RE: Problem with use of NotUnderstood in negotiations

[pat_thaler@agilent.com]

Julian,

I agree that the current text is explicit in restricting the use of the special values. In the scenario suggested each device is using NotUnderstood as the text requires.

Where the ambiguity arises is what checking one does on values of a key that one doesn't understand. When you are doing a series of tests for validity and the first one fails, do you take the action that failure requires or do you first do some of the following tests? Usually one would do the former unless there was an explicit requirement to do additional tests.

I don't find anything in the current text that requires checking the value when one receives an not understood key. Furthermore, I don't think it is necessary to require such a check. 

The scenario that was brought up was a corner case that hangs up login. There can be other corner cases we haven't discovered yet. It makes more sense to deal with it by timing out a negotiation that goes on too long (in time or number of exchanges) than by making a special rule for this particular corner case.

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 09, 2002 9:11 PM
To: ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations



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