Digest Login, iSCSI Discovery, and Other Draft 03 Comments

[Mark Bakke <mark.bakke@nuspeed.com>]

Here are some non-connection-recovery-related thoughts on Draft 03;
mainly concerning digest logins and iSCSI target discovery.


Logins for iSCSI draft 03 might benefit from the following additions:

1. Version number text fields should be placed in both login requests
   and responses.  the request could either specify the version of the
   protocol the initiator wishes to run, or perhaps a list of versions
   that the initiator is capable of running.

Version: 1.0

-OR-

Version: 1.0 1.1 1.2

  The target would then choose the highest version that it supported
  in common with those requested, and return it in the response:

Version: 1.1

2. Login with username and password.  It seems that the scheme already
   proposed (a digest scheme) would work quite well; we can re-use the
   text headers defined for HTTP/1.1, with some simplification (see
   RFC 2617).

   The initiator would send the initial login message, which would be
   failed by the target with status == 2 (additional authentication
   required; just like HTTP 401).  The following text fields would be
   added to the response by the target:

Authenticate: Digest
Nonce: text-string (hex or uuencode of random value)

   The Nonce is used to provide a temporary value with which to hash
   the username and password, preventing replay of the password on
   another TCP connection.  The nonce is randomly generated by the
   target, and should be thrown out after being used to validate the
   login for a particular connection.

   The initiator would then concatenate the nonce, user-name, and
   password, and compute their MD5 hash.  It would send a new login
   request to the target:

Authenticator: Digest user-name hex-hashed-response
Nonce: (echo of hex-string)

   Where hex-hashed-response
         = md5(concat(nonce, ":", user-name, ":", password))

   Note that if a given nonce value is only used on a single 
   connection, we really don't have to echo it here as they
   do in HTTP/1.1.

3. Underlying encryption mechanisms could be either negotiated by
   name at login, or could just be assumed on different TCP ports;
   CIFS and telnet are done over SSL without modification to their
   protocols; perhaps IPSec is similar?

   For the most part, I think that any of these mechanisms supported
   by the target and initiator, or transparently by network security
   devices would work with the protocol, and that there shouldn't
   be a lot to specify here.

   However, it might be worth thinking about how user-names and
   passwords are tied in to those lower levels.

--------------------------------------------------------

iSCSI Target and LUN Discovery

1. The target named "iSCSI-SYS" in Draft 03 looks good.

2. We would like to add the sendTargets text command - this is a
   value-add command for NuSpeed, but would be a good addition to
   the spec, as it eliminates most of the need to configure the
   iSCSI driver in the initiator.  Targets that do not wish to
   report this information can deny the command.  Normally, only
   the targets to which an initiator should have access are
   returned.  Here's the text command we use now.  We log into
   iSCSI-SYS, use sendTargets to find the targets, then log into
   each target.

   The command:

com.nuspeed.sendTargets:please

   The response is a list of "target:<target-name>"

target:jbod_one
target:tape_three
... 

   We would rename this command to just sendTargets.

3. Async notification for a new LUN in an existing, connected target
   is in the draft, but there's no notification for a newly-created
   target.  This notification would work with our sendTargets
   mechanism, and would probably just define an event type to
   ask the initiator to re-request the target list.


--------------------------------------------------------

Flow Control

1. Right now we are sending Queue Full back to handle flow control
   from the iSCSI target; someone indicated that this may break
   some host SCSI implementations.  Is this correct?  Anyway, will
   the MaxCmdRN scheme handle this effectively?

2. MaxCmdRN has found its way into quite a few response headers.  This
   probably does not need to be updated that often, most likely when
   watermarks are reached.  Costa's separate message looks like would
   be cleaner.

--------------------------------------------------------

Data and Command CRC (or other checksum/hash/whatever)

- More to come; we would like to see these negotiated at login, and
  have separate CRCs for iSCSI headers and actual data.

--------------------------------------------------------

Some additional notes on iSCSI draft 03.

1. Immediate Data - this is a nice optimization for small data messages,
   since they cut down on data headers, and eliminate another message
   to parse on the target.  However, using this for large data can get
   around a target that wants to use RTT.  Should RTT be required to
   used immediate data, or should the length of immediate data be
   limited to some fixed (or negotiated) maximum (a few kbytes)?

2. The Write bit is gone from the header; clearing both the Read and
   Write bits implied a Control message before.  Without the Write
   bit, I assume that an expected data length of zero would indicate
   a Control message instead.


-- 
Mark A. Bakke
NuSpeed, Inc.
mark.bakke@nuspeed.com
763.398.1054