Re: [tcpm] Some comments on tcpsecure

At 10:02 p.m. 05/04/2008, Joe Touch wrote:

>>>         TCP *has* an MSL requirement (RFC793)
>>>                 this means that TCP segments should not live
>>>                 in the network beyond approx 2 minutes
>>Yes, and this requirement cannot be met, as it is based on the 
>>assumption that the IP TTL can be enforced. (Not to say that the 
>>MSL sort of imposes a requirement on the TTL you set in IP packets. 
>>If you set a TTL of say 240, then the TTL becomes 4 minutes, and 
>>2*MSL becomes eight minutes.
>>As a result, if anything, this is as incorrect as requiring ICMPs 
>>to be in window. Well, unless you run TCP on anything other than IP....
>
>If you want to win this part of the argument, then - as you note - 
>window information is never useful within TCP. What's the point of 
>this straw-man?

That if you want to be picky, that's where you should probably start. 
You talk about how incorrect it would be to enforce ICMP messages to 
be in-window... but even the most basic timing assumptions in TCP are 
not "correct", either.

Yes, "It just works". But that does not imply "correctness".

[...]
>>>As a result, it remains incorrect to validate a TCP segment inside 
>>>the ICMP as needing to be "in window".
>>If there's an error, the the window won't advance, and in the event 
>>the window does advance, then the error was not really "hard". And it would
>>have been incorrect to abort the TCP connection. (see e.g., Clark's paper).
>
>The ICMP error isn't "TCP failing to make progress" - if you want 
>that one, please create a new ICMP error type. Whether you do or 
>not, please stop trying to imply those semantics to the current ICMP errors.

We're not here to re-hash history, are we?

>>There's no code that runs what you're describing, Joe. Everybody is 
>>doing what is described in the ICMP attacks draft.
>
>Popular vote does not determine correctness. Part of the problem is 
>that there are some people who've deployed prototype code and 
>convinced everyone it's appropriate. That is NOT how protocol 
>specifications are determined.

There's a recent and wonderful book by old-timer John Day, in which 
he explains that the internet protocols themselves were what you call 
"prototype" (and I'm referencing that particular book just for the 
fact that the author is great, and I love his book). So... I find 
your comment a little bit ironic. :-)

Kind regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm