SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Login Proposal



    Subrahmanya,
    
    I can only presume that you sent this by mistake.  If you have any other
    reasons please can you explain them.  As John mentioned this is very old
    stuff.
    
    Cheers
    
    Matthew Burbridge
    
    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Tuesday, February 26, 2002 12:56 AM
    To: Subrahmanya Sastry K V
    Cc: 'ips@ece.cmu.edu'; 'Julian Satran'
    Subject: Re: Login Proposal
    
    
    
    I do not see why this is needed, almost everyone has moved on from v0.7,
    and we have overtly left boot sessions, and copy manager session behind.
    Everyone I talked to at the last plugfest got through login without a
    significant issue.
    
    This seems a bit strange to bring this up now.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Subrahmanya Sastry K V <skotra@npd.hcltech.com>@ece.cmu.edu on 02/25/2002
    08:04:13 PM
    
    Sent by:    owner-ips@ece.cmu.edu
    
    
    To:    "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>, "'Julian Satran'"
           <Julian_Satran@il.ibm.com>
    cc:
    Subject:    Login Proposal
    
    
    
    The recent plugfest highlighted areas of the login procedure that could
    be
    improved.
    With this in mind, Bob Russell, Marjorie Krueger, and myself have been
    working on
    a proposal for the Login procedure.
    
    Our goals were to keep it inline as much as possible with 0.7 of the
    specification and
    to ensure connectivity can be maintained amongst target and initiators.
    I
    believe we
    have meet all the goals we set out to do.
    
    I have also attached a Login Reference Model (in the form of c code)
    which
    backs up
    our proposal.  Please note that the reference model is only a reference
    model and should
    not be considered as, or be part of the iSCSI specification.
    
    Cheers
    
    Matthew Burbridge
    Marjorie Krueger
    Bob Russell
    
    ++++++++++++++++++++++++
    
    The Login Proposal:
    
    Definitions:
    FBit means "I have nothing (more) to negotiate"
    Request: The first occurrence of a Text Parameter from the initiator or
    the
    target. A request
             MUST be answered with a reply.
    Reply: A Text Parameter that is a response to a Request.
    Negotiation: A request followed by a response.
    
    1.1 Actions at the Initiator
    
    The initiator starts the login phase by sending a Login Command PDU.
    
    The IIN MUST be present in the login command.  The SessionType MUST be
    present if the
    session type is Discovery, Boot or CopyManager.  It MAY be present if
    SessionType=Normal.
    The ITN MUST be present unless SessionType=Discovery when it is
    optional.
    The initiator
    MUST NOT send operational text parameters in the login command.  The
    table
    below defines
    the parameter present in the login command.
    
            SessionType        SessionType          IIN               ITN
                               Present in        Present in        Present
    in
                                 Login?            Login?            Login?
    
              Normal            Optional            Yes               Yes
               Boot               Yes               Yes               Yes
            CopyManager           Yes               Yes               Yes
             Discovery            Yes               Yes             Optional
    
    SecurityContextComplete=yes MUST NOT be present in the login command
    Operational Parameters MUST NOT be present in the login command
    
    At anytime the initiator MAY terminate the login killing the TCP
    connection.
    
    If the initiator requires security negotiation it MUST send one or more
    security
    parameters: (AuthMethod, HeaderDigest, DataDigest) in the login command.
    
                 Fbit     Security
                         Parameters     Description
                          Present
    
                  0          No         Initiator has no security parameters
                                        to negotiate but has operational
    parameters
                                        to negotiate.
    
                  0          Yes        The initiator wants to negotiate
    security.
    
                  1          No         The initiator has no security
    parameters
    to
                                        negotiate and no operational
    parameters
    to
                                        negotiate.
    
                  1         Yes         ILLEGAL.  Target must reject login
                                        (Login Status = 0200)
    
    1.2 Actions at the Target
    
    On receipt of the Login Command the target MUST respond according to the
    rules below:
    
    If the InitiatorName is not present the target MUST reject the login
    by sending a Login Response with FBit=1 and StatusCode=0200.  Similary,
    if
    the
    SessionType is not Discovery and the TargetName is not present the
    target
    MUST
    reject the login by sending a Login Response with FBit=1 and
    StatusCode=0200. It
    both cases the target should kill the TCP connection after the login
    response has
    successfully been sent.
    
    At anytime the target MAY terminate the login by sending a login
    response
    with
    the FBit set to 1 and a non-zero StatusCode. The target should kill the
    TCP
    connection after the login response has successfully been sent.
    
    If the login command contains security parameters, the target MUST enter
    the
    security
    phase of the login.  It MUST send response to those security parameters
    and
    MAY start
    negotiating security parameters if the parameters that it wants to
    negotiate
    are not
    in the Login command.  The target responses with a Text Response (F=0).
    
    If the login command does not contain security parameters the target
    MUST
    perform one
    of the two actions below:
    
          a) If the target requires security negotiation to be performed,
    then
    it MUST
             enter the security phase and MUST send a text response
    containing
    one or
             more security parameters and F=0.
    
          b) If the target does not require security negotiation (and
    therefore
    neither
             does the initiator) it MUST perform one of the actions defined
    by
    the table
             below.
    
                  Initiator    Target has     Action
                    FBit       params to
                               negotiate
    
                     0            No         Send Text Response with F=1
    (Initiator
                                             only wants to negotiate
    operational
                                             parameters).
    
                     0            Yes        Send Text Response with
    operation
    params
                                             If all parameters can be sent
    in
                                             a single response then F=1 else
    F=0
                                             (Both target and initiator want
    to
                                             negotiate operational
    parameters).
    
                     1            No         Send Login Response with F=1.
    (Neither target
                                             nor initiator want to negotiate
    operational
                                             parameters).
    
                     1            Yes        Send Text Response. If all
    parameters can be
                                             sent in a single response then
    F=1
    else
                                             F=0 (Target only wants to
    negotiate
                                             operational parameters).
    
    1.3 General Rules
    
    If an initiator or target has text parameters (security or operational)
    to
    negotiate
    then it MUST send them at the earliest opportunity and it MUST NOT send
    an
    empty text
    command.
    
    An initiator or target MUST respond to the a text parameter request with
    a
    text parameter
    response in the next text PDU to be sent.
    
    Once an initiator or target has completed initiating negotiations
    (security
    or operational)
    it MUST not initiate any more of the same type (security or
    operational).
    In other
    words it can not go backwards.
    
    Operational Parameters MUST NOT be negotiated during the security phase.
    Security Parameters MUST NOT be negotiated during the operartional
    phase.
    
    When a party has no more text parameters to negotiate then the FBit MUST
    be set in the PDU containing the last text parameter request and all
    subsequent
    PDUs.  For example: if an initiator only wants to negotiate
    "InitialR2T=yes"
    and no others, then it MUST set the FBit to 1 in the commands containing
    "InitialR2T=yes".
    
    Once the FBit has been set to 1, it MUST not be set back to 0.  Also, if
    the FBit is 1 then the party MUST not instigate anymore text parameter
    negotiations.  It can only respond to requests from the other party.
    
    If FMarker=yes then SFMarkInt and RFMarkInt MUST be present in the same
    Text PDU as FMarker=yes.  If FMarker=no then SHOULD NOT be present.  If
    they
    are then the remote party MUST reply to them and echo the values sent in
    the
    initial PDU.
    
    1.4 Completion of Security Phase
    [Authors note: This section has been extracted from v0.7 but I have made
    some
    clarifications to the version 0.7 spec. - Changes in CAPITALS]
    
              -Every party in the security negotiation MUST [Added MUST]
               indicate that it has completed building its security context
               (has all the required information) by sending the key=value
    pair:
    
    
                  SecurityContextComplete=yes
    
               The other party either offers some more SECURITY parameters
    or
    answers
               with the same:
    
                  SecurityContextComplete=yes
    
    
               The party that is ready MUST [Added MUST] keep sending the
               SecurityContextComplete=yes pair (in addition to new security
               Parameter REPLYS if required) until the handshake is
    complete.
        Once the party has set SecurityContextComplete=yes it MUST
               not instigate anymore negotiations but it MUST respond to any
               requests from the other pary.
    
               If the initiator has been the last to complete the SECUIRTY
    PHASE
    it
               MUST NOT start sending operational parameters within the same
               text command; a text response including only
               SecurityContextComplete=yes concludes the security sub-phase.
    
               If the target has been the last to complete the SECURITY
    PHASE,
    the
               initiator can start the operational parameter negotiation
    with
               the next text command; the security negotiation sub-phase
    ends
               with the target text response.
    
               The SecurityContextComplete handshake MUST be performed if
    any
               of negotiating parties has offered a security/integrity item
               (even if it is not selected).
    
               All PDUs sent after the security negotiation sub phase MUST
    be
               built using the agreed security.
    
    This proposal removes from 0.7 of the spec:
    Partial Login response: It no longer coveys any information.
    OpParamReset: No longer required as operational parameters can not be
    negotiated
    during security phase.
    
    Keep:
    SecurityContextComplete=yes.  This is how 0.7 works.  If people disagree
    then
    we can vote and change it.
    
    
    
    Matthew Burbridge
    Senior Development Engineer
    NIS-Bristol
    Hewlett Packard
    Telnet: 312 7010
    E-mail: matthewb@bri.hp.com
    
    
    
    


Home

Last updated: Tue Feb 26 13:18:21 2002
8893 messages in chronological order