Re: iSCSI login phasing

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

Steve:

> I am a bit confused by your iSCSI Target state diagram.
> I would think you should be able to go from T1 to
> either T2 or T4, depending on what the login command
> contained.  Something like login command with
> SecurityContextComplete=yes goes to T4, else goes to T2.

I was assuming that the SecurityContextComplete=yes key
could not appear in the same list as other keys, and
therefore could not be in the login command because these
were required to carry the 3 security keys HeaderDigest=,
DataDigest=, and AuthMethod=.


> Also, I would not expect to see T3 (Leave Security) as
> a state.

This state is needed for the case when it is the target,
not the initiator, that is the first one to send the
SecurityContextComplete=yes key (on the Z3 transition).
The target must now wait for the initiator to reply
with SecurityContextComplete=yes, and then send
SecurityContextComplete=yes again because, as described
in one of Julian's recent e-mails, the handshake
must always end with the Target sending this key to the
Initiator.

There is another assumption in this diagram, which I believe
is true for all the security negotiation dialogues proposed
for iSCSI, but I would like verification of this from others,
and that is that once one side sends SecurityContextComplete=yes,
the other side will in fact also be finished and will send
the same key back (assuming successful negotiation).
This is certainly true for all the examples shown in draft 7,
but, of course, these are only examples and do not exhaust
all the possibilities.  If there are situations where
the other side needs to continue the negotiation, then 2 more
transitions would be needed: one from state T3 back to itself,
labeled with conditions and actions similar to transition Z3,
and one from state T3 back to state T2, labeled with
conditions and actions similar to transition Z2.
Adding these transitions makes the target diagram more similar
to the initiator diagram for the two states Negotiate Security
and Leave Security.

Bob


> 
> Regards,
> Steve Senum
> 
> "Robert D. Russell" wrote:
> > 
> > All:
> > 
> > Attached are 2 ASCII text files.  Once contains a state diagram
> > for the iSCSI Initiator login phase, the other a state diagram
> > for the iSCSI Target login phase.
> > 
> > The Initiator state machine has only 6 states with 10 allowed
> > transitions, and the Target state machine has only 5 states
> > with 7 allowed transitions.  Both diagrams have the form of
> > a single "spine" with minimal branching.  Error/failure
> > transitions are not shown, since they always result in
> > closing the connection during login (on the target side
> > a reject message may be sent first).
> > 
> > Both of these diagrams are based on draft 7 with simplifications
> > suggested by Julian, Rod Harrison, Steve Senum, Eddy Quicksall,
> > Stephen Bailey, Barry Reinhold, myself and others.
> > 
> > These include:
> > 
> > 1. Every login is split into 2 distinct subphases (security and
> >    operational) with a required demarcation line between them.
> > 
> > 1. Every login starts in the security subphase and must contain
> >    at least the keys: TargetName, InitiatorName, HeaderDigest,
> >    DataDigest, AuthMethod, and optionally SessionType=Normal.
> > 
> > 2. No operational parameters can be negotiated before or during
> >    the security subphase (informational parameters, like
> >    TargetName, although listed in Appendix D, do not require
> >    negotiation and are not considered "operational" here).
> > 
> > 3. The security subphase ends with a required 2- or 3-way handshake of
> >    Text and Text Response PDUs containing only the
> >    SecurityContextComplete=yes key and ending with a message from
> >    the target to the initiator.  The negotiated security functions
> >    become effective only at the successful conclusion of this handshake.
> > 
> > 4. The operational subphase always begins immediately after the
> >    handshake had been completed.  No security parameters can be
> >    negotiated during or after the operational subphase.
> > 
> > 5. The operational subphase ends with a Login Response with F=1 from
> >    the target to the initiator, at which time both target and
> >    initiator are in Full Feature Phase (the final state in both
> >    diagrams).
> > 
> > Comments please.
> > 
> > Bob Russell
> > InterOperability Lab
> > University of New Hampshire
> > rdr@iol.unh.edu
> > 603-862-3774
> > 
> > On Fri, 27 Jul 2001, Julian Satran wrote:
> > 
> > > 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
> > >
> > >
> > >
> > 
> >   --------------------------------------------------------------------------------
> >                Name: i_states
> >    i_states    Type: Plain Text (TEXT/PLAIN)
> >            Encoding: BASE64
> > 
> >                Name: t_states
> >    t_states    Type: Plain Text (TEXT/PLAIN)
> >            Encoding: BASE64
>