Subject: RE: iSCSI: invalid key value

From: "LEMAY,KEVIN (A-Roseville,ex1)" <[email-masked]>
Date: Fri, 25 Jan 2002 10:01:29 -0700

This is an area that is open to interpretation in the spec.

My interpretation is:

Any parameter defined in appendix D can only have the values represented in
the appendix. To offer any thing not defined in the spec for these well
defined parameters is a format error. The first option offered is an invalid
one, thus a format error has occurred.

If newer options are added to the spec, then they would be defined for that
revision and see no problem. The values offered must be consistent with the
version number sent in the login request. If new key values are added to a
spec and the initiator supports a range of versions. Only key pairs and
values common to the requests versions should be offered. If this is not
true, then the spec needs to be updated to make it clear that not understood
key values should be passed over and only rejected if no valid option
exists.

The spec is clear on the behavior when a format error occurs. A target
should reject the login and close the connection.

On further review, NotUnderStood is not the correct response. The correct
response would be: "DataDigest=Reject"

Kevin Lemay
Agilent Technologies

-----Original Message-----
From: Mark Bakke [mailto:[email-masked]]
Sent: Friday, January 25, 2002 8:28 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: iSCSI: invalid key value

Kevin-

How can this be rejected, if at least one of the values
is understood and supported?  One of the original reasons
to negotiate digest methods, authentication methods, and
such is so newer methods can be added to iSCSI as they
become available.  If I have an initiator that sends:

DataDigest=LatestGreatestDigest,CRC32C,none

and a target that supports CRC32C, it should pick CRC32C,
rather than sending back a notunderstood.  This way, the
initiator can say what it wants, and the target can pick
from the set of methods it supports.

If we let the target reject these, we will degenerate
iSCSI login into a "try this, nope, try that, nope, then
let's try this" sort of negotiation:

I->T DataDigest=LatestGreatest,NextBestThing,CRC32C,none

T->I reject

I->T DataDigest=NextBestThing,CRC32C,none

T->I reject

I->T DataDigest=CRC32C,none

T->I DataDigest=CRC32C

The initiator had to guess at which value the target didn't
like, then keep trying to log in with different sets of
methods until they were reduced to the subset known by the
target.  This would default the purpose of having a relatively
simple negotiation for these things.

Steve is right, the only good way to do this is to accept
the value that's understood, even if it's "none", rejecting
only if none of the values are understood.  If the initiator
didn't want "none", it shouldn't have offered.

BTW, if "CRC32C" is corrupted into "#$C32C", we will have
much worse problems than text key corruption, and trying
to get around it this way will not work.

--
Mark

[email-masked] wrote:
> 
> I disagree,
> 
> This is an initiator error and the login should be rejected as such.
> NotUnderStood should be returned in the key with the login rejected.
> 
> Kevin Lemay
> Agilent Technologies
> 
> -----Original Message-----
> From: Steve Senum [mailto:[email-masked]]
> Sent: Friday, January 25, 2002 7:57 AM
> To: ietf-ips
> Cc: Eddy Quicksall
> Subject: Re: iSCSI: invalid key value
> 
> Eddy,
> 
> If someone sends me "DataDigest=#$C32C,none".
> I will respond "DataDigest=none".
> 
> I think responding with "DataDigest=NotUnderstoood"
> or one of the other special responses would be wrong,
> as there is nothing wrong with the key ("DataDigest").
> 
> Since I support "none", and can't tell "#$C32C"
> is really "CRC32C", I believe "DataDigest=none"
> is the only correct response.
> 
> Steve Senum
> 
> -----------------------------------------
> Subject: iSCSI: invalid key value
>    Date: Fri, 25 Jan 2002 10:17:12 -0500
>    From: Eddy Quicksall <[email-masked]>
>      To: "ips@ece. cmu. edu (E-mail)" <[email-masked]>
> 
> If a key has a value that is not valid, do you know how I respond?
> 
> 
> 
> For example, DataDigest=#$C32C,none. The valid values are CRC32C,none.
> 
> 
> 
> If I say DataDigest=NotUnderstood, wouldn't that mean the key was not
> understood?
> 
> 
> 
> If I say DataDigest=Reject, that would mean I don't support the key for
the
> current initiator.
> 
> 
> 
> If I say DataDigest=Irrelevant, that would mean the digest is not relevant
> for
> the current negotiation.
> 
> 
> 
> If I say DataDigest=none, that would mean I don't support CRC32C when in
> reality
> I do. It could be that, since there is no digest in login,
> the 1st two letters got changed.
> 
> 
> 
> If I treat it as a protocol error and send a response with status == 0200
or
> 0201, then the initiator does not know why.
> 
> 
> 
> Eddy

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Steve Senum <[email-masked]>
Date: Fri, 25 Jan 2002 11:17:50 -0600

The spec also says:

        Proprietary algorithms MAY also be negotiated for 
        digests. Whenever a proprietary algorithm is negotiated, 
        "none" or "CRC32C" should be listed as an option in order 
        to guarantee interoperability.

I would consider any option not recoginzed as proprietary,
and simply ignore it.  I would only send "DataDigest=Reject"
if I don't support any of the options.

Steve Senum

---

From: Mark Bakke <[email-masked]>
Date: Fri, 25 Jan 2002 11:05:28 -0600

> one, thus a format error has occurred.

This makes the iSCSI draft non-extensible through other drafts.
There are a lot of value-added things that can be done, either
by other drafts/RFCs adding new methods to iSCSI, or through
vendor-specific methods.  The iSCSI revision number has little
to do with text keys; it is primarily a PDU format version
number.  If we have to change the base iSCSI spec and version
every thing a new authentication method is made available,
for example, we will be turning out too many big RFCs.  Better
to have a good, extensible "base" iSCSI protocol, and add
new authentication or digest methods through separate RFCs.

Otherwise, we would have done better to keep the login exchange
as a set of binary keys and values, instead of text.

> key values should be passed over and only rejected if no valid option

I disagree.  This makes it too difficult to add new methods to
the iSCSI protocol.  A new PDU format revision should not be
necessary to add an authentication method.

> response would be: "DataDigest=Reject"

This response should be sent only if NONE of the offered methods
are supported.  If any method offered is recognized and supported,
that method will be returned by the target.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Mark Bradley" <[email-masked]>
Date: Fri, 25 Jan 2002 11:04:36 -0700

Kevin is generally correct.  However, it should be possible to have
in Appendix D such things as 'vendor-defined' and 'reserved' as well.
I think this may address Steve S. and Mark Bakke's issues.
  --  markb

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> LEMAY,KEVIN (A-Roseville,ex1)
> Sent: Friday, January 25, 2002 10:01 AM
> To: 'Mark Bakke'; LEMAY,KEVIN (A-Roseville,ex1)
> Subject: RE: iSCSI: invalid key value
>
>

---

From: Paul Koning <[email-masked]>
Date: Fri, 25 Jan 2002 13:56:26 -0500

I think the statement in the spec that "proprietary digest algorithms
may also be negotiated" settles the matter for the case of the digest
negotiation: an unrecognized value means a proprietary algorithm you
don't know of, and clearly you have to keep scanning for another value
that you *do* support.  You can't just quit immediately, because that
would conflict with the rule permitting proprietary key values.

For other keys, that reasoning doesn't necessarily apply (i.e., if
proprietary key values aren't explicitly listed as legal).

You can then do one of two things:

1. Insist that the receiver should be extremely picky.  If so, then
you will *force* a version number change for every tiny change in the
set of allowed values.  

2. Expect the receiver to ignore values it doesn't understand, and not
complain so long as one of the alternatives offered is one it *does*
both understand and support.

This is an application of the protocol design principle "be strict in
what you send, lenient in what you receive".  It's not an absolute
rule, but as a design guideline it has served well for many decades.
One reason why is that it eliminates the need to change version
numbers except when you make "large" changes to the protocol.
Nitpicking changes like adding new alternatives for keys are not
changes that require version number incrementing, provided that you
use this rule.

Having had to deal with both approaches, I am strongly of the opinion
that #1 is a bad idea and #2 is the only correct approach.

     paul