[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    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 []
    Sent: Friday, January 25, 2002 8:28 AM
    Subject: Re: iSCSI: invalid key value
    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:
    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 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 []
    > 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 <>
    >      To: "ips@ece. cmu. edu (E-mail)" <>
    > 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
    > 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
    > 0201, then the initiator does not know why.
    > Eddy
    Mark A. Bakke
    Cisco Systems


Last updated: Fri Jan 25 13:18:07 2002
8477 messages in chronological order