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

[Joe Touch <[e-mail]>]

Fernando Gont wrote:
> Hello, Phillip,
> 
> Thanks so much for your feedback! See my comments inline....
> 
> 
>> 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.

> What's in the I-D is what most implementation (all the
> mainstream ones, at least) do.
> 
> 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.

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

It'd be an interesting question to ask whether we could do without ICMPs
altogether, but that is not addressed sufficiently in this doc to make
such a conclusion, IMO.

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

>> It might well be that an
>> appropriate control in certain cases would be to turn off ICMP hard
>> errors and rely on timeouts, I am thinking here of critical
>> infrastructure applications and communications between hosts running
>> BGP functions.
> 
> Most (if not all) real-world implementations already do this. We have
> lived with this behaviour that you describe for the last..mm.. 20 years
> (or so) with BSDs... and there's no way that BSDs, or Linux, or Cisco,
> or whoever are going to change back their implementations to e.g.
> "resetting connections in response to ICMP hard errors". For instance,
> they have issued vulnerability advisories in this respect...

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.

>> In particular I note that the draft says "It is interesting to note
>> that, as ICMP error messages are transmitted unreliably, transport
>> protocols should not depend on them for correct functioning."
>>
>> 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.

Joe