SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI OpParamReset



    I am also ambivalent about it. The reason I introduced it is that it is
    norm in secure environments
    to drop things that where negotiated before establishing the secure
    environment.
    However one of the parties may have already commited to some changes before
    the secure
    environment - dropping will not help too much in this case.
    As a more general think any parameters negotiated during login are supposed
    to be "removed in block"
    if the login fails.
    
    It looked to me that having to implement the atomic behavior for login
    anyhow (for recovery) adding OpParmReset will allow more freedom in the
    decision about what to drop and what can stay even when negotiated before
    security.
    
    Julo
    
    "Rod Harrison" <rod.harrison@windriver.com> on 20-07-2001 06:44:14
    
    Please respond to "Rod Harrison" <rod.harrison@windriver.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL, "Robert D. Russell"
          <rdr@mars.iol.unh.edu>
    cc:   "ips" <ips@ece.cmu.edu>
    Subject:  iSCSI OpParamReset
    
    
    
    
    Julian,
    
         I have no fundamental objection to the introduction of the
    OpParamReset key, however please consider the following
    observation.
    
         It seems an implementer has two basic choices with respect
    to OpParamReset.
    
         1) Add special case code in the login phase handling to
    remember the initial values that might get reset.
    
         2) Obviate (1) by always sending OpParamReset.
    
         I suspect most implementers will go for option (2), if this
    is so we might as well mandate that behaviour and remove the
    need for key.
    
         - Rod
    
    ------------------------------------------------------------
    --------------------
    
    
     1. Exactly what should happen if operational parameters are
    sent by the
        initiator during the security phase of login?
    
    
        In section 4.2 the standard says:
        "-The iSCSI parameter negotiation (non-security
    parameters)
         SHOULD start only after security is established.  This
    should be
         performed using text commands."
    
        and:
        "When establishing the security context, any
        operational parameters sent before establishing a secure
        context MAY be ignored by both the target and the
    initiator."
    
        There is a problem with the meaning of "ignore" --
    should the target:
    
            1.  not respond to these operational keys at all, or
            2.  respond with key=reject, or
            3.  respond with a valid value and then just not use
    these values.
                In this case, how does the initiator know
    whether or not the
    target
                is ignoring these parameters or not?
    
        A final note:  The standard seems to allow the initiator
    to
        send operational parameters when establishing the
    security context,
        get back a valid value from the target, and then ignore
    the entire
        negotiation anyway.  Is this legal?  In this case, how
    does
        the target know that the initiator is ignoring these
    parameters?
    
    +++ It is standard practice (and legal) in most protocols to
    reset the
    operational parameters to previous values
    at the end of the security phase negotiation if the channel
    is becoming a
    secure channel
    WE have two options:
    
    a) assume that this happens at every SecurityContextComplete
    b) say explicitly that it happened - e.g., the target or
    initiator decide
    that the channel is now more secure than before
    and say explicitly something like OpParmReset=yes
    
    I will assume that is b that most of you want and I will say
    so in 7 unless
    I hear otherwise TODAY:
    
    here is the text:
    
    01   OpParmReset
    
       Use: IO
       Who can send: Initiator and Target
    
       OpParmReset=<yes|no>
    
       OpParmReset enables an Initiator or Target to request the
    operational
       parameters to be reset to the values they had before
    login.  Either the
       initiator or target may choose to do so but only after
    and only if a
       SecurityContextComplete handshake is completed on the
    connection. The
       resetting should involve only parameters that where set
    during login on
       the connection in which the OpParmReset is issued.
    Please note that
       since either initiator or target may request this
    behavior there is no
       need to reply.
    
       and 4.3 reads:
    
    1.1  Operational Parameter Negotiation During the Login
    Phase
    
       Operational parameter negotiation during the login MAY be
    done:
    
          - starting with the Login command if the initiator
    does not offer
          any security/ integrity option
          - starting immediately after the security/integrity
    negotiation if
          the initiator and target perform such a negotiation
          - starting immediately after the Login response with
    Final bit 0 if
          the initiator does offer  security/integrity options
    but the target
          chose none.
    
       An operational parameter negotiation on a connection
    SHOULD not start
       before the security/integrity negotiation if such a
    negotiation exists.
       Operational parameters negotiated inadvertently before
    the
       security/integrity negotiation MAY be reset after the
    security/integrity
       negotiation at the explicit request of the initiator or
    target.
    
     ++++
          TargetName=iqn.com.acme.diskarray.sn.88
    HeaderDigest=crc-32C,none
          DataDigest=crc-32C,none AuthMethod:KRB5,SRP,none
          T-> Login-PR, HeaderDigest=none, DataDigest=none,
    AuthMethod=none
          I-> Text SecurityContextComplete=yes
          T-> Text SecurityContextComplete=yes
    
          I-> Text ... iSCSI parameters
          T-> Text ... iSCSI parameters
    
          And at the end:
    
          I-> Text optional iSCSI parameters F bit set to 1
          T-> Login "login accept"
    TargetName=iqn.com.acme.diskarray.sn.88
    
       Note that SecurityContextComplete=yes is required
    although no security
       mechanism was chosen.
    
    ++++
    
    
    
    
    
    
    
    


Home

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