iSCSI: Use of Reject as a key value

["Robert D. Russell" <rdr@io.iol.unh.edu>]

Julian:

Attached are 2 ascii text files.

The first, reject_extracts.txt, contains all the pieces of
draft 14 (the latest available txt version of the drafts)
that say anything about the use of Reject as a key value.
(At least all those I could find using simple search --
unfortunately, Reject is also the name of a PDU and hence
it is not a simple mechanical process to distinguish the two
uses!  If I missed some, please let me know.)

The second, reject_comments.txt, are my comments on these
excerpts from the standard.

It seems to me that the key thing missing in the standard is
a general statement about "what to do next" if a key=Reject response
is received.  Except for the OFMarkInt and IFMarkInt keys,
I could find no other statement about how to proceed after
receiving the key=Reject response.  In looking through the
e-mails posted to the list for June and July, I also could find
nothing, although many people seem to be taking the third
of the 3 interpretations I listed in reject_comments.txt.

I am requesting a clear statement somewhere in the standard that
says "what to do next" upon receiving a key=Reject response.

Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774




All references in draft 14 to use of "Reject" as a key value.
-------------------------------------------------------------

...

4.2  Text Mode Negotiation

...

   The general format of text negotiation is:

      Originator-> <key>=<valuex>
      Responder-> <key>=<valuey>|NotUnderstood|Irrelevant|Reject

   The originator or declarer can either be the initiator or the target 
   and the responder can either be the target or initiator, respec-
   tively. Targets are not limited to respond to key=value pairs as 
   offered by the initiator. The target may offer key=value pairs of its 
   own. 

   All negotiations are explicit (i.e., the result MUST be based only on 
   newly exchanged or declared values). There are no implicit offers. If 
   an explicit offer is not made then a reply cannot be expected. Con-
   servative design requires also that default values should not be 
   relied upon when use of some other value has serious consequences. 

   The value offered or declared can be a numerical-value, a numerical-
   range defined by lower and upper value - both integers separated by 
   tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSI-
   local-name-value, a boolean-value (Yes or No), or a list of comma 
   separated text-values. A range or a large-numerical-value MAY ONLY be 
   offered if it is explicitly allowed for a key. An iSCSI-name-value 
   and an iSCSI-local-name-value can be used only where explicitly 
   allowed. A selected value can be an numerical-value, a large-numeri-
   cal-value, a text-value or a boolean-value.

   If a specific key is not relevant for the current negotiation, the 
   responder may answer with the constant "Irrelevant" for all types of 
   negotiation. However the negotiation is not considered as failed if 
   the response is "Irrelevant".

   Any key not understood by the responder may be ignored by the 
   responder without affecting the basic function. However, the Text 
   Response for a key not understood MUST be key=NotUnderstood.

   The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are 
   reserved and must only be used as described here.

   Reject or Irrelevant are legitimate negotiation options where allowed 
   but their excessive use is discouraged. A negotiation is considered 
   complete when the responder has sent the key value pair even if the 
   value is "Reject", "Irrelevant", or "NotUnderstood. Sending the key 
   again would be a re-negotiation
    
   Some basic key=value pairs are described in Chapter 11. All keys in 
   Chapter 11, except for the X- extension format, MUST be supported by 
   iSCSI initiators and targets and MUST NOT be answered with NotUnder-
   stood.
    
...


4.2.1  List negotiations

   In list negotiation, the originator sends a list of values (which may 
   include "None") in its order of preference.

   The responding party MUST respond with the same key and the first 
   value that it supports (and is allowed to use for the specific origi-
   nator) selected from the originator list. 

   The constant "None" MUST always be used to indicate a missing func-
   tion. However, None is a valid selection only if it is explicitly 
   offered. 

   If a responder does not understand any particular value in a list it 
   MUST ignore it. If a responder does support, understand or is allowed 
   to use none of the offered options with a specific originator, it may 
   use the constant "Reject" or terminate the negotiation. The selec-
   tion of a value not offered is considered a negotiation failure and 
   is handled as a protocol error. 

4.2.2  Simple-value negotiations

   For simple-value negotiations, the responding party MUST respond with 
   the same key. The value it selects, based on the selection rule spe-
   cific to the key, becomes the negotiation result. For a numerical 
   range the value selected must be an integer within the offered range 
   or "Reject" (if the range is unacceptable). An offer of a value not 
   admissible (e.g., not within the specified bounds) MAY be answered 
   with the constant "Reject" or the responder MAY select an admissible 
   value. The selection, by the responder, of a value not admissible 
   under the selection rules is considered a negotiation failure and is 
   handled accordingly. The selection rules are key-specific. 

...


4.3  Login Phase

...

   Neither the initiator nor the target should attempt to declare or 
   negotiate a parameter more than once during login except for 
   responses to specific keys that explicitly allow repeated key decla-
   rations (e.g. TargetAddress). If detected by the target this MUST 
   result in a Login reject (initiator error). The initiator MUST drop 
   the connection
    

...

4.3.2  iSCSI Security Negotiation

   The security exchange sets the security mechanism and authenticates
   the initiator user and the target to each other. The exchange pro-
   ceeds according to the authentication method chosen in the negotia-
   tion phase and is conducted using the login requests' and responses' 
   key=value parameters.

   An initiator directed negotiation proceeds as follows:

     -The initiator sends a login request with an ordered list of 
       the options it supports (authentication algorithm). The 
       options are listed in the initiator's order of preference. 
       The initiator MAY also send proprietary options. 
     -The target MUST reply with the first option in the list it 
       supports and is allowed to use for the specific initiator 
       unless it does not support any in which case it MUST answer 
       with "Reject" (see also Section 4.2 Text Mode Negotiation). 
       The parameters are encoded in UTF8 as key=value. For secu-
       rity parameters, see Chapter 10.

...

A.3.2   OFMarkInt, IFMarkInt

   Use: IO
   Senders: Initiator and Target
   Scope: CO

   Offering:

   OFMarkInt=<numeric-range-from-1-to-65535> 
   IFMarkInt=<numeric-range-from-1-to-65535>

   Responding:

   OFMarkInt=<numeric-value-from-1-to-65535>|Reject
   IFMarkInt=<numeric-value-from-1-to-65535>|Reject

   OFMarkInt is used to set the interval for the initiator to target 
   markers on the connection.  IFMarkInt is used to set the interval for 
   the target to initiator markers on the connection.

   For the offering the initiator or target indicates the minimum to 
   maximum interval (in 4-byte words) it wants the markers for one or 
   both directions. In case it only wants a specific value, only a sin-
   gle value has to be specified. The responder selects a value within 
   the minimum and maximum offered or the only value offered or indi-
   cates through the xFMarker key=value its inability to set and/or 
   receive markers. When the interval is unacceptable the responder 
   answers with "Reject".  Reject is resetting the marker function in 
   the specified direction (Output or Input) to No.

...
Comments on the use of "Reject" as a key value.

In section 4.2, the "general format of text negotiation" clearly allows
both initiator and target to send and receive a "Reject" value.

However, this "general format" does not necessarily imply that it is
legal to send a "Reject" value at any time and for any key!

Later in the same section 4.2 it says:

    "Reject or Irrelevant are legitimate negotiation options where
    allowed but ...".

This could be read to imply that further explanations must be given to
indicate where Reject (Irrelevant) is allowed.  In fact, the standard 
explicitly lists the following specific situations where Reject is allowed.

    1.  In section 4.2.1, List negotiations, it says:
        
        "If a responder does support, understand or is allowed to use
        none of the offered options with a specific originator, it may
        use the constant "Reject" or terminate the negotiation."

      --This could be understood to mean that "Reject" does NOT terminate
        the negotiation.  However, the next sentence in the standard says:

        "The selection of a value not offered is considered a negotiation
        failure and is handled as a protocol error."

      --Clearly "Reject" was not offered, so if it appears in the
        response, this sentence could be understood to mean that the
        negotiation failed.


    2.  In section 4.2.2, Simple-value negotiations, it says:

        "For a numerical range the value selected must be an integer
        withing the offered range or "Reject" (if the range is
        unacceptable)."

      --This explicitly allows Reject as a response for numerical range
        parameters (of which there are only two: OFMarkInt and IFMarkInt),
        but doesn't say what to do next if Reject is used.  However,
        section A.3.2 does say what to do for the OFMarkInt and IFMarkInt
        keys (see below).


    3.  Also in section 4.2.2, Simple-value negotiations, it says:

        "An offer of a value not admissible (e.e., not within the specified
        bounds) MAY be answered with the constant "Reject" or the responder
        MAY select an admissible value."

      --This explicitly allows Reject as a response for other simple-value
        types (keys expecting numerical values, boolean values, etc.),
        but again doesn't say what to do next if Reject is used.


    4.  In section 4.3.2, iSCSI Security Negotiation, it says:

        "-The target MUST reply with the first option in the list it
        supports and is allowed to use for the specific initiator
        unless it does not support any in which case it MUST answer
        with "Reject" (see also Section 4.2 Text Mode Negotiation)."

      --Ok, but then what happens next -- has the negotiation failed?
        If not, what value is used for the rejected key -- the value
        in effect prior to this offer/response exchange?  The standard
        never says.


    5.  In section A.3.2, OFMarkInt, IFMarkInt, it says:

        "Responding:
        OFMarkInt=<numeric-range-from-1-to-65535>|Reject
        IFMarkInt=<numeric-range-from-1-to-65535>|Reject"

      --This is the only instance where Reject is explicitly specified
        as a valid response for a specific key.


    6.  Also in section A.3.2, OFMarkInt, IFMarkInt, it says:

        "When the interval is unacceptable the responder answers with
        "Reject".  Reject is resetting the marker function in the
        specified direction (Output or Input) to No."

      --This is also the only instance where the standard says what to
        do when a response value of Reject is used.


I believe the source of much confusion is that, except for point 6 above,
the standard never says what is supposed to happen next when a response
value of Reject is used!

There are at least the following three interpretations:

    1.  Both sides use the value of the key in effect before the offer
        and continue with negotiations as if nothing had happened,
        although this particular key cannot be offered again in this
        negotiation sequence (that is explicit).

    2.  Treat the negotiation as a failure and take appropriate action.
        During login, appropriate action is to close the connection.
        During text negotiation during FFP, appropriate action is
        to ignore all the negotiations in this sequence of text request
        text response exchanges.

    3.  If possible, use the value of the key in effect before the
        offer (and continue as in point 1).  If not possible, treat
        the negotiation as a failure (and take appropriate action,
        as in point 2).

Perhaps this vagueness is intentional, and all interpretations are
allowed.  However, I believe it would remove a lot of confusion
if the standard said something about what to do next!

Comments?