Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code

From: "Julian Satran" <[email-masked]>
Date: Thu, 30 Aug 2001 00:17:31 +0300

Steve,

The partial response is not strictly needed it is just handy to have the
login request answered
with a login response. On this we can put the partial/final answer. For a
text it would have been arbitrary (text outside login does not need it).

As for the names - I though that security people might object having the
name in clear if the security phase does not make use of the name.
Otherwise we can mandate them on the login but I wonder if that is a real
improvement or we are getting carelles.

Julo

Steve Senum <[email-masked]>@ece.cmu.edu on 29-08-2001 23:59:36

Please respond to Steve Senum <[email-masked]>

Sent by:  [email-masked]

To:   ietf-ips <[email-masked]>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code

Julian,

A couple of ideas from Matthew Burbridge & Co.'s
login proposal that has generated some interest here:

1. Removal of partial login response.  Is it still needed?

2. Requiring Initiator and (if not a discovery session)
   Target names on login command, so they are always
   available if needed by the initial phase.

Comments?

Regards,
Steve Senum

---

From: "Ayman Ghanem" <[email-masked]>
Date: Wed, 29 Aug 2001 21:26:27 -0500

Julian,

One could also argue for symmetry; only one login response per login cmd. On
the other hand, the only time a partial login is returned at the moment is
when status class is 0 and F=0. Any other status class results in a final
login response. For status class 0, there exists 3 status detail codes: 0,
1, and 2. The first two are implied from the negotiation phase, and the
third case will no longer exist if we enforce the ITN to be sent in the
login cmd. The session parameters returned in a partial login response are
not needed because the connection has not joined the session yet during
login.

-Ayman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Julian Satran
> Sent: Wednesday, August 29, 2001 4:18 PM
> To: [email-masked]

---

From: Sandeep Joshi <[email-masked]>
Date: Thu, 30 Aug 2001 12:11:53 -0400

Julian,

> > improvement or we are getting carelles.

The problem with these names (and hence the request from Steve and
others 
earlier) is that it is not possible to know when the target wants them. 

Consider the following excerpts from your latest login proposal..

> A target MAY use the iSCSI Initiator Name as part of its access control
> mechanism; therefore, the iSCSI Initiator Name MUST be sent before the
> target is required to disclose its LUs.

The above is _very_ confusing..how can the initiator know if the
 the target is doing access control ?

> If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used
> in determining the security mode or it is implicit part of
> authentication, then the iSCSI Target Name and/or iSCSI Initiator Name
> MUST be sent in the login command for the first connection of a session
> to identify the storage endpoint of the session

In both the above cases, how does the initiator know when the target
requires these names?  The partial login response occurs *only* once.
So when going from the security->operational phase, there is no
indication that the target would like these names sent.

There are 3 options here :
(A) ALways send the names in the login command.  Simplify target
   and initiator and eliminate a few of those partial login 
   response codes.
(B) Maintain a configuration database (per-target) of when names
   must be sent - adds an administration burden.  
(C) Change the wire protocol to allow the target to indicate when
   the names must be sent - again more complications. 

To round up, I prefer Option (A).  These are just names and not
passwords, so the security risks are minimal.  Are we trying to 
protect against traffic analysis ?

-Sandeep

---

From: Steve Senum <[email-masked]>
Date: Thu, 30 Aug 2001 10:57:46 -0500

Julian,

> improvement or we are getting carelles.

The names are in the clear in any case, unless IPsec encryption is
being used, in which case the entire connection is encrypted.

My concern is that an initiator can't know without
configuration when the target needs the names, so I would
prefer we mandate them on the login command.

Regards,
Steve Senum