Subject: RE: Problem with use of NotUnderstood in negotiations

From: [email-masked]
Date: Fri, 9 Aug 2002 14:04:36 -0600

Bart,
 
So the question is, in what order does a device do the checking.
 
There are many possibilites for handling a received key that is 
unknown and comes in with the value unknown:
 
A) Check key
       if key unknown, send key=NotUnderstood
         else ...process key=value pair
 
B) Check key
       if key unknown
         if value=NotUnderstood silently drop (or close connection)
           else send key=NotUnderstood
 
I expect case A is more likely to get implemented in the absence 
of an explicit statement. There would normally be no need to 
examine the value of a key when one doesn't understand the key.
In this case, the receiver never does a test that detects the 
apparent protocol violation of making an offer with a value 
NotUnderstood.
 
So, if we want to stop the loop that Bill has found, we should 
put in an explicit requirement to test the value for NotUnderstood 
before responding to a key with NotUnderstood.
 
The alternative is to leave things as they are and count on 
implementations to abort the negotiation based on a timeout
or a count of excessive number of negotiation PDU exchanges.
 
Regards,
Pat
 
-----Original Message-----
From: Bart Crane [mailto:[email-masked]]
Sent: Friday, August 09, 2002 12:33 PM
To: [email-masked]
Subject: RE: Problem with use of NotUnderstood in negotiations

This new rule is not necessary. 

Sec. 4.2 says: 

   The constants None, Reject, Irrelevant, and NotUnderstood 
   are reserved and must only be used as described here. 

In the situation you describe, the sender will be expecting 
a response to "keyA", but the key-name was corrupted to "keyB". 

The receiver does not understand "keyB", and so responds with 
"keyB=NotUnderstood". 

To the sender, this appears to be the start of negotiating a 
new key, "keyB", with the value "NotUnderstood".  

But, this is not a valid use of the value "NotUnderstood", 
so it is a protocol error. 

So, the new rule of not-responding to keys with the value 
"NotUnderstood" is not necessary. 

Bart. 

-----Original Message----- 
From: Bill Studenmund [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, August 09, 2002 9:12 AM 
To: [email-masked] 
Subject: Problem with use of NotUnderstood in negotiations 

I encountered a problem with how draft 15 specifies using NotUnderstood as 
a reply to keys that aren't understood. Namely if something injects 
garbage into the negotiation stream we can end up with a key BOTH sides 
don't understand, and so they both sit there sending "foo=NotUnderstood" 
back and forth to each other. 

Yes, well-behaved negotiators won't offer a key they don't understand. But 
the data stream can be corrupted, and all it would take is a single-bit 
error in a key name and we encounter the above. 

I propose we change the text to: 

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. If the value for the key was "NotUnderstood", the 
acceptor MUST not answer the key. 

Note: I can easily see closing the connection with an error in the above 
case too. 

Thoughts? 

Take care, 

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Sat, 10 Aug 2002 20:29:14 -0700 (PDT)

> apparent protocol violation of making an offer with a value

Actually, reading the spec, it's worse than that. The spec says if you
don't understand the key, you MUST answer NotUnderstood. Doesn't matter
what the value is, "MUST" is in there. So it's arguable that while case A
isn't what we want, it more closely conforms with the wording of the spec
than does case B.

The problem is that "strange_key=NotUnderstood" looks like two different
protocol issues, we give no guidance as to which one is more important,
and the different issues have different resolutions. One resolution has
MUST attached to it that will lead to more trouble.

> before responding to a key with NotUnderstood.

In my thoughts now, it's more we want a release from the MUST assosciated
with keys we don't understand. I've changed my mind since I first posted.
I now think the best thing to do is say if you get a key you don't
understand and its value is NotUnderstood, you call it a protocol error.
That way it doesn't matter if you look at the key or the value first, you
arrive at a protocol error (and you sending nothing) either way.

Take care,

Bill