RE: Problem with use of NotUnderstood in negotiations

[Martins Krikis <mkrikis@yahoo.com>]

I absolutely agree. I would not have posted what
I just posted had I known that this is on its way
to the list already. Very well said, Pat.

Martins Krikis, Intel Corp.

Disclaimer: my opinions and not necessarily Intel's.

--- pat_thaler@agilent.com wrote:

> Julian,
>  
> Saying that a violation of a rule is a protocol
> error is not the same as saying that the receiver
> must detect and react to the error. I don't think
> your suggested change to the text changes anything.
> If we want to say that receiving an offer for any
> key (even if the key is not understood) with a value
> of "Reject", "Irrelevant" or "NotUnderstood" MUST be
> detected and treated as a protocol failure, then a
> specific statement to that effect should be added.
>  
> Secondly, there is no requirement that
> re-negotiation MUST be detected. The specific text
> on renegotiation is (for login): 
> If an attempt to re-negotiate/redeclare parameters
> not specifically allowed is detected by the target
> the target MUST respond with Login reject (initiator
> error); if detected by the initiator the initiator
> MUST drop the connection.
> 
> The text for operational negotiation is similar
> except that the actions taken on detection are
> different.
>  
> It says "If an attempt ...is detected" which is
> entirely different than saying such attempts "MUST
> be detected". 
>  
> As Bill as pointed out, detecting re-negotiation of
> unknown parameters is onerous and I am very opposed
> to adding such a requirement. It adds unnecessary
> cost for minimal benefit. For the keys that are
> supported, on just needs a couple of bits per
> parameter to keep track of whether the state is
> unnegotiated, received offer, sent offer or
> negotiation complete and one may need that state
> even if one wasn't going to detect re-negotiation.
> Thus, it is pretty trivial to detect re-negotiation
> of supported keys. 
>  
> If someone wants to maliciously tie up a
> negotiation, they can do so by continuously offering
> new unknown keys and no working non-malicious
> implementation will keep offering the same key. One
> would have to save all
> received unsupported keys and each time an
> unsupported key was received it would have to be
> compared to the list. This is time and memory
> consuming and unnecessary. It isn't required by
> draft 15 and no such requirement should be added.
>  
> A simpler solution to concerns about the silent data
> corruption problem Bill identified is either 
>  
> 1) add in text requiring that an offer the value
> equal to NotUnderstood be detected as a protocol
> error even if the key is not supported/not
> understood
>  
> or 
>  
> 2) rely on timing out the negotiation if it doesn't
> complete after reasonable time or number of
> exchanges (definition of reasoanble left to the
> implementation probably).
>  
> Personally, I prefer number 2 because it will catch
> anything that hangs up a negotiation with one test.
> I don't know that we can find every corner case.
> Even if we could, it is better to have one test that
> digs us out for all corner case errors than to put
> in many specific tests.
>  
> However, number 1 would also be acceptable to me.
>  
> Regards,
> Pat


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com