RE: iSCSI login phasing

[Julian_Satran/Haifa/IBM%IBMIL <julian_satran@il.ibm.com>]

Deva,

If there is no security phase the keywords SEcurityPhase start/end don't
have to be used.

Julo



"Dev - Platys" <deva@platys.com> on 27-07-2001 18:30:14

Please respond to "Dev - Platys" <deva@platys.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI login phasing




Julian,

So this proposal allows the operational parameters to be issued during
login
request itself if it there is no authentication ?

i.e.

I ->FR Login -> Operational Parameters = Start key1=x, key2 =x, Operational
Parameters = End
T ->FR Login -> Operation Parameters = Start key=x, key2=x, key3=x

In the above case, since no authentication is involved thre is no security
phase start end.

Also the keywords SecurityPhase=Start and SecurityPhase=end mandatory so to
be used even during non authentication phases.

Thanks

Deva

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Thursday, July 26, 2001 11:14 PM
To: ips@ece.cmu.edu
Subject: iSCSI login phasing


Dear colleagues,

As some of you have complained about difficulty in implementing the login
phase I thought it might be worthwhile to consider a slight departure from
the current description.

The current text assumes that negotiations are forming one tree and the
"login machine" has to parse the tree.
A leaf node will completely define a state and some pathes may get you to
error.

I was driven to this design by the need to keep the parsing tree minimal
(under the assumption that any split in subtrees
will result is some parameters needing to appear in several subtrees).

However - after the noisy (mostly UPPERCASE) debate - I came to realize
that few if any have done the generalized mapping I started with, and
implemented a parser,  and ad-hoc, man-glued, engines have to have smaller
trees for the next plugfest (although by then some bright undergraduate
student may take onto himself to give us  an open-source yacc definition of
the login phase!).

I looked at the 2 phases and the number of key=values that they share are
probably limited today at initiator and target names (some
organizations/configurations want them for authentication while some others
will object to them being revealed in the "open phase") and as such we may
want to slit the login in 2, completely bracketed, phases each of them
optional but not both:


   a security phase that if present must start with the login command and
   is bracketed by the pairs SecurityPhase=start and ended by
   SecurityPhase=end (on both initiator and target)
   an operational-parameter-negotiation phase that must follow security
   phase (if there is a security phase) and is bracketed by the pairs
   OperationalPhase=start and OperationalPhase=end (on both initiator and
   target)


Some additional rules will apply:

   No request/response will span phases
   The phase closing handshake can start on both sides but if started at
   target will be followed by an "full initiator target handshake" - i.e a
   new phase or the "curtain close" end always with the target having the
   last word.
   keys will be clearly segregated and only a few (like names) should be
   allowed in both.


Comments?

Julo