Re: iSCSI login phasing

[Steve Senum <ssenum@cisco.com>]

Julian,

Questions on your proposal.

1. Is the Initiator then required to start
   with either a SecurityPhase=start or an
   OperationalPhase=start on the initial
   login command?

2. If the Initiator started with
   OperationalPhase=start, does the target
   have any way to force a SecurityPhase=start?

Steve Senum

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