iSCSI 04.txt is out

[julian_satran@il.ibm.com]

Dear colleagues,

I've just submitted to the Internet-Drafts repository and to our list
archive (at CMU) a new
version of the draft.

You can find the new document at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-04.txt

It includes many changes and a brief summary of them follows:

- it includes a first attempt at synchronization with the ND team

- text and login are explained in more detail and the login phase is
complete

- the new PDU format (you had a preview on the list)

- recovery has a new help PDU - the SACK

- We have removed the data ack mechanism (as agreed in Orlando) but we had
to leave data sequence in to enable detection of missed pieces of data (not
necessarily recovery) without resorting to a very "unSCSI" scoreboarding
technique

-the recovery chapter is rewritten and has now two complementary threads -
errors and recovery

-Security - here is a short summary for the main security changes:

1. Public key, password and challenge  authentication methods are removed.
All public key related stuff is removed.  Public key mechanism for iSCSI
can be implemented at the IPSEC level, or as a propriety authentication
method (that is still allowed!)

2. The defined authentication methods are now none, KERB5 and srp.

3. The header and data digests remain and can be negotiated to none, CRC or
KERB5-based digests. The motivation for KERB5-based digests is that after
KERB5 authentication (mutual or initiator-only)  both parties have actually
built a security context with symmetric session key, and it makes sense to
enable its usage for digests with real security significance. Moreover,
this follows the typical usage of KERB5 through GSSAPI (rfc-1964) and the
KERB5 digests were  defined according to the three GSS_getMIC() options for
digests.

4. The only CRCs left are CRC32Q (a new and supposedly far better CRC with
a 10**-4 lower probability of undetected errors) and CRC64. The memo we are
working on about block lengths will be out soon.  CRC64 is open (but CRC32Q
makes the need for it less stringent for a while).

4. About security MUST and MAY for iSCSI implementation as it appears now:
- It MUST provide means of authentication and data integrity.
- it MAY provide means of data privacy (encryption).
- Both statements can be satisfied by using IPSEC.
- When not using IPSEC  iSCSI implementation MUST provide   the KERB5
authentication and data integrity or other propriety method for
authentication and data integrity - and those can be software solutions.

We gave up on TLS (it can still be used as a "proprietary option") for two
reasons;

-it does make framing and RDMA more difficult (an additional layer of
chunking!)
-it is more expensive in terms of performance than the mechanisms that we
decided to keep - although it offers features far beyond our minimal needs

Regards,
Julo