Re: Digest Login, iSCSI Discovery, and Other Draft 03 Comments

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

Julian-

Thanks for taking a look.  My comments are embedded below.

-
Mark

julian_satran@il.ibm.com wrote:
> 
> 1. version is already in my working draft!

Excellent
 
> 2. we will have to merge it with whatever comes from Luciano & Paul

Luciano & Paul- Any comments?

> 
> 3.that assumption was made for SSL
> 
> 1. anything related to discovery might be a bit premature. What you propose
> look like a neat
> thing but I don't know how it will merge with the management scheme,
> administrative access.
> I though that reserving the name is a thing we should do now but not more

We'll leave our discovery scheme as an implementation enhancement for
now, until we see how it plays out.

> 2. Queue full - Is a SCSI layer thing. I think that passing over MaxCmdRN
> should have the command discarded with iSCSI protocol error (or something
> of this nature)

It sounds like the MaxCmdRN should eliminate the need to send Queue Full
most (if not all) of the time.  This should take care of any concerns
about the host's SCSI-layer implementations.

> 2. I can reinstate the bit. But control commands can have data and in this
> sense are writes.
>     R/W was meant only to indicate the meaning of ExpectedDataLength (to
> avoid scaning the CDB)

We shouldn't need to reinstate the bit; your description works just
fine.
 
> Regards,
> Julo
> 
> Mark Bakke <mark.bakke@nuspeed.com> on 29/06/2000 16:13:32
> 
> Please respond to Mark Bakke <mark.bakke@nuspeed.com>
> 
> To:   ips@ece.cmu.edu
> cc:    (bcc: Julian Satran/Haifa/IBM)
> Subject:  Digest Login, iSCSI Discovery, and Other Draft 03 Comments
> 
> 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

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