Subject: RE: iSCSI: invalid key value

From: [email-masked]
Date: Fri, 25 Jan 2002 09:23:10 -0700

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

---

From: Mark Bakke <[email-masked]>
Date: Fri, 25 Jan 2002 10:27:36 -0600

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

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