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

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492