<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6164 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6164.xml">
<!ENTITY RFC6583 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6583.xml">
<!ENTITY RFC6775  SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC7404 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7404.xml">
<!ENTITY RFC4941 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY RFC7608 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7608.xml">
<!ENTITY RFC1885 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1885.xml">
<!ENTITY RFC3756 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3756.xml">
<!ENTITY RFC7707 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7707.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-jaeggli-v6ops-indefensible-nd-01" ipr="trust200902">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title abbrev="IND">Indefensible Neighbor Discovery</title>

   <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

   <author fullname="Joel Jaeggli" initials="J" surname="Jaeggli">
     <organization>Fastly</organization>

     <address>
       <postal>
         <street></street>

         <!-- Reorder these if your country does things differently -->

         <city>Mountain View</city>

         <region>CA</region>

         <code>94043</code>

         <country>US</country>
       </postal>

       <phone>+5415134095</phone>

       <email>joelja@bogus.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>

   <date year="2018" />

   <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Operations and Management</area>

   <workgroup>v6ops</workgroup>

   <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>neighbor discovery</keyword>

   <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
     <t>NDP resource exhastion is a problem which cannot fundamently be addressed through limited protocol changes or implementation tweaks; mitigations proposed in <xref target="RFC6583">RFC 6583</xref> 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.</t>
   </abstract>
 </front>

 <middle>
   <section title="Introduction">
      <t>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 <xref target="RFC1885">RFC 1885</xref> 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.</t>

      <t>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 <xref target="RFC6583">RFC 6583</xref>, we detailed the threat posed by neighbor discovery resource consumption to network devices as well as some mitigations which could improve the situation. While some mitigations remove the threat entirely; <xref target="RFC6164">RFC 6164</xref> 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 <xref target="RFC6583">RFC 6583 section 7</xref>  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.</t>

      <t>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.</t>

     <section title="Requirements Language">
        <t> This document does not employ and should not interpreted through <xref
        target="RFC2119">RFC 2119</xref> requirements language.</t>
     </section>

  </section>

<section title="ND under stress">

  <t>
  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.
  </t>

   <section anchor="simple_list" title="Ways in which resources are consumed:">
  <t><list style="symbols">
    <t>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.</t>

    <t>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 <xref target="RFC3756">RFC 3756</xref>. 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.</t>
    
    <t>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 (<xref target="draft-perkins-intarea-multicast-ieee802-03">draft-perkins-intarea-multicast-ieee802-03</xref>).</t>
  </list></t>
  </section>
</section>  

<section title="Mitigations">
  <t>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  <xref target="RFC6775">RFC 6775</xref> ultizing an address registration scheme to limit the need for discovery.</t>

  <t>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.</t>

  <section title="RFC 6583">
    <t><xref target="RFC6583">RFC 6583</xref> suggests some practical mitigations, which can reduce the extent to which ND fails but not eliminate it.</t>
  </section>
 
  <section title="Link-Local">
    <t><xref target="RFC7404">RFC 7404</xref>(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.</t>

    <t>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.</t>
  </section>

  <section title="RFC 6164">
    <t><xref target="RFC6164">RFC 6164</xref> uses /127s allows for the use of /127s for inter-router links. This effectively precludes ND exhaustion attempts for point to point links.</t>
  </section>

  <section title="Firewalls">
    <t>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.</t>
  </section>

  <section title="Subnetting">
    <t>Sizing subnets effectively to support the number of hosts present does limit the scope for ND exhaustion attacks. <xref target="RFC7608">RFC 7608</xref> 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 <xref target="RFC4941">RFC 4941</xref>. In the draft <xref target="draft-bourbaki-6man-classless-ipv6-03">draft-bourbaki-6man-classless-ipv6-03</xref> is a proposal to eliminate the expectation of fixed length subnetting.</t>

    <t>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.</t>

    <t>Use of very long prefixes has the potential to expose subnets to the considerations in <xref target="RFC7707">RFC 7707</xref> 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 <xref target="RFC7707">RFC 7707</xref>  e.g. forward or reverse dns mappings may trivialy reveal the presence of additional hosts within a prefix.</t>
  </section>

  <section title="Stateless Neighbor Presence Discovery">
  <t><xref target="draft-smith-6man-mitigate-nd-cache-dos-slnd">"Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless Neighbor Presence Discovery"</xref> was a proposal by Mark Smith, to aleviate the pressure on the neghbor discovery process when under duress.</t> 
  </section>  

  <section title="Solicitied Node Multicast Group Membership">
  <t><xref target="draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node">"Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership"</xref> 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.</t> 
  </section>  

</section>


<section anchor="Acknowledgements" title="Acknowledgements">
   <t>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.</t>
</section>

   <!-- Possibly a 'Contributors' section ... -->

   <section anchor="IANA" title="IANA Considerations">
     <t>This memo includes no request to IANA.</t>
   </section>

   <section anchor="Security" title="Security Considerations">
     <t>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.</t>
   </section>
 </middle>

 <!--  *****BACK MATTER ***** -->

 <back>
   <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

   <references title="Normative References">
     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
     &RFC2119;

   </references>

   <references title="Informative References">
     <!-- Here we use entities that we defined at the beginning. -->

     &RFC6164;

     &RFC6583;

     &RFC6775; 

     &RFC7404;

     &RFC4941;

     &RFC7608;

     &RFC1885;

     &RFC3756;

     &RFC7707;

          <reference anchor="draft-bourbaki-6man-classless-ipv6-03"
                target="https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-03">
       <front>
         <title>Classes IPv6</title>

         <author>
           <organization>Nicholas Bourbaki</organization>
         </author>

         <date year="2018" />
       </front>
     </reference>

      <reference anchor="draft-perkins-intarea-multicast-ieee802-03"
                target="https://tools.ietf.org/html/draft-perkins-intarea-multicast-ieee802-03">
       <front>
         <title>Multicast Considerations over IEEE 802 Wireless Media</title>

                  <author initials="C" surname="Perkins"><organization></organization></author>
         <date year="2018" />
       </front>
     </reference>

    <reference anchor="draft-smith-6man-mitigate-nd-cache-dos-slnd"
                target="https://datatracker.ietf.org/doc/draft-smith-6man-mitigate-nd-cache-dos-slnd/">
       <front>
         <title>Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless Neighbor Presence Discovery</title>

                  <author initials="M" surname="Smith"><organization></organization></author>
         <date year="2013" />
       </front>
     </reference>

    <reference anchor="draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node"
                target="https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/">
       <front>
         <title>Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless Neighbor Presence Discovery</title>

                  <author initials="M" surname="Smith"><organization></organization></author>
         <date year="2016" />
       </front>
     </reference>

   </references>

 </back>
</rfc>
