Re: [tcpm] Some comments on tcpsecure

[Joe Touch <[e-mail]>]

Fernando Gont wrote:
> At 04:55 p.m. 04/04/2008, Joe Touch wrote:
> 
>>> The first one is the ICMP attacks draft 
>>> (draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the security 
>>> implications of ICMP on TCP conenctions, it does not reference the 
>>> I-D. IIRC, this had already been pointed out by Joe (?). As far as 
>>> the specifications are concerned, you shouldn't bother to fix 
>>> TCP-based reset attacks if you don't fix the the ICMP-based ones.
>>
>> Agreed; should this doc recommend filtering out ICMPs as a result? 
>> (there's no in-window checks that are meaningful, since ICMPs are not 
>> guaranteed to be timely) I.e., something stronger than "there's 
>> nothing we can do", which is what is implied in the current security 
>> considerations.
> 
> Ha... So we have been arguing about the ICMP stuff for almost four years 
> on the idea that it is too aggressive to require ICMP error messages to 
> be in-window, and now we're going to propose to filter them out? 

ICMPs are already filtered out for security reasons at firewalls. The 
key here is whether to recommend that action or not.

As to filtering them when they're in- vs out- of window, the issue there 
is whether that even means anything. The point is that with arbitrary 
delays, the location of an ICMP's TCP header with respect to the current 
outstanding window has no useful meaning, so it cannot (and thus should 
not) serve as a useful descriminator.

 > Seems
> ironic to me. (And you cannot do it with "frag needed and DF bit set". 
> Well, you *could* implement the new PMTUD that does not rely on ICMP 
> error messages. But ignoring ICMP error messages will increse the PMTUD 
> convergence time).
> 
> And, for what is worth, strictly speaking there's no such a thing as a 
> TCP MSL, either. TCP's MSL is based on the assumption that the IP TTL is 
> decremented at least once every second. And this is not warranted, 
> either. There's not such enforcement as there is in, e.g., Delta-t.

If there's no MSL, then that's even more reason not to use window 
information to determine the validity of an ICMP. At that point, not 
only might you be receiving a very old ICMP, you might be receiving a 
very recent ICMP for a very old TCP segment.

>>> The other doc is the port randomization draft 
>>> (draft-tsvwg-port-randomization).
>>
>> Also ISN randomization (RFC-1948), for similar reasons. Even though 
>> some of the RST attacks span the entire window, knowing the ISN can 
>> help during the initial handshake and shortly thereafter.
> 
> Agreed. (Although the math in "Slipping in the window" does not assume 
> the attacker can predict the ISN).

Right - it's not nearly as important as the port randomization for this 
case.

Joe

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm