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

[Joe Touch <[e-mail]>]

Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>> The principal security risks considered are service risks. ICMP may be
>>>> used to perform certain denial of service and performance downgrade
>>>> attacks. As such it probably needs rather more justification than 'we
>>>> have always done this' when building critical infrastructures.
>>> I fully agree. This I-D has been debated in tcpm form... 6 years now. It
>>> was originally meant for Std track, but somehow ended up heading for
>>> Informational.
>> That implies the decision was either accidental or unintentional, and
>> neither is the case, FWIW.
> 
> 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.

...
>>>> Given that TCP streams will eventually time-out, I have something of a
>>>> hard time seeing why we would be using a non-authenticated control
>>>> protocol at all. Yes, I know the legacy reasons etc. etc. But this is
>>>> not the way we would approach this problem today. 
>>> I fully agree.
>>
>> Not all TCP state times out. Connections that don't use keepalives will
>> retain stale state until the state is explicitly flushed by a RST. If
>> the other end never comes back up, the state *never* gets flushed if not
>> for ICMPs.
> 
> 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.

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 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.

> 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.
...
> 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.

>>>> This argument is
>>>> almost made on page 15. Some statement giving the case for taking
>>>> notice of ICMP messages at all is in order. 
>>> I guess the "statement" that you could get here (tcpm) is
>>> "responsiveness". -- with which I'd disagree, for many of the reasons
>>> stated in the draft, and because in many other cases it has been argued
>>> in this very wg that "tcp is supposed to be robust, it's not optimized
>>> for any scenario, etc.".
>>>
>>> Should I craft some text along the lines of "responsiveness"?
>> This doc, by WG agreement, focuses on "what is". It is not intended to
>> make broader recommendations or conclusions.
> 
> This doc has probably been one of the best examples for the recent flood
> of messages on the WG.
> 
>> KARP is addressing some of these issues. TCP-AO also addresses these
>> issues in the context of BGP.
>>
>> 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.

(e.g., if "in window" was sufficient, then you should be arguing to stop
work on TCP-SECURE).

Joe