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

[Fernando Gont <[e-mail]>]

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



>> So if *I* had to answer why we don't stress that ICMP should be
>> disregarded in many scenarios, etc., I can just say that this is what
>> the WG has converged to.
> 
> This is what the WG *decided*. "Converged to" similarly implies lack of
> deliberate decision, which was not the case.

FWIW, this is what was decided (IIRC) at the IETF Vancouver in 2005. And
as a result of what I already considered at the time an excessive
expenditure of energy :-), didn't fight that much.



>>> 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 you ever get an ICMP hard error, it's probably because of a firewall.
And many of these devices do not even check the TCP checksum. So you may
end up resetting a connection in response to an ICMP hard error elicited
by a corrupted TCP segment. That is, honoring ICMPs makes TCP less robust.

That said, at this point in time all this has already been discussed. So
I just want to finish the I-D. So at this point in time, whatever
addresses the raised issues would do for me.

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



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



>>> Given the extreme approach to security of starting from nothing and
>>> only adding systems that are essential, this would seem to suggest
>>> ICMP is not necessary and could be eliminated. 
>> Yes...except for ICMP "frag needed but DF bit set", which is needed for
>> PMTUD.
> 
> Well, if we're going to pick, PMTUD based on ICMP should be replaced
> with PLPMTUD. However, again, this level of recommendation is out of
> scope for this doc, IMO.

I already tried this one, and e.g., Linux developers already refused to
do so, as a result of "convergence time" reasons.

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