SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    


Home

Last updated: Tue Sep 04 01:08:12 2001
6315 messages in chronological order