Subject: [v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Sep 2014 14:23:39 -0300

Folks,

Based on the recent discussions, we're planning to update Section 5.2
(which contains all the discussion about the ICMP-based attack vector)
of the aforementioned I-D as follows. Please let us know if you have any
comments:

---- cut here ----
5.2.  A possible attack vector

   The widespread filtering of IPv6 packets employing IPv6 Extension
   Headers can, in some scenarios, be exploited for malicious purposes:
   if packets employing IPv6 EHs are known to be filtered on the path
   from one system (say, "A") to another (say, "B"), an attacker could
   cause packets sent from A to B to be dropped by sending a forged
   ICMPv6 Packet Too Big (PTB) [RFC4443] error message to A (with a
   Next-Hop MTU smaller than 1280), such that subsequent packets from A
   to B include a fragment header (i.e., they result in atomic fragments
   [RFC6946]).

   Possible scenarios where this attack vector could be exploited
   include (but are not limited to):

   o  Communication between any two systems through to public network
      (e.g., client from/to server or server from/to server), where
      packets with IPv6 extension headers are filtered by some
      intermediate router

   o  Communication between two BGP peers employing IPv6 transport,
      where these BGP peers implement ACLs to drop IPv6 fragments (to
      avoid control-plane attacks)

   The aforementioned attack vector is exacerbated by the following
   factors:

   o  The attacker does not need to forge the IPv6 Source Address of his
      attack packets.  Hence, deployment of simple BCP38 filters will
      not help as a counter-measure.

   o  Only the IPv6 addresses of the IPv6 packet embedded in the ICMPv6
      payload need to be forged.  While one could envision filtering
      devices enforcing BCP38-style filters on the ICMPv6 payload, the
      use of extension (by the attacker) could make this difficult, if
      at all possible.

   o  Many implementations fail to perform validation checks on the
      received ICMPv6 error messages, as recommended in Section 5.2 of
      [RFC4443] and documented in [RFC5927].  It should be noted that in
      some cases, such as when an ICMPv6 error message has (supposedly)
      been elicited by a connection-less transport protocol (or some
      other connection-less protocol being encapsulated in IPv6), it may
      be virtually impossible to perform validation checks on the
      received ICMPv6 error messages.  And, because of IPv6 extension
      headers, the ICMPv6 payload might not even contain any useful
      information on which to perform validation checks.

   o  Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big"
      error messages, the Destination Cache [RFC4861] is usually updated
      to reflect that any subsequent packets to such destination should
      include a Fragment Header.  This means that a single ICMPv6
      "Packet Too Big" error message might affect multiple communication
      instances (e.g., TCP connections) with such destination.

   o  A node cannot simply "just filter/drop all incoming ICMPv6 Packet
      Too Big error messages", or else it would create a PMTUD
      blackhole.

   Possible mitigations for this issue include:

   o  Filtering incoming ICMPv6 Packet Too Big error messages that
      advertise a Next-Hop MTU smaller than 1280 bytes.

   o  Artificially reducing the MTU to 1280 bytes and filter incoming
      ICMPv6 PTB error messages.

   Both of these mitigations come at the expense of possibly preventing
   communication through SIIT [RFC6145] that rely on IPv6 aomic
   fragments (see [I-D.gont-6man-deprecate-atomfrag-generation]), and
   also implies that the filtering device has the ability to filter ICMP
   PTB messages based on the contents of the MTU field.

   [I-D.gont-6man-deprecate-atomfrag-generation] has recently proposed
   to deprecate the generation of IPv6 atomic fragments, and update the
   SIIT [RFC6145] such that it does not rely on ICMPv6 atomic fragments.
   Thus, any of the above mitigations would eliminate the attack vector
   without any interoperability implications.
---- cut here ----

Thanks!

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Sep 2014 09:55:29 +1000

In message <[email-masked]>, Fernando Gont writes:
>    The widespread filtering of IPv6 packets

	with Extension Headers by enterprise firewalls

>                                               employing IPv6 Extension

IPv6 packets with fragmentation headers get through if you don't
stuff a device with deliberately blocks them in the path.  This is
self inflicted pain.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Sep 2014 12:42:12 +1200

> stuff a device with deliberately blocks them in the path.  This is

I think the problem is that isn't painful at all to the people who
configure the blocking device. It's only painful to actual users.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Sep 2014 10:59:37 +1000

> configure the blocking device. It's only painful to actual users.

Which in 99% of case work for the same people that orded the firewall
to be installed.  If fragments aren't getting to your device take
the issue up with your management.  It's almost always a problem
at the receiving end.

If you are a home user with a broken firewall that does this replace
it.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Sep 2014 15:02:17 +1200

> the issue up with your management.  It's almost always a problem

Yes, but in my experience, the ordinary corporate user has zero
influence on the security edicts of the corporate IT department,
even if the user is knowledgeable enough to identify that his or
her problem is a failure due to dropped PTBs or fragments.

I'm not just saying this. In fact, personal experience of the
corporate firewall where I work dropping extension headers is
exactly why I initiated RFC 7045 and have taken so much interest
in Fernando's various drafts. I think it's very important to get
the analysis and the best possible advice out there before the
concrete sets on IPv6 "best" practices.

> If you are a home user with a broken firewall that does this replace

If you know that's the case, sure, but it means spending $99 that
you might prefer to spend elsewhere. And Joe Random Citizen won't
know that it's the case anyway.

RFC 7084 is silent on this issue. RFC 6092 covers ICMPv6 but is
incomplete in its coverage of extension headers and options,
and doesn't mention fragments at all. Once Fernando's various
drafts have stabilised, it may be useful to review 6092 carefully,
and make sure that Homenet is aware of the issues too.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 04 Sep 2014 20:06:56 -0300

Hi, Mark,

> 	with Extension Headers by enterprise firewalls

EH filtering is simply widespread... not just by enterprise firewalls.
For instance, please check the measurement results we have included in
our I-D.

> stuff a device with deliberately blocks them in the path.  This is

Again, not necessarily "self inflicted". Please check the percentage of
packet drops by ASes other than the destination AS (in our I-D).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 04 Sep 2014 20:23:16 -0300

> the issue up with your management.  It's almost always a problem

Brian already commented on this issue. That said, for the case we are
describing, your assessment does not really apply: the filtering is
happening in transit rather than at the edge.

e.g., I was able to attack my own connection against www.kernel.org, and
there wasn't any firewall on my access.

Whether firewalls at the edge are predominant when it comes to filtering
of IPv6 packets with Ehs between peers (i.e., peer to peer) is something
worth exploring... but for the time being is rather orthogonal to our
discussion (although it might help to exacerbate the problem when
there's no filtering on the network, but the border firewall does filter
IPv6 packets with EHs).

Thanks,