RE: iSCSI: invalid key value

["Mark Bradley" <markb@indstorage.com>]

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

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> LEMAY,KEVIN (A-Roseville,ex1)
> Sent: Friday, January 25, 2002 10:01 AM
> To: 'Mark Bakke'; LEMAY,KEVIN (A-Roseville,ex1)
> Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com
> Subject: RE: iSCSI: invalid key value
>
>
> 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: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
>