Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery
draft-smith-6man-mitigate-nd-cache-dos-slnd-05

Internet Engineering Task Force                                 M. Smith
Internet-Draft                                                      IMOT
Updates: 4861 (if approved)                            November 10, 2012
Intended status: Standards Track
Expires: May 14, 2013

   Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor
                               Discovery
             draft-smith-6man-mitigate-nd-cache-dos-slnd-05

Abstract

   The IPv6 neighbor discovery cache is vulnerable to a Denial of
   Service attack that purposely exhausts the state used during the
   neighbor discovery process.  This attack can be very disruptive when
   the target is a router.  This memo proposes a stateless form of
   neighbor discovery to be used by routers to mitigate this attack.  It
   does not require any changes to hosts.

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 http://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 May 14, 2013.

Copyright Notice

   Copyright (c) 2012 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
   (http://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

Smith                     Expires May 14, 2013                  [Page 1]
Internet-Draft        Stateless Neighbor Discovery         November 2012

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Opportunities for Stateless Neighbor Discovery . . . . . . . .  4
     3.1.  Neighbor Advertisement Validation  . . . . . . . . . . . .  4
     3.2.  Optimisation Functions . . . . . . . . . . . . . . . . . .  5
   4.  Stateless Neighbor Discovery . . . . . . . . . . . . . . . . .  5
     4.1.  SLND Variables . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  SLND Processing  . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Optional Enhancements  . . . . . . . . . . . . . . . . . .  7
       4.3.1.  Selective Stateless Neighbor Discovery . . . . . . . .  7
         4.3.1.1.  Source Address . . . . . . . . . . . . . . . . . .  8
         4.3.1.2.  Ingress Interface  . . . . . . . . . . . . . . . . 10
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Change Log [RFC Editor please remove]  . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12

Smith                     Expires May 14, 2013                  [Page 2]
Internet-Draft        Stateless Neighbor Discovery         November 2012

1.  Introduction

   The IPv6 neighbor discovery cache [RFC4861] is vulnerable to a Denial
   of Service attack that purposely exhausts the state used during the
   neighbor discovery process [RFC3756].

   When a router is the target of this attack, an off-link attacker
   sends traffic towards many non-existent addresses within a prefix
   attached to the router.  This causes the router to create neighbor
   cache state for neighbor solicitations for these non-existent
   addresses.  The denial of service occurs when the router's neighbor
   cache state capacity is exhausted due to too many outstanding neighor
   solicitations.

   Sizing a prefix proportional to the number of attached hosts, rather
   than using the standard /64 prefix size [RFC4291], would mitigate
   this attack.  However, operational conveniences and benefits such as
   universal fixed length prefixes and interface identifiers, Stateless
   Address Autoconfiguration (SLAAC) [RFC4862] and privacy addresses
   [RFC4941], and never having to resize the prefix or add secondary
   prefixes to attach more hosts to the link would be lost.

   This memo proposes a stateless form of neighbor discovery to prevent
   this type of DoS attack on a router.  It does not require any changes
   to the operation of neighbor discovery on hosts.  It takes advantage
   of hosts' ability to recover from packet loss in the network,
   necessary due to IPv6's best effort nature.  This method would be
   used when the router's neighbor cache's state capacity reaches a
   medium to high threshold of use, suggesting a neighbor cache DoS
   attack is occuring.  An optional enhancement is to distinguish packet
   sources as trusted or untrusted, and to continue to provide trusted
   packet sources with traditional stateful neighbor discovery.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Terminology

   Stateful Neighbor Discovery (SFND): Traditional neighbor discovery,
   as specified in [RFC4861].  This form of neighbor discovery maintains
   per packet destination state for all unresolved destinations during
   the neighbor discovery process.  The neighbor cache's state capacity
   is intentionally exhausted to cause the neighbor cache Denial of
   Service attack.

Smith                     Expires May 14, 2013                  [Page 3]
Internet-Draft        Stateless Neighbor Discovery         November 2012

   Stateless Neighbor Discovery (SLND): The form of neighbor discovery
   described in this memo.  This form of neighbor discovery does not
   maintain per packet destination state for unresolved destinations
   during the neighbor discovery process.

   IGP: Interior Gateway Protocol, such as OSPF [RFC5340].

   EGP: Exterior Gateway Protocol, such as BGP [RFC4271].

3.  Opportunities for Stateless Neighbor Discovery

   During traditional stateful neighbor discovery, state is used to
   perform the following:

   o  ensure a received neighbor advertisement corresponds to a
      previously sent neighbor solicitation

   o  to retransmit a limited number of neighbor solicitations if
      previous solicitations remain unanswered

   o  to store a small number of packets that triggered the neighbor
      discovery process, so that they can be transmitted if neighbor
      discovery completes successfully

   o  to generate ICMPv6 destination unreachable, address unreachble
      messages should neighbor discovery fail

   Stateless neighbor discovery sacrifices these functions and the
   related state to mitigate the neighbor cache DoS attack.

3.1.  Neighbor Advertisement Validation

   Ensuring received neighbor advertisements correspond to previously
   sent neighbor solicitations prevents on-link nodes from sending
   unsolicited neighbor advertisements to the router, and then having
   them added to the router's neighbor cache without validation.  This
   would allow on-link hosts to perform a neighbor cache DoS attack, as
   they could send many neighbor advertisements for non-existent
   addresses within the link assigned prefixes, exhausting the neighbor
   cache capacity.

   If neighbor advertisement validation occurs, then the router is
   vulnerable to an off-link sourced neighbor cache DoS attack, but is
   not vulnerable to an on-link sourced neighbor cache DoS attack.  If
   neighbor advertisement validation does not occur, then the router is
   vulnerable to an on-link sourced neighbor cache DoS attack, but is
   now not vulnerable to an off-link sourced neighbor cache DoS attack.

Smith                     Expires May 14, 2013                  [Page 4]
Internet-Draft        Stateless Neighbor Discovery         November 2012

   Considering that on-link nodes will usually have a vested interest in
   the router continuing to operate, that there will be a much smaller
   set of on-link sources, and that they'll be far better known and
   possibly access controlled, the likelihood of an on-link sourced
   neighbor cache DoS is much lower than an off-link sourced neighbor
   cache DoS.  It is therefore beneficial to sacrifice on-link neighbor
   cache DoS protection to gain off-link neighbor cache DoS protection.
   Also note that during the stateless neighbor discovery process
   proposed in this memo, neighbor advertisement validation is only
   sacrificed when an off-link sourced neighbor cache DoS appears to be
   taking place.  Under normal circumstances on-link sourced neighbor
   advertisement validation continues to occur.

3.2.  Optimisation Functions

   The nature of IPv6 is best effort, meaning that there is a
   possibility that packets may be lost as they transit the network, and
   that IPv6 will not make any attempt to recover lost packets.  If an
   application residing on an IPv6 node requires reliable packet
   delivery, it will need to utilise locally implemented reliable upper
   layer protocols such as TCP and SCTP, or implement it's own
   reliability mechanisms.  These reliability mechanisms involve
   retransmitting packets.  Alternatively, the application needs to
   accept the possibility and consequences of packet loss.

   The remaining uses of stateful neighbor discovery state are not
   assured of success.  The limited number of neighbor solicitation
   retransmissions may not be enough, causing neighbor discovery to fail
   even though the target node exists.  There may be more packets sent
   that trigger neighbor discovery than are stored for transmission when
   neighbor discovery completes successfully, causing them to be
   dropped.  The ICMPv6 destination unreachable message may be dropped
   on the way back to the traffic originating node, perhaps
   intentionally by a network located firewall.

   This means that these functions are useful but not essential
   optimisations.  If necessary, they do not need to be performed, as
   the packet source will retransmit it's packets, reinitiating the
   neighbor discovery process, or accept that packet loss has occured.
   This provides the opportunity to perform a stateless form of neighbor
   discovery if there is evidence that a neighbor cache DoS attack is
   occuring, mitigating the off-link sourced neighbor cache DoS attack.

4.  Stateless Neighbor Discovery

Smith                     Expires May 14, 2013                  [Page 5]
Internet-Draft        Stateless Neighbor Discovery         November 2012

4.1.  SLND Variables

   To perform stateless neighbor discovery, four variables are
   maintained:

   SLND Flag - This flag indicates whether or not the interface will
   perform SLND if necessary.  By default, this flag should be set to
   on.

   SLDN Activate Threshold - This variable specifies the threshold when
   stateless neighbor discovery is activated.  The threshold specifies a
   neighbor cache utilisation level.  It is expressed as a percentage,
   with a default value of 80%.  It may either be a per-interface or
   router global variable depending on whether the router implementation
   has per-interface neighbor caches or a global neighbor cache used by
   all interfaces.

   SLND Active Flag - This flag indicates whether or not the interface
   is currently performing SLND.  It is maintained for each interface on
   the router.

   SLND Neighbor Solicitation Rate Limit ("SLND NS Rate Limit") - This
   variable specifies a threshold for multicast Neighbor Solictiations
   when the interface is performing SLND, specified in packets per
   second.  It is a per-interface variable, as different interfaces may
   have different thresholds.  The rate value should be an appropriate
   portion of the multicast packet per second capabilities of the
   interface link technology, such as 10%.  A router may maintain a
   global threshold that is applied to interfaces that do not have an
   interface specific rate limit.

4.2.  SLND Processing

   The stateless neighbor discovery process may occur once a router has
   determined the outgoing interface for a packet, and that the packet's
   destination is on-link.

   If the packet's destination address is present in the neighbor cache,
   and the link-layer address has been resolved, the packet is forwarded
   to it's destination.

   If the packet's destination address is not present in the neighbor
   cache, and the SLND Flag is off, traditional stateful neighbor
   discovery is performed for the packet's destination.

   If the SLND Flag is on, and the SLND Active flag is off, traditional
   stateful neighbor discovery is performed.

Smith                     Expires May 14, 2013                  [Page 6]
Internet-Draft        Stateless Neighbor Discovery         November 2012

   If the SLND Flag is on, and the SLND Active flag is on, stateless
   neighbor discovery is performed as follows:

   1.  The router determines if sending a multicast neighbor
       solicitation would exceed the SLND NS Rate Limit for the outgoing
       interface.  If the SLND NS Rate Limit would be exceeded, drop the
       packet and do not proceed any further.

   2.  A multicast neighbor solicitation is sent by the router for the
       destination address in the packet.  The packet is then dropped.

   3.  As some later point in time, the router is likely to receive a
       unicast neighbor advertisement, for a previously sent neighbor
       solicitation.

   4.  If the SLND Active Flag is off, the router ignores the neighbor
       advertisement.

   5.  If the SLND Active Flag is on, the router creates an entry in
       it's neighbor cache using the information received in the unicast
       neighbor advertisement.  Stateless neighbor discovery is now
       complete.

   The utilisation of the neighbor cache needs to be measured to
   determine if it crosses the SLDN Activate Threshold.  If the
   utilisation increases above the SLDN Activate Threshold, the SLND
   Active Flag is switched on, and if it decreases below the SLDN
   Activate Threshold, the SLND Active Flag is switched off.  Neighbor
   cache utlisation should be measured and compared to the SLDN Activate
   Threshold when:

   o  entries are added to the neighbor cache, during either stateful or
      stateless neighbor discovery

   o  entries are removed from the neighbor cache when Neighbor
      Unreachability Detection discovers the neighbor has disappeared

4.3.  Optional Enhancements

4.3.1.  Selective Stateless Neighbor Discovery

   When a neighbor cache DoS attack appears to be occurring, it could be
   useful to continue to provide traditional stateful neighbor discovery
   service to hosts that are considered unlikely to initiate or
   participate in the DoS attack.  These hosts could be considered
   trusted hosts, while the remaining set of hosts are untrusted.

   The determination of whether a host is trusted or untrusted would

Smith                     Expires May 14, 2013                  [Page 7]
Internet-Draft        Stateless Neighbor Discovery         November 2012

   take place when neighbor discovery is determined to be necessary,
   during the stateless neighbor discovery process.  The determination
   of trust is made based on attributes of the packets that trigger the
   neighbor discovery process.  If none of the packet attributes
   indicate either a trusted or untrusted host, then the host is
   considered to be untrusted.

   There are two basic packet attributes that an enhanced implementation
   should provide mechanisms to use to classify a packet source as
   trusted or untrusted:

   o  source address

   o  ingress interface

   An implementation may be able to reuse its existing packet
   classification mechanisms to determine trust, such as those used to
   implement network QoS.  This would mean that other packet attributes,
   such as Traffic Class, Flow Label [RFC6437], the CALIPSO option
   [RFC5570] or MPLS label values [RFC3031], could also be used to
   determine packet source trustworthiness.

4.3.1.1.  Source Address

   The source address of the packet that has triggered the neighbor
   discovery process can be used to determine the trust level of the
   origin host.  The information used to classify the source address can
   come from two possible sources:

   o  an operator configured prefix list

   o  the network's routing information

4.3.1.1.1.  Operator Configured Prefix List

   An operator configured prefix list consists of a static list of
   prefixes and their lengths, each with a flag indicating whether
   traffic with source addresses that falls within the specified prefix
   is from a trusted or untrusted source.

   How this list is evaluated would be implementation dependent, however
   it is likely to be either sequential from first to last entry, or
   using a longest match algorithm.

   This list should have a default entry of the ULA prefix (fc00::/7)
   [RFC4193], flagged as a trusted source.  An implementation must allow
   this entry to be removed.

Smith                     Expires May 14, 2013                  [Page 8]
Internet-Draft        Stateless Neighbor Discovery         November 2012

4.3.1.1.2.  Routing Information

   The network's routing information can be used to distinguish trusted
   and untrusted packet sources.  An advantage of using routing
   information for this purpose is that it will typically be dynamically
   and automatically distributed to all routers within the network, when
   dynamic routing protocols are used.  This avoids changes to the
   operator configured prefix list on individual routers when trusted
   prefixes are added or removed from the network.

   The contents of a stub network's route table is typically all the
   internal routes for the network, and then a default route used to
   reach the Internet.  The list of internal routes can be used to
   distinguish between trusted and untrusted sources, with packet
   sources matching internal routes being trusted, and all other packet
   sources being untrusted.

   In more complex routing environments, such as those using one or more
   IGPs and an EGP such as BGP [RFC4271], there may be other methods
   available to distinguish between trusted and untrusted sources.  For
   example, routes carried in an IGP could be considered trusted, while
   routes carried in BGP are untrusted.  For a network using BGP to
   carry all reachability information, except network transit and
   loopback interface routes, internal routes may be tagged with one or
   more BGP communities to indicate they are also trusted prefixes.

   There may be cases where a subset of the internal routes need to be
   considered untrusted, despite them being propagated internally via a
   routing protocol.  These routes will likely be for links at the edge
   of the local network, where untrusted hosts can be attached without
   local network control or authorisation.  These routes need to be
   labelled as untrusted, and that information propagated to all routers
   within the local network.  Route labelling mechanisms such as OSPF's
   External Route Tag [RFC5340] or a BGP community could be used for
   this purpose.

   A default route should never be used as a trusted packet source
   route.  If a router's operator wishes to trust all packet sources,
   they should specify the prefix that covers all IPv6 addresses, ::/0,
   as an operator configured trusted prefix.  (The ::/0 prefix is only a
   default route when used as routing information.)

   Implementations should provide simple and convenient methods to use
   the network's routing information to distinguish between trusted and
   untrusted packet source prefixes.

Smith                     Expires May 14, 2013                  [Page 9]
Internet-Draft        Stateless Neighbor Discovery         November 2012

4.3.1.2.  Ingress Interface

   A packet's ingress interface on the router could be used to determine
   whether statelful or stateless neighbor discovery takes place.
   Interfaces on the router would be labelled as trusted or untrusted.

   The default trust level for interfaces would be up to the router's
   implenter.  Considerations could be the likely deployment scenario
   for the router implementation (e.g., residential Internet access, or
   within an enterprise network), and the type of interface (e.g., an
   interface type that is usually used to attach the router to the
   Internet, such as an ADSL interface, would be labelled untrusted).
   These default interface trust assignments should be easy to change.

5.  Acknowledgements

   Oliver Ddin provided review and comments, and suggested the use of
   ingress interface and other more general packet attributes to
   determine packet source trust.

   Review and comments were provided by Ray Hunter, Matthew Moyle-Croft
   and Karl Auer.

   This memo was prepared using the xml2rfc tool.

6.  Security Considerations

   This memo proposes a security mitigation for an off-link sourced
   neighbor cache Denial of Service attack, aimed at a router.

   As discussed in Section 3.1, the method proposed creates an
   opportunity for an on-link sourced neighbor cache DoS attack, when
   mitigating the off-link sourced neighbor cache DoS.  This is
   considered to be an acceptable security trade-off.

7.  Change Log [RFC Editor please remove]

   draft-smith-6man-mitigate-nd-cache-dos-slnd-00, initial version,
   2012-09-04

   draft-smith-6man-mitigate-nd-cache-dos-slnd-01, more clarity, 2012-
   10-13

Smith                     Expires May 14, 2013                 [Page 10]
Internet-Draft        Stateless Neighbor Discovery         November 2012

   o  more comprehensive introduction (problem definition) text

   o  make it more obvious that hosts don't need to be changed

   o  low-end/embedded hosts can consider all packet sources untrusted

   o  misc. minor text updates

   draft-smith-6man-mitigate-nd-cache-dos-slnd-05, structual changes,
   2012-11-08

   o  moved opportunities for SLND section to before SLND description

   o  spit SLND into basic functionality and optional enhancements

   o  use of ingress interface and other more general packet attributes
      to determine trust

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,
              May 2004.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

Smith                     Expires May 14, 2013                 [Page 11]
Internet-Draft        Stateless Neighbor Discovery         November 2012

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

   [RFC5570]  StJohns, M., Atkinson, R., and G. Thomas, "Common
              Architecture Label IPv6 Security Option (CALIPSO)",
              RFC 5570, July 2009.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437, November 2011.

Author's Address

   Mark Smith
   In My Own Time
   PO BOX 521
   HEIDELBERG, VIC  3084
   AU

   Email: markzzzsmith@yahoo.com.au

Smith                     Expires May 14, 2013                 [Page 12]