Re: iSCSI: invalid key value

[Steve Senum <ssenum@cisco.com>]

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

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