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

[Fernando Gont <[e-mail]>]

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



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



> 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"?



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



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


> There may be a case to
> the contrary but it needs to be made before page 15.

My take is "responsiveness". But I'll let the wg chime in. :-)



> Page 15/16
> 
> The following phrase repeats in a way that suggests an editing oversight:
> aborting the
>    connection would be to ignore the valuable feature of the Internet
>    that for many internal failures it reconstructs its function without
>    any disruption of the end points

Sorry... I wasn't able to catch the "oversight" you refer to...  :-(




> Page 24-26
> 
> A more general way of describing the mitigation strategy would be to
> point out the general principle that error messages may be ignored
> whenever a packet indicating success is received within the timeout
> window. In other words no final processing decisions should be made on
> an unauthenticated ICMP packet until after the timeout window expires.

Section 7.2 already states:
"  The
   described mechanism basically disregards ICMP messages when a
   connection makes progress, without violating any of the requirements
   stated in [RFC1191] and [RFC1981]."

Please let me know if this text addresses your comment, or whether you
think I should craft another paragraph mentioning that of "ignore
messages whenever a packet indicating progress is received".

Thanks!

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