SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI login phasing



    Julian,
    
    I like the intent of your proposal, with
    explict keys to mark the beginning of the phases.
    
    I still think we could achieve most of this
    with the existing handshake protocols
    (SecurityContextComplete for the SecurityPhase
    phase, F=1 bits for the OperationalPhase).
    We just need to define exactly when the
    SecurityPhase is (and is not) entered.
    I still vote for going through the SecurityPhase
    all the time.
    
    But, your proposal is a bit more precise on these points,
    and a more complete solution.
    
    Regards,
    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
    


Home

Last updated: Tue Sep 04 01:04:10 2001
6315 messages in chronological order