Re: iSCSI: invalid key value

[Mark Bakke <mbakke@cisco.com>]

"LEMAY,KEVIN (A-Roseville,ex1)" wrote:
> 
> 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.

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.

> 
> 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.

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.

> 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"

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

> Kevin Lemay
> Agilent Technologies
> 
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Friday, January 25, 2002 8:28 AM
> To: kevin_lemay@agilent.com
> Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com
> 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
> 
> kevin_lemay@agilent.com 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:ssenum@cisco.com]
> > 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 <Eddy_Quicksall@ivivity.com>
> >      To: "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
> >
> > 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
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054