idnits 2.17.00 (12 Aug 2021) /tmp/idnits27787/draft-jaeggli-v6ops-indefensible-nd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6583]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 1412 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7404' is defined on line 332, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1885 (Obsoleted by RFC 2463) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops J. Jaeggli 3 Internet-Draft Fastly 4 Intended status: Informational July 2, 2018 5 Expires: January 3, 2019 7 Indefensible Neighbor Discovery 8 draft-jaeggli-v6ops-indefensible-nd-01 10 Abstract 12 NDP resource exhastion is a problem which cannot fundamently be 13 addressed through limited protocol changes or implementation tweaks; 14 mitigations proposed in RFC 6583 [RFC6583] may well prevent the 15 outright failure of a device under duress. This draft discusses some 16 mitigations which have or can be employeed by networks looking to 17 reduce or eliminate the exposure of the Neighbor Discovery Process. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 3, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. ND under stress . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Ways in which resources are consumed: . . . . . . . . . . 3 57 3. Mitigations . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. RFC 6583 . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Link-Local . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. RFC 6164 . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.5. Subnetting . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.6. Stateless Neighbor Presence Discovery . . . . . . . . . . 5 64 3.7. Solicitied Node Multicast Group Membership . . . . . . . 6 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 7.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Neighbor discovery serves to allow the discovery of hosts and the 76 self assignment of resources within the sparse address space of IPv6 77 subnets. Since the definition of Interface IDs and accompanying 78 subnet sizes RFC 1885 [RFC1885] the potential has existed for the 79 forwarding and control plane resources of a router to be greatly 80 exceeded by locally or remotely triggered attempts to desocver 81 connected neighbors. The problem of the number of adjacencies that 82 can reasonably be supported and signaled in not unique to IPv6 though 83 it is especially accute there. It also exists in IPv4 as well as 84 other non-internet protocols. Practical scaling limits of the number 85 of adjaciences or amount of signaling serve as incentives for 86 operators to limit the size and number of participants in layer-2 87 domains. 89 Because of the size of typical IPv6 Interface IDs as well as the 90 property of self-assignment, IPv6 subnets and connected devices are 91 particularly exposed to resource consumption; therefore proactive 92 mitigations are required to limit the potential for resource 93 consumption resulting in Denial of Service. In RFC 6583 [RFC6583], 94 we detailed the threat posed by neighbor discovery resource 95 consumption to network devices as well as some mitigations which 96 could improve the situation. While some mitigations remove the 97 threat entirely; RFC 6164 [RFC6164] style /127 prefixes for example 98 are not subject to ND attacks, they have the property of not being 99 practical for subnets supporting end systems. Practical mitigations 100 in RFC 6583 section 7 [RFC6583] implementation advice serve to tamp 101 down, but cannot entirely eliminate the threat of resource 102 exhaustion; devices operating under durress cannot be expected to 103 perform as well as devices which are not. 105 If we are to characterize the achitectural challenge posed by ARP and 106 ND. It is that traffic in the data-plane from untrusted source may 107 impose demands on the control plane to create and then exhaust 108 available state. In IPv4 the mitigiation for this is for the most 109 part relatively trivial and tighly coupled to subnet and forwarding 110 hardware sizing; address conservation principles that do not apply to 111 IPv6 subnets therefore generally but not entirely ameliorate this 112 problem in IPv4. 114 1.1. Requirements Language 116 This document does not employ and should not interpreted through RFC 117 2119 [RFC2119] requirements language. 119 2. ND under stress 121 In characterizing the behavior of devices under stress we posit that 122 the neighbor discovery process responsible for resolving an 123 effectively unlimited number of unknown neighbors itself is 124 ultimately indefensible. By Indefensible we mean that if implemented 125 as intended by 4861 the protocol is always exposed to resource 126 consumption constraints that require mitigation. 128 2.1. Ways in which resources are consumed: 130 o Host-routes / Negative cache entries - IPv6 subnets do not have 131 constraints on the number of addresses which can be employed 132 within the limit (64 bits) imposed by the subnet mask. Networks 133 employing stateful DHCP v6 address assignment can make some 134 assumptions about the number of host to address mappings they are 135 willing to support, devices performing SLAAC and deriving 136 addresses subsequently are under no such constraints. 138 o CPU / RAM - Neighbor Discovery is intended to be triggered for 139 addresses for which no layer-2 next-hop yet exists. This allows 140 for the classical DDOS of the ND process described in RFC 3756 141 [RFC3756]. Since the senders of packets which might trigger ND 142 are not subject to the same constraints as devices which have to 143 initiate it this asymmetry is trivial to exercise. 145 o Multicast - Multicast replication of Neighbor solicitations may be 146 expensive for certain link-layers or hosts particularly wireless 147 networks. In cases where multicast is transmitted at lower rates 148 then the prevailing unicast rate, performance of other traffic may 149 be directly impacted by the presence of this traffic even at 150 relatively low levels (draft-perkins-intarea-multicast-ieee802-03 151 [draft-perkins-intarea-multicast-ieee802-03]). 153 3. Mitigations 155 Recognition of the short-comings of IPv6 neighbor discovery are 156 sufficiently common that link-layers supporting resource constrained 157 infrastructure typically have to address them directly, 6LowPAN for 158 example has RFC 6775 [RFC6775] ultizing an address registration 159 scheme to limit the need for discovery. 161 There are various forms of mitigation which can be applied in order 162 to avoid having neighbor discovery become the ineluctable bottleneck 163 in defending a subnet. Many of these approaches are more specially 164 changes to harden networks or transfer the burden of state rather 165 than alterations of the neighbor discovery process itself. 167 3.1. RFC 6583 169 RFC 6583 [RFC6583] suggests some practical mitigations, which can 170 reduce the extent to which ND fails but not eliminate it. 172 3.2. Link-Local 174 RFC 7404 [RFC7404](Using Only Link-Local Addressing inside an IPv6 175 Network) style approaches, link-local-only numbered interfaces make 176 it impossible to target the subnet address from off-link, at the cost 177 of limiting the ability to ping interfaces, return useful interface 178 IPs in traceroute and so on. 180 Link-local-only addressing may be extended to Hosts by assigning 181 unicast addressees on loopback interfaces rather than on subnet 182 connected interfaces. In conjunction with routing (typically BGP but 183 alternatives are possible), it is possible to construct networks in 184 which no external targeting of neighbor discovery on connected 185 subnets is possible. The existence of a prefix of arbitrary length 186 is signaled in a routing protocol. Probes addressed to unused 187 addresses may be discarded by an aggregate route. 189 3.3. RFC 6164 191 RFC 6164 [RFC6164] uses /127s allows for the use of /127s for inter- 192 router links. This effectively precludes ND exhaustion attempts for 193 point to point links. 195 3.4. Firewalls 197 Stateful inspection firewalls may limit the expense of performing 198 neighbor discovering for unknown addresses by discarding packets for 199 unestablished connections. While this may be a transfer of expense 200 from one account (ND) to another (firewall) it never-the-less 201 precludes targeting subnets for NDP exhaustion. 203 3.5. Subnetting 205 Sizing subnets effectively to support the number of hosts present 206 does limit the scope for ND exhaustion attacks. RFC 7608 [RFC7608] 207 does instruct that devices be able to forward to arbitrary length 208 subnets. Arbitrary length subnets e.g. a /120 or /121 are presently 209 considered incompatible with SLAAC and conflict with some goals for 210 privacy address RFC 4941 [RFC4941]. In the draft draft-bourbaki- 211 6man-classless-ipv6-03 [draft-bourbaki-6man-classless-ipv6-03] is a 212 proposal to eliminate the expectation of fixed length subnetting. 214 Alternative to resizing the subnet, stateful DHCPv6 address 215 assignment can be used to limit the range of IPs within a /64 subnet 216 which are consumed which may be used to ACL to target sub-prefixes of 217 the entire subnet. 219 Use of very long prefixes has the potential to expose subnets to the 220 considerations in RFC 7707 [RFC7707] where for example neighboring 221 devices on a subnet might be trivial to discover via scanning as for 222 example are router interfaces numbered as "::1" out of convience . 223 The extent to which discoverability is an issue may vary by usage and 224 also methodoly, so for example sparsely allocated pseudo-randomly 225 assigned /128s may be no more discoverable then IPv6 self assigned 226 privacy addresses, but machines clumped together in a /121 may be 227 trivially identified when one of them is located. other methods of 228 discovering detailed in RFC 7707 [RFC7707] e.g. forward or reverse 229 dns mappings may trivialy reveal the presence of additional hosts 230 within a prefix. 232 3.6. Stateless Neighbor Presence Discovery 234 "Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless 235 Neighbor Presence Discovery" 236 [draft-smith-6man-mitigate-nd-cache-dos-slnd] was a proposal by Mark 237 Smith, to aleviate the pressure on the neghbor discovery process when 238 under duress. 240 3.7. Solicitied Node Multicast Group Membership 242 "Further Mitigating Router ND Cache Exhaustion DoS Attacks Using 243 Solicited-Node Group Membership" 244 [draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node] was a proposal by 245 Mark Smith, to use the solicited node multicast group to limit the 246 need to multicast ND to all ports when performing ND. 248 4. Acknowledgements 250 This Document is entirely depedent on previous work done in the IETF 251 community and other authors. Mark Smith offered valuable 252 contributions and References to the initia Draft. Brian Carpenter 253 reviewed the initial draft and provided additional references. 255 5. IANA Considerations 257 This memo includes no request to IANA. 259 6. Security Considerations 261 All drafts are required to have a security considerations section. 262 This document is essentially a collection of related security 263 considerations, it is hoped that by exploring these issues somce 264 insight into the rational and methodology for mitigating the exposure 265 posed by ND ay be gained. Some methods considered here are currently 266 and may remain non-standard. 268 7. References 270 7.1. Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, 274 DOI 10.17487/RFC2119, March 1997, 275 . 277 7.2. Informative References 279 [draft-bourbaki-6man-classless-ipv6-03] 280 Nicholas Bourbaki, "Classes IPv6", 2018, 281 . 284 [draft-perkins-intarea-multicast-ieee802-03] 285 Perkins, C., "Multicast Considerations over IEEE 802 286 Wireless Media", 2018, . 289 [draft-smith-6man-mitigate-nd-cache-dos-slnd] 290 Smith, M., "Mitigating IPv6 Neighbor Discovery DoS Attack 291 Using Stateless Neighbor Presence Discovery", 2013, 292 . 295 [draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node] 296 Smith, M., "Mitigating IPv6 Neighbor Discovery DoS Attack 297 Using Stateless Neighbor Presence Discovery", 2016, 298 . 301 [RFC1885] Conta, A. and S. Deering, "Internet Control Message 302 Protocol (ICMPv6) for the Internet Protocol Version 6 303 (IPv6)", RFC 1885, DOI 10.17487/RFC1885, December 1995, 304 . 306 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 307 Neighbor Discovery (ND) Trust Models and Threats", 308 RFC 3756, DOI 10.17487/RFC3756, May 2004, 309 . 311 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 312 Extensions for Stateless Address Autoconfiguration in 313 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 314 . 316 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 317 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 318 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 319 . 321 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 322 Neighbor Discovery Problems", RFC 6583, 323 DOI 10.17487/RFC6583, March 2012, 324 . 326 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 327 Bormann, "Neighbor Discovery Optimization for IPv6 over 328 Low-Power Wireless Personal Area Networks (6LoWPANs)", 329 RFC 6775, DOI 10.17487/RFC6775, November 2012, 330 . 332 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 333 Addressing inside an IPv6 Network", RFC 7404, 334 DOI 10.17487/RFC7404, November 2014, 335 . 337 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 338 Length Recommendation for Forwarding", BCP 198, RFC 7608, 339 DOI 10.17487/RFC7608, July 2015, 340 . 342 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 343 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 344 . 346 Author's Address 348 Joel Jaeggli 349 Fastly 350 Mountain View, CA 94043 351 US 353 Phone: +5415134095 354 Email: joelja@bogus.com