Re: working draft last comments before it goes out

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

Julian-

Here are some comments on logins and on connection recovery.  The
draft is looking pretty good so far.

--
Mark

Login Security-

Looking at the latest draft, I noticed that section 3.13.5 (pg 37)
provides for a clear text login, while section 6.2.1.1 (pg 52)
assumes that long-lived passwords are never sent in the clear.
These appear contradictory.  I also do not see any method to do
digest authentication; all of the strong authentication schemes
are based on public key encryption, which I think will require some
sort of key distribution or certificate system to be in place.

Anyway, I would like to see the clear text login replaced with
a digest login, based on MD5 and a nonce, like HTTP/1.1 uses.
For those who wish to base authentication on knowing a user name
and password, this will be an easier scheme to configure and deploy.
This method of hashing passwords is so easy to do, and requires no
additional configuration to be done, that it could simply replace
the clear text logins.  I had proposed the text fields to
accomplish this in a previous posting; I will be happy to re-send
it if anyone is interested.

Login Version-

The Version field (either a text field or part of the login command
header) still needs to be added.

Asynchronous Events-

(this one might not make it in this draft)

In conjunction with the connection recovery discussion, I would still
like to add an asynchronous event type indicating that the target is
planning to close the connection:

3.6.2.  SCSI Event Indicator

   5 Connection will be closed by the target

   Two reserved fields would be used to communicate:

   - MaxUpTime - the number of seconds the target intends to keep
                 the connection alive.
   - MinHoldTime - the number of seconds the initiator should wait
                 before establishing a new connection.

This feature would allow a target to indicate that it wishes a
connection to be re-established, in the case of a controlled shutdown,
failover, or other operation on the target itself.  The initiator
would perform normal connection recovery, and would not necessarily
have to lose commands and data.

An open question-  I've documented this as an advisory event, since
the initiator has to deal with "hard" shutdown or failover of a target
anyway.  Would it be cleaner to allow the client to acknowledge that
it is finished with the connection, or have the client close the
connection within a certain time period?


julian_satran@il.ibm.com wrote:
> 
> A new version is on
> 
> http://www.haifa.il.ibm.com/satran/iSCSI-Working-Draft0709.txt
> 
> date July 9.
> 
> It will be out there for a very short time (24 Hours?) before I send it (+
> some editorial
> corrections some of which are already apparent) to the IETF.
> 
> It includes the things we agreed already.
> 
> Security is in (first pass).
> 
> Length is changed to accommodate even the case of immediate and
> non immediate data (ugly).
> 
> RDMA is out (not out but not reference as another doc).
> 
> Audio/Video is out.
> 
> Please have again a look at mapping and suggest wording.
> 
> Julo

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