Re: iSCSI login phasing

[Steve Senum <ssenum@cisco.com>]

Bob,

I like your overall approach, but at this point,
I would favor Julian's proposal.  If the WG
wanted to minimize the changes though, I think
your approach should be looked at some more.

Comment:

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.
Also, I would not expect to see T3 (Leave Security) as
a state.

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