Re: [iSCSI]: Key negotiation procedure proposal

[Martins Krikis <mkrikis@yahoo.com>]

I'm gonna skip most of what I already commented
on in response to Luben.

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

That's the problem---the "negotiation step".
Currently a step is basically PDU-wide. You cannot
force the other side to hold off answering before
you've sent all the data that you want processed
together. Since we need to know what physically
went out on the wire and what didn't (to be able
to process reception of same keys properly), we
cannot just leave ready-to-be-sent text sittin
in buffers. We cannot prepare a key=value unless
we're sure it will fit. That's true in general,
not just for this key=Reject\0Key=BetterValue\0
situation. I think we need a flag there to tell
the other side to hold off processing. No replies
necessary until the flag goes off.

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

I don't know, but it doesn't sound simple anymore.
It would be good to preserve symmetry. And actually,
we probably shouldn't talk about closing the
connection too much as negotiation reset or Reject
PDU are similar alternatives for Text Requests/Rsps.

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

I didn't intend this to fit in with Luben's 
definitions but with the current ones. The
O: key=? is meant to be entirely optional, in fact.
Anyway, I don't need this, but I think it is a
more natural way to get the "other side's values".

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

That's now simple. There is no renegotiation possible.
Empty requests discouraged, so it should not take
too long. There are no strict guarantees (and would
not be even with Luben's proposal) because of
empty requests/responses. In general, a counter
of "negotiation rounds" and an upper bound is
simpler than extra rules. In fact, I don't mind
the no-renegotiation rule thrown out altogether.
All I ever wanted was that if it's used then it's
used for everything (including reserved values).

Take care,

  Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be
            those of my employer


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com