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



    
    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
    
    
    
    
    
    
    


Home

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