SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    
    
    
    
    
    
    
    


Home

Last updated: Sat Aug 10 01:18:59 2002
11601 messages in chronological order