Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt

[Fernando Gont <[e-mail]>]

Joe Touch wrote:

>> Well, if you track the decision, you'll probably go back to an IETF
>> meeting in 2005 (Vancouver), in which, while we were heading for Std.
>> Track, somebody asked "Why not Informational?", and that's what we ended
>> up doing. So...
> 
> That decision was discussed at length at multiple IETFs. It didn't
> happen as an accident or by the direct consequence of a single
> off-handed suggestion.

I disagree. But at this point in time, this is off-topic.



>> The TCP spec says that "ICMP hard errors should be processes as RSTs",
>> but never describe a case in which a TCP would send an ICMP hard error
>> instead of a RST.

I already argued that the only ICMPs that you really need are the "frag
needed" ones.



> If frag is needed, you can't get a RST since the packet never gets
> there. If the port is blocked upstream of the end device, the same thing
> happens. Your next sentence appears to assert that the latter is the
> common case.

If the packet had elicited an RST if it had been received at the
intended destination, the connection will probably time-out (i.e., it
was a data segment... unless you're implying that a simple ACK does not
fit into the PMTU).



>> If you ever get an ICMP hard error, it's probably because of a firewall.
> 
> If it's after a connection is established, it's likely because of a
> change in path that has different firewall policy or MTU.

Exactly. In which case that should be a *soft* error (who said the path
is not going to change back to the old one?).



>> And many of these devices do not even check the TCP checksum.
> 
> Nor should they. The ICMP packet isn't required to include the entire
> TCP segment, and when it doesn't it *can't* verify the checksum anyway.

Exactly. And this hurts the precious TCP robustness you have always been
defending.


>> And, if you really depend on anything to flush stale connections, you're
>> vulnerable to a bunch of other attacks (Sockstress, and the rest of the
>> stuff that is already discussed in the CPNI TCP security paper).
> 
> My point was simply that TCP doesn't always clean itself up via
> timeouts. That could be changed, but requires a change to the TCP spec
> to, e.g., require all TCP connections to default to "keepalive", and
> that hasn't been discussed.

Keepalives are not even part of the spec.



>>> It's difficult to argue for broader controls of ICMPs in the absence of
>>> authentication at the IP or TCP level, since RSTs have just as injurious
>>> an impact.
>> C'mon, Joe. ICMP must have an in-window TCP SEQ. ICMPs need not. We've
>> been here before. So the ICMP attack vector is the low hanging fruit.
> 
> There are numerous ways to upset a TCP connection by injecting bad data,
> causing it to emit extra ACKs, etc. And the difference between in and
> not-in window has become much less relevant.

ICMP's are one of the only two vectors that can reset connections
without being required a matching SEQ. -- the other one being the ToS
and Precedence level, as discussed in the CPNI document.

IMO, in-window vs. oo-window does make a difference. For instance, the
whole press that these issues got back in 2004 is because people had got
the numbers wrong in their calculations of "number of packets needed".
This is essentially the "new thing" that Paul Watson pointed out back in
2004.

Anyway: For the most part I'm wondering if there's any additional text
needed to address Phillip's comments. Thoughts? This should be our focus
at this point in time.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1