Re: [iSCSI]: Key negotiation procedure proposal

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Thu, 23 May 2002, Martins Krikis wrote:

> Bill, Luben,
>
> Sorry, my previous response was already somewhat dated. Hard to keep
> up with you. :-)

Heh!

> > 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.
>
> Does it mean it should not send or does it mean "should not send
> with a non-reserved value"?

I took it as "should not send with a non-reserved value". The Originator
either gets to accept that the Responder can do, or it shuts down the
connection.

I'm afraid that if we don't do something like that, we can end up with
negotiations that don't terminate or converge.

> > If a Responder replies with Reject, it SHOULD send its value
> > of that key in the same reply PDU to the Originator after the
> > key=Reject pair.
>
> There is the problem that it may not fit. If we leave it for the
> next round, we have to remember that the state for this key is such.
> In order to avoid this problem, we could use the key only once,
> but use a list of values: first element "Reject", next elements
> whatever was the value (or value list) that the Responder would
> like. But, that's another big complication, so I am NOT proposing it.

I think we need some more terminology.

When you support SPKM and Kerberos authentication protocols, you must be
able to receive 64k of text. This text is going to come in multiple PDUs.

What do we want to call this blob of text? Stage? SO the above would be:
"If a Responder replies with Reject, it SHOULD send its value
of that key in the same reply *stage* to the Originator after the
key=Reject pair."

?? Another word? Yes, it can be in a different PDU, but it has to be in
the same negotiation step.

> > If an Originator finds the response to an offered key=value
> > pair to be unacceptable, it SHOULD send Reject and close the
> > connection.
>
> But then the Responder (who both Reject-ed and responded to the key)
> must remember that it not only sent the key but also rejected the
> key, i.e., sent a value that does not necessarily fit in the selection
> rules and which is not guaranteed to be liked by the Originator,
> because if it is not liked, this Originator most likely will
> send a Reject, which is not to be treated as a no-renegotionation
> violation but just as a harmless little Reject.

Maybe what we sould do is if the originator is the initiator, when it
choses to reject, it closes the connection. Only when the originator is
the target does it then send a Reject key. It also returns a non-zero
status indicating that the connection is ending. That way we perform the
minimum steps required by the protocol to end things.

> Thus, I think we need more state for this. But we gain the knowledge
> of what values the other side likes. I like the latter feature
> of course, but hate introducing more state. Plus I was getting
> to feel happy about the current situation.
>
> If the goal of this is to have a way to figure out what the other
> side likes, perhaps it is simpler to reinstate the "key=?"
> syntax, with the changed semantics, that the Responder must
> send its acceptable values (not current). This would not count
> as a start of a new negotiation, of course, so no extra state here.
>
> I.e.,
>
> O: k=u,v,w                   (I want (in order of preference) u, v or w)
> R: k=Reject                  (But I hate all of those)
> O: k=?                       (What do you like then?)
> R: k=x,y,z                   (I like (in order of preference) x, y and z)

That wouldn't work with Luben's definitions. We could change them to make
it work, but I'm not sure if it's worth it. We'd be opening up the
non-convergence potential problems.

While I think the key=? syntax can be useful, I'm not sure if we want to
use it as above. I'm just not sure how to enforce that negotiations
terminate.

Take care,

Bill