Subject: RE: Problem with use of NotUnderstood in negotiations

From: "Julian Satran" <[email-masked]>
Date: Sun, 11 Aug 2002 07:39:54 +0300

Bill,

My only intention in the note was to be brief.  If you viewed that as rude 
I am really sorry.
I have a lot of mail to reply to and a limited time.

As for the crux of the matter - if one of the parties receives a key it 
has not seen before
with NotUnderstood as value it MUST act on it as a protocol error. The 
text is unambiguous on this.
However we may want to strengthen the rule in 4 (and add another line of 
text) as follows:

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are 
reserved and MUST ONLY be used as described here. Violation of this rule 
is a protocol error (in particular the use of "Reject", "Irrele-vant", and 
"NotUnderstood" as proposed values).

In the second part of my comment I was just saying that if you  failed to 
implement the above check you still can't enter a loop
because the double negotiation rule.

To get you in a loop in which every party think it answers - then either 
both are buggy or somebody is altering the messages maliciously.
The protocol is not designed to handle either.

Julo

Bill Studenmund <[email-masked]>
08/11/2002 06:11 AM

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     <[email-masked]>
        Subject:        RE: Problem with use of NotUnderstood in negotiations

On Sat, 10 Aug 2002, Julian Satran wrote:

> Bill,
>
> Perhaps the text is unabiguos but you just ignored the text that forbids
> it.

Julian,

I must say that the tone above is very unbecoming of the author of a
protocol spec. In the past, I've often gotten snippy comments from you,
but written them off to, well, I'm not sure what. But it seems that you
really don't listen to what I say. You read a message, make an
interpretation, do not question that interpretation, and then you run with
it. That's really bad. Besides being quite rude and exceedingly arrogant,
you'll miss things. And the iSCSI spec will suffer for it. Do you think
whatever is going on between us worth more than a bad iSCSI spec? I don't.

Also, if you're going to say that the text is unambiguous, please quote
said text. That makes the discussion much clearer.

> The use of Notunderstood is limited to responses. Using it as you 
suggest
> is a protocol error.

Julian, I have to ask, what exactly do you think I'm suggesting? From
parsing your sentence, I read that you are telling me that I'm suggesting
using NotUnderstood outside its limited scope, of responses.

As I understand the situation I described, both parties think they are
using NotUnderstood as a response. How is using it as a response outside
its use as a response?

> A repeated use will also violate the "no renegotiation rule".

Please be VERY VERY VERY careful when saying that. Have you thought about
what the statement you just made will imply?

We are (or at least I started) talking about the case where one side
THOUGHT it sent key X, but somehow it was key Y that made it to the other
side. Be it a bug in the code on one side or the other, a PCI bus error in
transfer, a router glitch, or what. Key Y doesn't exist in the spec, and
it's in the negotiation stream. OGMarker or DataPDPInOrder would be
examples.

The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't
understand. Reading the spec, it succinctly states if you get a key you
don't understand, you MUST reply "NotUnderstood".

Getting back to the "repeated use is a protocol violation," how is each
side supposed to realize that they are seeing "OGMarker=NotUnderstood" for
the second time, other than by remembering that it saw OGMarker as a
not-understood key. i.e. by in addition to replying, "NotUnderstood", each
side has to remember that it responded NotUnderstood to key foo. That
seems unwise. I can think of at least one DoS attack if that really is
what implementations do.

Getting back to addressing the topic of the thread, what is wrong with
this text, slightly modified from the I proposed in the first message?

***
Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST
be considered a protocol violation.
***

As I said before, my main interest is the spec point out that if for a key
you don't understand you get the value "NotUnderstood" (i.e. the other
side is telling you it didn't understand a key that it turns out you also
don't understand), you don't just answer "NotUnderstood". Either
saying nothing, or considering it a protocol violation (since if we both
didn't understand the key it should have never gotten into the
negotiations) are both fine options. I now favor protocol violation as if
neither side understood the key, it should not be there. If it's there,
something is wrong.

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Sat, 10 Aug 2002 21:57:46 -0700 (PDT)

> I have a lot of mail to reply to and a limited time.

And my appologies if I saw rudeness that was not intended.

> "NotUnderstood" as proposed values).

Ok. That would work. Also see my proposed text that crossed this one in
the mail.

> The protocol is not designed to handle either.

But do we need to remember keys we didn't understand? I hadn't taken that
away from the spec before now; I (and others, as evidenced by code :-)
thought it was safe to just respond and be on with it. For the
double-negotiation rule to catch it, we have to remember them.

Is that really what we want? I have this unplesant image of one side
wanting to try a whole lot of vendor keys (different vendors), and the
other side being a simple negotiator and getting overwhelmed.

Take care,

Bill