Re: [iSCSI]: Key negotiation procedure proposal

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Thu, 23 May 2002, Luben Tuikov wrote:

> I'm proposing the following key negotiation procedure. It
> preserves the no-renegotiation of keys rule and all the
> rules of login request and response currently used in the
> draft (12-91). It applies to any kind of value (list,
> boolean, integer, etc.).
>
> Simple implementations:
>
> Simple implementations SHOULD close the connection right
> after Reject has been communicated. This ensures that the
> reason for closing has been communicated to the peer.
>
> Regular implementations:
>
> Core rule: A negotiation of a key=value pair is
> complete/finished when both the Originator and Responder
> have sent their values (non-reserved keywords).
>
> The core rule implies the the following:
>
> If a Responder replies with Reject, then the Originator
> SHOULD NOT renegotiate the rejected key.
>
> If a Responder replies with Reject, it SHOULD sent its value
> of that key on the next reply to the Originator.

My only concern with this is that we now have to keep more state around;
we have to remember to send the key next negotiation, and the other side
has to know to send a blank message as part of that next negotiation.

Instead, why not just send it later in the first message?

> If an Originator finds the response to an offered key=value
> pair to be unacceptable, it SHOULD send Reject and close the
> connection.
>
> Please note that the core rule above ensures that both the
> Originator and Responder _know_ each other's values if the
> connection is closed due to Reject. This will give the user
> of each node more information to find out what went wrong.
> That is, this kind of negotiation is exhaustive.
>
> Let O: denote Originator and R: the Responder.
>
> Example 1:
> ----------
> O: v = x  -->
>          <--   R: v = Reject
>
> O: ""     -->
>          <--   R: v = y

i.e.

O: v = x  -->
         <--   R: v = Reject
         <--   R: v = y

We 1) make the negotiations happen faster, and 2) can keep less state
around (O doesn't need to send "", and R doesn't need to remmeber to send
v = y next time).

All the implementations I've seen break the login text up one key/value
pair at a time, so seeing the same key twice won't cause a problem AFAICT.

> O: 1) v = y is OK, continue as normal,
>    2) v = y is unacceptable,
>
>    v = Reject -->
>    close the connection (reason just given).
>
>
> Example 2:
> ----------
> O: v = x  -->
>          <--   R: v = y
>
> O: 1) v = y is OK, continue, as normal,
>
>    2) v = y is unacceptable,
>
>    v = Reject -->
>
>    close the connection (reason just given).

Except for the above, looks good.

Take care,

Bill