RE: Problem with use of NotUnderstood in negotiations

["Julian Satran" <Julian_Satran@il.ibm.com>]

Pat,

The current text is explicit in restricting the use of the special values
NotUnderstood, Reject etc.

Julo



                                                                                                                                    
                      pat_thaler@agilen                                                                                             
                      t.com                    To:       bcrane@iready.com, ips@ece.cmu.edu                                         
                      Sent by:                 cc:                                                                                  
                      owner-ips@ece.cmu        Subject:  RE: Problem with use of NotUnderstood in negotiations                      
                      .edu                                                                                                          
                                                                                                                                    
                                                                                                                                    
                      08/09/2002 11:04                                                                                              
                      PM                                                                                                            
                                                                                                                                    
                                                                                                                                    



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:bcrane@iready.com]
Sent: Friday, August 09, 2002 12:33 PM
To: ips@ece.cmu.edu
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:wrstuden@wasabisystems.com]
Sent: Friday, August 09, 2002 9:12 AM
To: ips@ece.cmu.edu
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