Re: iSCSI OpParamReset

["Julian Satran" <Julian_Satran@il.ibm.com>]

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.

++++