Re: [iSCSI]: Key negotiation procedure proposal

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Thu, 23 May 2002, Martins Krikis wrote:

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

That's fine.

> > 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 we do! It's not a flag, but we do have the capability.

I'm not spelled out as clearly as it might be, but here's references from
12-90.

9.12.10 Login Parameters (bottom of page 169)

     All the rules specified in Section 9.10.4 Text for text requests/
     responses also hold for login requests/responses.   Keys and their
     explanations are listed in Chapter 10 (security negotiation keys) and
...

9.10.4 describes how a text response can span multiple PDUs.

9.10.3 shows a text rexponse spanning multiple PDUs.

It's not as clear as I think it should be, but my understanding (which has
been confirmed/developed by EMails from others) is that if you get a login
PDU whose last data byte (not padding, but byte in the data length) is not
a NUL (0x00), you have more coming. You should then send an empty PDU to
the other side, and then you'll get more data.

Works rather well, but should be explained better.

Also, it would be nice if it were stated that sending new key/value pairs
in the "I'm ready for more" PDUs is a protocol error. Otherwise one side
is feeding the other info before the other has had a chance to finish
responding.

Oh, nits: 1) I'm not sure what meaning transit and NSG would have when the
initiator is sending these "I'm ready for more" PDUs. 2) The target
shouldn't set "transit" until its sending the last of an extended-PDU data
transfer.

3) If you are sending data that will span multiple PDUs, you MUST not send
a PDU that has a zero (0x00) in its last data byte. i.e. say you're
sending 12 k, and build an 8k pdu. The very last byte of that 8k must not
be zero, or else the other side won't realize there's more coming.

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

I guess my thought was, do you have to send a packet anyway according to
the protocol. If you're the initiator, no. If you're the target, yes
(you're supposed to respond to the login cmd). If you weren't going to
send a packet anyway, don't send one because of the Reject (and your
decision that the reject is faital to the connection). :-)

Good point about text nego. I think everyone is using the same parsing
innards for both, and we should be careful of having a text nego pull down
a connection. If it has to, it has to. But let's be careful.

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

Devil's advocate question, if you don't understand key=?, would asking for
the other side's values then constitute a negotiation failure? :-)

Sounds like there's more discussion and concensus to be had. :-)

Take care,

Bill