Subject: Re: [iSCSI]: Key negotiation procedure proposal

From: Martins Krikis <[email-masked]>
Date: Thu, 23 May 2002 16:33:01 -0500

Bill, Luben,

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

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

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

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

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)

  Martins Krikis, Intel Corp.

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

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 23 May 2002 15:13:03 -0700 (PDT)

> Sorry, my previous response was already somewhat dated. Hard to keep

Heh!

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

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

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

> 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

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 23 May 2002 18:08:34 -0400

> with a non-reserved value"?

It means that the Originator SHOULD NOT send any
more offers. (key=another-value(s))

> There is the problem that it may not fit.

Yes, Randy mentioned this already and gave an excellent
example.

Well, this is an open question. Anyone?

> key, i.e., sent a value that does not necessarily fit in the selection

NO! it must only remember the value of the key it sent!
The Originator will 1) close the connection with Reject,
2) accept the value quetly. (I can know, implied rule 1,
but we have to STOP somewhere or we'll never get to 
FF phase :-))

> violation but just as a harmless little Reject.

key=Reject is never considered renegotiation, since there is no
valid value being offered!
 
> to feel happy about the current situation.

Oh, well, there is the ``simple implementation'' rule.

Please remember that there is always the ``simple implementation''
rule (compatible with ``regular implementation'').

If the people feel comfortable with the logic then, some
may implement ``simple'' others may implement ``regular'',
both will interoperate and will get the job done.
 
> R: k=x,y,z                   (I like (in order of preference) x, y and z)

This will never work since  ``k(R) Intersection k(O) = Empty''.
If it did, then O: cheated in its offer! (and should be banned
from operating ;-))

-- 
Luben

---

From: Martins Krikis <[email-masked]>
Date: Thu, 23 May 2002 16:58:37 -0700 (PDT)

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

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

> minimum steps required by the protocol to end

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.

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

> use it as above. I'm just not sure how to enforce

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,

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

---

From: Martins Krikis <[email-masked]>
Date: Thu, 23 May 2002 16:34:11 -0700 (PDT)

> more offers. (key=another-value(s))

I knew. I should stop putting requests for more
precision in the form of questions to which I know
the answers. My fault.

> Well, this is an open question. Anyone?

We can mandate that if the DataSegment does not 
end with a \0 (which would mean that all included
key=value pairs are complete and terminated),
then it should not be processed yet, but the
next piece waited for to be concatenated with.
And we'd drop the need to send PDUs in the other
direction. This would be even better achieved
with a flag in the header.

I.e., if a (new) flag is set in the header of a
Text/Login Request/Response PDU, then it means
that more such PDUs are coming and their data
is to be concatenated together (once the flag
is unset in the last one) before processing.
This would in fact allow a nice separation of
the negotiation logic from the en/de-capsulator.
(For example, if willing to send lots of values,
the sender just dumps them to the encapsulator
instead of worrying how many will fit and how
many will need their state adjusted to be sent
next (can't just mark them sent yet, because
there may be surprises if they arrive)).

In general the possibility of split data is a
pain and any way to alleviate this pain would
be very welcome by many, I suspect.

> NO! it must only remember the value of the key it

You don't have to object yet, it gets clearer at
the end of my paragraph.

> but we have to STOP somewhere or we'll never get to 

Stopping is not a problem. There is no renegotiation.
Anyway, I've lost track here a little of what you're
saying.

> valid value being offered!

For me seeing a key twice raises big red alarms.
I look at the key first, IMHO, naturally.
key=Reject is also wrong as an offer, so in order
to allow for receiving it (w/o big red alarms either
due to renegotion or due to "Reject in offer"), we
have to prepare first. So we need more state than
currently (for the ultra-fine implementations
at least). And yes, connection will have to be
closed, yet I'd like to know precisely the reason
why.

> rule (compatible with ``regular implementation'').

And it is compatible with the current state of
affairs as well. In fact, it is subsumed by the
current protocol. It already allows Reject-ing a
key and then closing the connection. Wait, there
might be nuances for text vs. login. Anyway, very
minor differences if any between your "simple 
implemention" and what would be currently already
allowed.

> both will interoperate and will get the job done.

Yes, but "regular" could, IMO, stay as it is.
I now hold the view that there are no renegotiations
possible. If other people don't, we have to keep
asking Julian to clarify yet again and put it in a
very visible place in the draft. 

> If it did, then O: cheated in its offer! (and should

I didn't say it would work. I know the intersection
is empty. I tried to show that learning what values
the other side may like is more naturally done with
inquiries than with forced depositions. The only
improvement that I see from your proposal is that in
case a value gets Reject-ed, the sender knows what
values the other side would have liked. (Because
most other things have been taken care of, I think.)
But that effect can be achieved by an inquiry, not
by protocol changes that require more state.

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

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 23 May 2002 18:19:45 -0700 (PDT)

> I'm gonna skip most of what I already commented

That's fine.

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

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

> 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

---

From: Martins Krikis <[email-masked]>
Date: Thu, 23 May 2002 19:27:25 -0700 (PDT)

> But we do! It's not a flag, but we do have the

The capability to send our pairs in multiple PDUs
yes, but we don't have the capability to stop
the other side from responding to the first ones
seen while we haven't sent all that we were planning
to send yet.

> the other side, and then you'll get more data.

I haven't seen a requirement to send an empty PDU.
In fact, since I view all keys as independent, I'm
sending however much I can send in each an every
PDU, not waiting for the other side to finish up
and send a PDU ending in a NUL byte. I.e., I will
not send you blank PDUs as a favor, because the spec
hasn't required me to do so and I didn't think it
was needed. I thought I was saving time by sending
PDUs with my responses (to what can be responded to).
I now realized that I had a problem by leaving
stuff sitting in buffers but marking it as sent.
I can fix it, but I see that the protocol allowing
this is what's making it messy. So, if we were
required to use blank PDUs until the other side
sends us something ending in NUL, things were
actually great. Still, not as good as an explicit
flag, since data has to be looked at, not just
stored away, but decent. However, the requirement
for a blank PDU has escaped me if it exists.
Somebody please enlighten me.

> is feeding the other info before the other has had a

Yeah, so I'm afraid it is not a protocol error
currently. If it is, I'm happier already.
Then, of course, we could say that blank PDUs
aren't even necessary, the sending side can just
send all PDUs that it had to send.

> shouldn't set "transit" until its sending the last

NSG=CSG and no T/F flag
set (until possibly the last of thos PDUs).

> be zero, or else the other side won't realize

This I know and was observing diligently. But I
don't believe there is a requirement for the
other side to refrain from sending data and
to send just blank PDUs.

Looks like we need some clarity here.

> the other side's values then constitute a

Asking would be legal, but the other side will
likely not see it that way. Anyway, I am NOT
seriously proposing this.

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 23 May 2002 20:01:22 -0700 (PDT)

> seen while we haven't sent all that we were planning

We will need to define it as an error.

> I haven't seen a requirement to send an empty PDU.

It's not written anywhere. All I can say is that: 1) the sample for text
negotiation (9.10.3) shows empty PDUs, and 2) if we don't do it,
negotiation becomes a REAL mess. :-)

> Somebody please enlighten me.

A flag would be fine too.

I think we definitely need a better description of how it's suppsoed to
work..

> send all PDUs that it had to send.

I think we should make it an error. :-)

> set (until possibly the last of thos PDUs).

If no T bit, NSG == reserved = 0.

The last one of a set of PDUs should probably reflect the desired state.

> Looks like we need some clarity here.

Indeed. :-)

> seriously proposing this.

Ahhh.. Ok. :-)

Take care,

Bill

---

From: Martins Krikis <[email-masked]>
Date: Thu, 23 May 2002 20:20:54 -0700 (PDT)

--- Bill Studenmund <[email-masked]>

> negotiation becomes a REAL mess. :-)

Agreed.

> I think we should make it an error. :-)

Yes, we should make it an error.

And on a second thought, having the blank PDUs
travelling in the other direction is perhaps
even simpler than allowing nothing to go in
the other direction; at least it does not require
changes to the text in this regard.

So I'm for requiring blank PDUs in this case.

> If no T bit, NSG == reserved = 0.

But does it even matter what NSG is in this case?
Either way is fine with me.

> reflect the desired state.

Yes.

We may have to change the subject to make this
post noticable. I doubt too many people are
following the current subject at this point.

Disclaimer: my opinions, not necessarily Intel's.