Subject: ICMP PTB spoofing attacks (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Feb 2016 17:46:35 +0000

Hi Fred,

> As soon as I say "there is no such attack", one will materialize, so I won't assert that.  However, I am not aware of attacks in which
> someone creates ICMP PTBs and sends them to someone else in order to reduce their windows unnecessarily.

RFC4821 Section 11 (Security Considerations) recognizes the potential for spoofed
(i.e., inaccurate) ICMP PTB messages and suggests a mitigation (ignore all ICMP PTBs).
For paths over which any node in the network can inject an inaccurate ICMP PTB
message, an attack vector exists.

> I certainly *am* aware
> of firewalls and other equipment being programmed to either not originate or not allow ICMP messages, believing ICMP to be an
> attack vector.

Right.

> As far as I know, RFC 4821 is a response to the latter issue.

RFC4821 is a response to both issues: 1) Loss of accurate ICMP PTBs, and
2) Receipt of inaccurate ICMP PTBs.

Thanks - Fred
[email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 15:02:02 -0300

> message, an attack vector exists.

In theory, you can do some basic validation for ICMP messages. However,
in v6, as a result of possible EHs, you may not find any meaningful data
in the ICMP payload to apply validity checks on.

Anyway, you can implement the countermeasure we implemented in
<https://tools.ietf.org/html/rfc5927#section-7.2> -- I implemented it
for OpenBSD, and it still runs it... and IIRC it was ported to at least
NetBSD later.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Feb 2016 18:25:53 +0000

Hi Fernando,

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Friday, February 05, 2016 10:02 AM
> To: Templin, Fred L; Fred Baker (fred)
> Cc: 6man WG; Bob Hinden
> Subject: Re: ICMP PTB spoofing attacks (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)
> 

Thanks for the reference. It seems to account for the case of paths that may
deliver inaccurate ICMP PTBs, but does not account for the case of paths that
fail to deliver accurate ICMP PTBs. Do we know of paths always deliver
accurate ICMP PTBs but can also deliver inaccurate ICMP PTBs? 

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 15:30:30 -0300

> accurate ICMP PTBs but can also deliver inaccurate ICMP PTBs? 

What do you mean by "accurate"?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Feb 2016 18:42:44 +0000

Hi Fernando,

> Sent: Friday, February 05, 2016 10:31 AM
> Cc: Bob Hinden; 6man WG

By "accurate" I mean:

- the router that sends the ICMP PTB is telling the truth that there is a restricting link
- the MTU value that the router writes in the PTB is in fact the true MTU of the
   restricting link

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 17:13:57 -0300

> - the MTU value that the router writes in the PTB is in fact the true MTU of the

Well, most of these protocols run on "good faith", right? -- If I cannot
trust the router to tell the truth, why should I trust it to e.g.
forward my packets?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Feb 2016 20:25:52 +0000

Hi Fernando,

> Sent: Friday, February 05, 2016 12:14 PM

A router's trustworthiness for forwarding packets and for telling the truth
in any ICMP PTB message it sends are mutually exclusive - the first question
is one of availability and the second is one of integrity.

Plus, it is not necessarily just the on-path routers - any off-path "router"
could also inject spurious PTBs.

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 17:39:37 -0300

> is one of availability and the second is one of integrity.

I think that, at the end of the day, its about trust. Can I trust the
device, or not?

I my goal as an attacker is to DoS your communications, I don't care
whether I achieve that by simply throwing your packets away, or by
sending you some packet that will cause yourself to shutdown and not talk.

I should say, however, that in the IPv6 case, the worst case scenario is
a 1280-byte MTU link...

> could also inject spurious PTBs.

For off-path attackers, you validate ICMP PTBs. If you don't, well...
prepare for trouble.  And, yes, if EHs are in use, you may not be able
to verify them.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Feb 2016 11:35:40 +1100

> I should say, however, that in the IPv6 case, the worst case scenario is

Which is what we force the nameservers we ship to use (for both TCP
and UDP) as PMTUD takes too long for DNS even when it works.

> prepare for trouble.  And, yes, if EHs are in use, you may not be able

Only if all the original headers + PTB header > 1280 which should
be a vanishing small pecentage of times.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Mon, 8 Feb 2016 18:48:27 -0300

> 2) Receipt of inaccurate ICMP PTBs.

FWIW, RFC4821 is rather orthogonal to ICMP-based attacks, since, in
principle, it can be implemented along RFC1918 or in replacement of it.

Thanks,