Internet DRAFT - draft-jaeggli-v6ops-indefensible-nd

draft-jaeggli-v6ops-indefensible-nd







v6ops                                                         J. Jaeggli
Internet-Draft                                                    Fastly
Intended status: Informational                              July 2, 2018
Expires: January 3, 2019


                    Indefensible Neighbor Discovery
                 draft-jaeggli-v6ops-indefensible-nd-01

Abstract

   NDP resource exhastion is a problem which cannot fundamently be
   addressed through limited protocol changes or implementation tweaks;
   mitigations proposed in RFC 6583 [RFC6583] may well prevent the
   outright failure of a device under duress.  This draft discusses some
   mitigations which have or can be employeed by networks looking to
   reduce or eliminate the exposure of the Neighbor Discovery Process.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Jaeggli                  Expires January 3, 2019                [Page 1]

Internet-Draft                     IND                         July 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  ND under stress . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Ways in which resources are consumed: . . . . . . . . . .   3
   3.  Mitigations . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  RFC 6583  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Link-Local  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  RFC 6164  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Firewalls . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  Subnetting  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.6.  Stateless Neighbor Presence Discovery . . . . . . . . . .   5
     3.7.  Solicitied Node Multicast Group Membership  . . . . . . .   6
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Neighbor discovery serves to allow the discovery of hosts and the
   self assignment of resources within the sparse address space of IPv6
   subnets.  Since the definition of Interface IDs and accompanying
   subnet sizes RFC 1885 [RFC1885] the potential has existed for the
   forwarding and control plane resources of a router to be greatly
   exceeded by locally or remotely triggered attempts to desocver
   connected neighbors.  The problem of the number of adjacencies that
   can reasonably be supported and signaled in not unique to IPv6 though
   it is especially accute there.  It also exists in IPv4 as well as
   other non-internet protocols.  Practical scaling limits of the number
   of adjaciences or amount of signaling serve as incentives for
   operators to limit the size and number of participants in layer-2
   domains.

   Because of the size of typical IPv6 Interface IDs as well as the
   property of self-assignment, IPv6 subnets and connected devices are
   particularly exposed to resource consumption; therefore proactive
   mitigations are required to limit the potential for resource
   consumption resulting in Denial of Service.  In RFC 6583 [RFC6583],
   we detailed the threat posed by neighbor discovery resource
   consumption to network devices as well as some mitigations which



Jaeggli                  Expires January 3, 2019                [Page 2]

Internet-Draft                     IND                         July 2018


   could improve the situation.  While some mitigations remove the
   threat entirely; RFC 6164 [RFC6164] style /127 prefixes for example
   are not subject to ND attacks, they have the property of not being
   practical for subnets supporting end systems.  Practical mitigations
   in RFC 6583 section 7 [RFC6583]  implementation advice serve to tamp
   down, but cannot entirely eliminate the threat of resource
   exhaustion; devices operating under durress cannot be expected to
   perform as well as devices which are not.

   If we are to characterize the achitectural challenge posed by ARP and
   ND.  It is that traffic in the data-plane from untrusted source may
   impose demands on the control plane to create and then exhaust
   available state.  In IPv4 the mitigiation for this is for the most
   part relatively trivial and tighly coupled to subnet and forwarding
   hardware sizing; address conservation principles that do not apply to
   IPv6 subnets therefore generally but not entirely ameliorate this
   problem in IPv4.

1.1.  Requirements Language

   This document does not employ and should not interpreted through RFC
   2119 [RFC2119] requirements language.

2.  ND under stress

   In characterizing the behavior of devices under stress we posit that
   the neighbor discovery process responsible for resolving an
   effectively unlimited number of unknown neighbors itself is
   ultimately indefensible.  By Indefensible we mean that if implemented
   as intended by 4861 the protocol is always exposed to resource
   consumption constraints that require mitigation.

2.1.  Ways in which resources are consumed:

   o  Host-routes / Negative cache entries - IPv6 subnets do not have
      constraints on the number of addresses which can be employed
      within the limit (64 bits) imposed by the subnet mask.  Networks
      employing stateful DHCP v6 address assignment can make some
      assumptions about the number of host to address mappings they are
      willing to support, devices performing SLAAC and deriving
      addresses subsequently are under no such constraints.

   o  CPU / RAM - Neighbor Discovery is intended to be triggered for
      addresses for which no layer-2 next-hop yet exists.  This allows
      for the classical DDOS of the ND process described in RFC 3756
      [RFC3756].  Since the senders of packets which might trigger ND
      are not subject to the same constraints as devices which have to
      initiate it this asymmetry is trivial to exercise.



Jaeggli                  Expires January 3, 2019                [Page 3]

Internet-Draft                     IND                         July 2018


   o  Multicast - Multicast replication of Neighbor solicitations may be
      expensive for certain link-layers or hosts particularly wireless
      networks.  In cases where multicast is transmitted at lower rates
      then the prevailing unicast rate, performance of other traffic may
      be directly impacted by the presence of this traffic even at
      relatively low levels (draft-perkins-intarea-multicast-ieee802-03
      [draft-perkins-intarea-multicast-ieee802-03]).

3.  Mitigations

   Recognition of the short-comings of IPv6 neighbor discovery are
   sufficiently common that link-layers supporting resource constrained
   infrastructure typically have to address them directly, 6LowPAN for
   example has RFC 6775 [RFC6775] ultizing an address registration
   scheme to limit the need for discovery.

   There are various forms of mitigation which can be applied in order
   to avoid having neighbor discovery become the ineluctable bottleneck
   in defending a subnet.  Many of these approaches are more specially
   changes to harden networks or transfer the burden of state rather
   than alterations of the neighbor discovery process itself.

3.1.  RFC 6583

   RFC 6583 [RFC6583] suggests some practical mitigations, which can
   reduce the extent to which ND fails but not eliminate it.

3.2.  Link-Local

   RFC 7404 [RFC7404](Using Only Link-Local Addressing inside an IPv6
   Network) style approaches, link-local-only numbered interfaces make
   it impossible to target the subnet address from off-link, at the cost
   of limiting the ability to ping interfaces, return useful interface
   IPs in traceroute and so on.

   Link-local-only addressing may be extended to Hosts by assigning
   unicast addressees on loopback interfaces rather than on subnet
   connected interfaces.  In conjunction with routing (typically BGP but
   alternatives are possible), it is possible to construct networks in
   which no external targeting of neighbor discovery on connected
   subnets is possible.  The existence of a prefix of arbitrary length
   is signaled in a routing protocol.  Probes addressed to unused
   addresses may be discarded by an aggregate route.








Jaeggli                  Expires January 3, 2019                [Page 4]

Internet-Draft                     IND                         July 2018


3.3.  RFC 6164

   RFC 6164 [RFC6164] uses /127s allows for the use of /127s for inter-
   router links.  This effectively precludes ND exhaustion attempts for
   point to point links.

3.4.  Firewalls

   Stateful inspection firewalls may limit the expense of performing
   neighbor discovering for unknown addresses by discarding packets for
   unestablished connections.  While this may be a transfer of expense
   from one account (ND) to another (firewall) it never-the-less
   precludes targeting subnets for NDP exhaustion.

3.5.  Subnetting

   Sizing subnets effectively to support the number of hosts present
   does limit the scope for ND exhaustion attacks.  RFC 7608 [RFC7608]
   does instruct that devices be able to forward to arbitrary length
   subnets.  Arbitrary length subnets e.g. a /120 or /121 are presently
   considered incompatible with SLAAC and conflict with some goals for
   privacy address RFC 4941 [RFC4941].  In the draft draft-bourbaki-
   6man-classless-ipv6-03 [draft-bourbaki-6man-classless-ipv6-03] is a
   proposal to eliminate the expectation of fixed length subnetting.

   Alternative to resizing the subnet, stateful DHCPv6 address
   assignment can be used to limit the range of IPs within a /64 subnet
   which are consumed which may be used to ACL to target sub-prefixes of
   the entire subnet.

   Use of very long prefixes has the potential to expose subnets to the
   considerations in RFC 7707 [RFC7707] where for example neighboring
   devices on a subnet might be trivial to discover via scanning as for
   example are router interfaces numbered as "::1" out of convience .
   The extent to which discoverability is an issue may vary by usage and
   also methodoly, so for example sparsely allocated pseudo-randomly
   assigned /128s may be no more discoverable then IPv6 self assigned
   privacy addresses, but machines clumped together in a /121 may be
   trivially identified when one of them is located. other methods of
   discovering detailed in RFC 7707 [RFC7707]  e.g. forward or reverse
   dns mappings may trivialy reveal the presence of additional hosts
   within a prefix.

3.6.  Stateless Neighbor Presence Discovery

   "Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless
   Neighbor Presence Discovery"
   [draft-smith-6man-mitigate-nd-cache-dos-slnd] was a proposal by Mark



Jaeggli                  Expires January 3, 2019                [Page 5]

Internet-Draft                     IND                         July 2018


   Smith, to aleviate the pressure on the neghbor discovery process when
   under duress.

3.7.  Solicitied Node Multicast Group Membership

   "Further Mitigating Router ND Cache Exhaustion DoS Attacks Using
   Solicited-Node Group Membership"
   [draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node] was a proposal by
   Mark Smith, to use the solicited node multicast group to limit the
   need to multicast ND to all ports when performing ND.

4.  Acknowledgements

   This Document is entirely depedent on previous work done in the IETF
   community and other authors.  Mark Smith offered valuable
   contributions and References to the initia Draft.  Brian Carpenter
   reviewed the initial draft and provided additional references.

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Security Considerations

   All drafts are required to have a security considerations section.
   This document is essentially a collection of related security
   considerations, it is hoped that by exploring these issues somce
   insight into the rational and methodology for mitigating the exposure
   posed by ND ay be gained.  Some methods considered here are currently
   and may remain non-standard.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

7.2.  Informative References

   [draft-bourbaki-6man-classless-ipv6-03]
              Nicholas Bourbaki, "Classes IPv6", 2018,
              <https://tools.ietf.org/html/
              draft-bourbaki-6man-classless-ipv6-03>.





Jaeggli                  Expires January 3, 2019                [Page 6]

Internet-Draft                     IND                         July 2018


   [draft-perkins-intarea-multicast-ieee802-03]
              Perkins, C., "Multicast Considerations over IEEE 802
              Wireless Media", 2018, <https://tools.ietf.org/html/
              draft-perkins-intarea-multicast-ieee802-03>.

   [draft-smith-6man-mitigate-nd-cache-dos-slnd]
              Smith, M., "Mitigating IPv6 Neighbor Discovery DoS Attack
              Using Stateless Neighbor Presence Discovery", 2013,
              <https://datatracker.ietf.org/doc/
              draft-smith-6man-mitigate-nd-cache-dos-slnd/>.

   [draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node]
              Smith, M., "Mitigating IPv6 Neighbor Discovery DoS Attack
              Using Stateless Neighbor Presence Discovery", 2016,
              <https://datatracker.ietf.org/doc/
              draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/>.

   [RFC1885]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6
              (IPv6)", RFC 1885, DOI 10.17487/RFC1885, December 1995,
              <https://www.rfc-editor.org/info/rfc1885>.

   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
              Neighbor Discovery (ND) Trust Models and Threats",
              RFC 3756, DOI 10.17487/RFC3756, May 2004,
              <https://www.rfc-editor.org/info/rfc3756>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <https://www.rfc-editor.org/info/rfc4941>.

   [RFC6164]  Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
              L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
              Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
              <https://www.rfc-editor.org/info/rfc6164>.

   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
              Neighbor Discovery Problems", RFC 6583,
              DOI 10.17487/RFC6583, March 2012,
              <https://www.rfc-editor.org/info/rfc6583>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.




Jaeggli                  Expires January 3, 2019                [Page 7]

Internet-Draft                     IND                         July 2018


   [RFC7404]  Behringer, M. and E. Vyncke, "Using Only Link-Local
              Addressing inside an IPv6 Network", RFC 7404,
              DOI 10.17487/RFC7404, November 2014,
              <https://www.rfc-editor.org/info/rfc7404>.

   [RFC7608]  Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
              Length Recommendation for Forwarding", BCP 198, RFC 7608,
              DOI 10.17487/RFC7608, July 2015,
              <https://www.rfc-editor.org/info/rfc7608>.

   [RFC7707]  Gont, F. and T. Chown, "Network Reconnaissance in IPv6
              Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
              <https://www.rfc-editor.org/info/rfc7707>.

Author's Address

   Joel Jaeggli
   Fastly
   Mountain View, CA  94043
   US

   Phone: +5415134095
   Email: joelja@bogus.com




























Jaeggli                  Expires January 3, 2019                [Page 8]