idnits 2.17.1 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2016) is 2979 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6724' is defined on line 497, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft February 27, 2016 4 Intended status: Informational 5 Expires: August 30, 2016 7 Further Mitigating Router ND Cache Exhaustion DoS Attacks Using 8 Solicited-Node Group Membership 9 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02 11 Abstract 13 For each of their IPv6 unicast or anycast addresses, nodes join a 14 Solicited-Node multicast group, formed using the lower 24 bits of the 15 address. This Solicited-Node group membership could be used by 16 routers to further mitigate a Neighbor Discovery cache Denial of 17 Service attack. 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 http://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 August 30, 2016. 36 Copyright Notice 38 Copyright (c) 2016 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 (http://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 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Tracking Solicited-Node Multicast Group Presence . . . . 4 56 2.2. Neighbor Presence Discovery . . . . . . . . . . . . . . . 5 57 2.2.1. Strict Mitigation Mode . . . . . . . . . . . . . . . 5 58 2.2.2. Relaxed Mitigation Mode . . . . . . . . . . . . . . . 6 59 3. MLD Reliability . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 62 6. Change Log [RFC Editor please remove] . . . . . . . . . . . . 9 63 7. Informative References . . . . . . . . . . . . . . . . . . . 10 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 66 1. Introduction 68 When an IPv6 unicast or anycast address is added to or removed from 69 an interface, a node is also required to join or leave the Solicited- 70 Node multicast group that corresponds to the address 71 [RFC4291][RFC6434], using the Multicast Listener Discovery (MLD) 72 protocol [RFC2710][RFC3810]. The Solicited-Node multicast group the 73 node joins or leaves is determined by appending the lower 24 bits of 74 the unicast or anycast address, usually part of the Interface 75 Identifier (IID), to the IPv6 multicast prefix 76 FF02:0:0:0:0:1:FF00::/104 [RFC4291]. 78 The current use of Solicited-Node multicast groups is to avoid having 79 to link layer broadcast Neighbor Discovery (ND) Neighbor 80 Solicitations to all nodes on the link (ARP's [RFC0826] behaviour for 81 most ARP Requests). Instead, Neighbor Solicitations are sent to the 82 Solicited-Node multicast group formed from the target address of the 83 Neighbor Solicitation. 85 The use of Solicited-Node multicast groups for Neighbor Solicitations 86 allows nodes to possibly filter Neighbor Solicitations they aren't 87 interested in in their link layer network interface, avoiding 88 interrupting the node's general purpose CPU (see sections 7.4 and 7.5 89 of [RFC1112] for further discussion), and possibly for the link layer 90 forwarding device(s) to avoid sending Neighbor Solicitations to nodes 91 that do not have the target address [RFC4541]. Facilitating link 92 layer network interface multicast filtering and reducing the flooding 93 scope of multicasts on a link helps increase the number of nodes that 94 can be attached to a link. 96 As the addition or removal of unicast or anycast addresses triggers 97 Solicited-Node multicast group joins or leaves, this mechanism is in 98 effect a low resolution address range presence registration protocol, 99 registering portions of the on-link address range for which there are 100 unicast or anycast addresses present. The presence of a Solicited- 101 Node multicast group on a link indicates that at least one unicast or 102 anycast address that maps to the Solicited-Node multicast group is 103 present. Conversely, the absence of a Solicited-Node multicast group 104 on a link indicates that no unicast or anycast addresses are present 105 that would map to the corresponding Solicited-Node multicast group. 107 MLDv2 joins for Solicited-Node multicast groups could also be used 108 as a link-local address registration method for at least one of 109 each nodes' link-local addresses, as link-local unicast addresses 110 are used as MLDv2 source addresses, excepting MLDv2 joins for 111 Solicited-Node multicast groups when a link-local address is not 112 available [RFC3590]. It would not be possible to do this reliably 113 with MLDv1 Solicited-Node multicast group joins as MLDv1 listeners 114 will suppress joins for their own groups if they hear a join for 115 the same groups from another listener. 117 This presence or absence of Solicited-Node multicast groups could be 118 used by a router to determine if it needs to send Neighbor 119 Solicitations for unresolved addresses on to the link. If the to-be- 120 resolved address maps to a non-existent Solicited-Node multicast 121 group, the router could discard the packet, rather than sending a 122 Neighbor Solicitation to the corresponding Solicited-Node multicast 123 group for the packet's destination and possibly queuing the trigger 124 packet while neighbor discovery occurs. Discarding trigger packets 125 that map to absent Solicited-Node multicast groups could be a further 126 Neighbor Discovery cache Denial of Service (DoS) attack [RFC3756] 127 mitigation technique. 129 For links with prefixes with lengths shorter than or equal to /104, 130 such as the common /64 [RFC7421], the total number of Solicited-Node 131 multicast groups possible on a link is 2^24, or 16 777 216 groups. 132 The number of Solicited-Node multicast groups present on a link is 133 equal to the number of IPv6 unicast or anycast addresses present on 134 the link which have unique lower 24 bits, used to form the Solicited- 135 Node multicast group address. 137 For most links the number of present Solicited-Node multicast groups 138 present will be in the order of 10s, 100s or perhaps on rarer 139 occasions in the low 1000s. This means that Neighbor Solicitations 140 do not have to be sent for very large numbers of unresolved unicast 141 or anycast addresses for which the corresponding Solicited-Node 142 multicast group is not present. This would significantly reduce the 143 attack surface for the ND cache exhaustion denial of service attack. 145 For example, if a link has 1000 present Solicited-Node multicast 146 groups, then Neighbor Solicitations do not have to be sent for 147 addresses that would map to the absent 16 776 216 Solicited-Node 148 multicast groups, more than 99.99% of the possible on-link Solicited- 149 Node multicast groups. 151 This memo describes how a router could collect Solicited-Node 152 multicast group membership and how it could use this information as 153 part of its neighbor presence discovery procedure, for the purposes 154 of further mitigating the ND cache exhaustion attack. 156 Note that this method has been independently suggested by Greg Daley 157 and perhaps others. 159 2. Method 161 2.1. Tracking Solicited-Node Multicast Group Presence 163 To track Solicited-Node multicast group presence on a link, a router 164 uses the multicast listener discovery procedures specified in 165 [RFC2710] or [RFC3810], without modification. 167 Note that the procedures specified in [RFC2710] and [RFC3810] do not 168 require that a router performing them is to forward multicast 169 packets, or is to be participating in a multicast routing protocol 170 with other multicast routers. The ND cache DoS mitigation method 171 described in this memo can be used regardless of whether the other 172 routers in the network, including other on-link routers, are 173 performing multicast forwarding. 175 If a router using this ND cache DoS mitigation method is not 176 performing multicast forwarding, it may choose to only track 177 Solicited-Node multicast group presence, ignoring the presence 178 information it receives for other multicast groups. This may 179 usefully reduce the router's resources consumption. If a router 180 using this optimisation becomes a multicast forwarding router, it 181 will need to collect presence information for all on-link multicast 182 groups, using the Querier Election procedure [RFC2710][RFC3810], as 183 though it had just been attached to the link, and had no knowledge of 184 the presence any of the multicast groups. 186 A router with two or more interfaces attached to the same link only 187 needs to operate MLD on one of those interfaces [RFC3810]; the list 188 of on-link Solicited-Node multicast groups would be used across all 189 of these interfaces when mitigating ND cache DoSes. 191 2.2. Neighbor Presence Discovery 193 When a router receives a packet for a destination for which it does 194 not have a neighbor cache entry, it uses the [RFC4291] specified 195 method to form a Solicited-Node multicast group address from the 196 packet's destination address. 198 The router then compares the resulting Solicited-Node multicast group 199 address with its list of present Solicited-Node multicast groups on 200 the link. 202 If the Solicited-Node multicast group is present, the router then 203 performs the address resolution procedure for the packet's 204 destination IPv6 address as specified in [RFC4861], starting with 205 sending a Neighbor Solicitation towards the Solicited-Node multicast 206 group that corresponds to the address. 208 Alternatively, when the Solicited-Node multicast group is not 209 present, the router operates in one of two mitigation modes. 211 2.2.1. Strict Mitigation Mode 213 When operating in Strict Mitigation Mode, the router discards all 214 packets whose destination address Solicited-Node multicast groups do 215 not match any of the Solicited-Node multicast groups present on the 216 link. 218 Strict Mitigation Mode makes the decision to perform Neighbor 219 Discovery dependent on the successful discovery of the Solicited-Node 220 multicast groups on the link by MLD. This means that if the router 221 is assembling a list of present Solicited-Node multicast groups from 222 scratch, such as after the router has been intialised, or when an 223 interface comes online, there will be a period where Neighbor 224 Discovery for existing nodes will not occur, while the full set of 225 present Solicited-Node multicast groups are discovered. To off-link 226 hosts sending traffic to the possible on-link hosts, this will appear 227 to be a period of packet loss. These hosts are expected to have 228 implemented methods to recover from transient failures of 229 transmission, such as packet retransmission, if necessary [RFC1958]. 231 This mode of operation is appropriate when it is known that all 232 attached nodes announce their Solicited-Node multicast group 233 membership for their addresses, and MLD operation on the link is 234 known to be reliable. An example scenario would be a large Internet 235 content provider's environment, where the content network routers and 236 content servers are being operated by the same organisation. 238 2.2.2. Relaxed Mitigation Mode 240 When operating in Relaxed Mitigation Mode, under normal non-DoS 241 circumstances the router will also perform the address resolution 242 procedure for packets whose destination address Solicited-Node 243 multicast group does not match any of the Solicited-Node multicast 244 groups present on the link. 246 However, when there is an indication that a neighbor cache Denial of 247 Service attack might be occurring, the router treats packets whose 248 destination address Solicited-Node multicast group does not match a 249 link present Solicited-Node multicast group with lower importance to 250 those packets whose do. 252 Indicators that a neighbor cache Denial of Service attack might be 253 occurring could be many failed address resolution attempts over a 254 short period of time, rapid and unexpected consumption of neighbor 255 cache resources (rapid consumption for a short period of time after 256 the link or router has come on-line could be expected), or some other 257 pattern of neighbor cache Denial of Service attack specific 258 behaviour. 260 If a neighbor cache Denial of Service attack appears to be occurring, 261 an implementation could immediately start discarding packets whose 262 destination address Solicited-Node multicast group does not match 263 those present on the link. A less harsh alternative would be to 264 start discarding some of these packets, increasing the discard rate 265 as neighbor cache resources are increasingly consumed by the Denial 266 of Service attack. 268 This mode of operation would be appropriate when it is not known if 269 all nodes will announce their Solicited Node multicast group 270 membership, possibly due to some nodes being pre-[RFC2710] 271 implementations or if MLD operation is not known to be reliable. 272 Example scenarios would be residential or public Internet access 273 networks, where the support for or reliability of MLD joins for 274 Solicited Node multicast groups is not known. Specific to the 275 residential network case, where the technical ability of the router 276 operator is not known and likely to be low, Relaxed Mitigation Mode 277 would be the safest default. 279 3. MLD Reliability 281 MLD is currently being used for two purposes: 283 o to join and leave multicast groups so that multicast applications 284 will receive routed multicast traffic they are interested in 285 receiving [RFC2710][RFC3810], and 287 o to advise link layer devices of node multicast group membership to 288 allow the link layer devices to limit to which devices multicast 289 traffic is sent, instead of flooding multicast traffic to all 290 attached devices [RFC4541]. Specific to this memo's topic, nodes 291 using MLD to join Solicited-Node multicast groups for their 292 addresses allows link layer devices to limit to which nodes 293 multicast Neighbor Solicitations are sent. 295 For the first purpose, partial or complete failure of MLD to 296 successfully join the intended multicast group(s) will likely cause 297 the respective multicast application(s) to not function adequately or 298 completely. While likely to be unacceptable to the application(s') 299 user(s), the effects of the failure are limited to the impacted 300 application(s); some multicast applications may function, and other 301 unicast-only applications will not be impacted. 303 For the second purpose, partial or complete failure of MLD operation 304 means the link layer device will not forward multicast traffic to 305 devices for groups for which MLD joins failed. As with the first MLD 306 purpose, application operation is likely to be impacted. MLD join 307 failures for Solicited-Node multicast groups would mean that 308 Duplicate Address Detection [RFC4861] and Neighbor Discovery 309 [RFC4861] for the node's addresses will fail. IPv6 unicast 310 connectivity for the effected node could be severely impacted, and 311 possibly fail completely. 313 For this memo's method, when operating in Strict Mitigation Mode, 314 partial or complete failure of MLD for Solicited-Node multicast group 315 joins will cause Neighbor Discovery to fail for routers implementing 316 this neighbor cache Denial of Service attack mitigation. The 317 effected nodes will be unreachable for traffic sources beyond the 318 impacted router. 320 With this memo's method, when operating in Relaxed Mitigation Mode, 321 partial or complete failure of MLD for Solicited-Node multicast group 322 joins will cause the router to consider neighbor discovery for the 323 effected node's addresses to be of lower importance. Under normal, 324 non-neighbor cache Denial of Service circumstances, these nodes will 325 receive equal service to those who've successfully joined the 326 Solicited-Node multicast groups via MLD. If a neighbor cache Denial 327 of Service occurs, these MLD failed nodes will either have less 328 success at or complete failure of being discovered by the router 329 performing neighbor discovery. In this situation, some rather than 330 all of the nodes will have been impacted by the Denial of Service 331 attack, which is an improvement over the attack impacting all nodes. 333 It is important to note that failure of neighbor discovery during a 334 neighbor cache Denial of Service attack will only impact nodes that 335 have not been previously discovered by the router. If a node has 336 been previously discovered, its neighbor information will already 337 reside in the router's neighbor cache, and its currency will be 338 maintained by Neighbor Unreachability Detection [RFC4861]. 340 Due to the number of significant consequences of MLD failure, 341 including those introduced by this memo's method, MLD should be 342 configured to operate reliably if the default MLD reliability related 343 parameter values are not adequate [RFC2710][RFC3810]. Although 344 [RFC6636] provides advice for tuning MLD operation for mobile and 345 wireless networks, some of the advice and considerations might be 346 more generally applied. 348 4. Security Considerations 350 The method described in this memo further mitigates the ND cache 351 exhaustion DoS attack. It does not prevent it. 353 Using this method, neighbor presence discovery will occur for any of 354 the unicast or anycast addresses that map to the present Solicited- 355 Node multicast groups. As a Solicited-Node multicast group can map 356 to up to 2^40 unicast or anycast addresses (for a /64 prefix, 2^(64 - 357 24)), the ND implementation is likely to continue to be vulnerable to 358 a ND cache exhaustion denial of service for addresses covered by the 359 present Solicited-Node multicast groups. While the number of non- 360 existent addresses that can be targetted remains very large, it is 361 very significantly smaller than the targettable non-existent 362 addresses possible in the on-link prefixes without this measure. 364 The severity of this threat depends on two factors: 366 o the number of Solicited-Node multicast groups present on the link, 367 and 369 o the ability of the off-link attacker to stumble upon or discover 370 non-existent addresses that map to present Solicited-Node 371 multicast groups. 373 The severity of the threat is lower with lesser numbers of Solicited- 374 Node multicast groups, and less predictable and sparsely distributed 375 Solicited-Node multicast group addresses. 377 [RFC7217] specifies the use of stable yet random and unpredictable 378 IIDs, on a per-prefix basis. This will increase the number of 379 present Solicited-Node multicast groups, by up to the number of 380 prefixes multiplied by the number of hosts implementing [RFC7217]. 381 This will reduce the effectiveness of the measure proposed in this 382 memo. However, it will also conversely increase the effectiveness of 383 this measure, as the IIDs and therefore the Solicited-Node multicast 384 groups become less predictable and more sparsely distributed. 386 To protect against ND cache DoS attacks for non-existent addresses 387 that map to present Solicited-Node multicast groups, other ND cache 388 protection measures, such as those described in [RFC6583] should also 389 be implemented. 391 When a packet is sent to a destination that is unresolved and is not 392 covered by a present Solicited-Node multicast group, a copy could be 393 sent to an [RFC6018] greynet collector for further analysis. For 394 example, packet sent to destinations falling outside the present 395 Solicited-Node multicast groups could be an indication of an attempt 396 to discover nodes via address probing. 398 5. Acknowledgements 400 Review and comments were provided by (in alphabetical order) Fred 401 Baker, Lorenzo Colitti and Ray Hunter. Lorenzo expressed a concern 402 about MLD reliability and its consequences, which prompted the 403 creation of the two modes of mitigation and the MLD reliability 404 discussion. 406 This memo was prepared using the xml2rfc tool. 408 6. Change Log [RFC Editor please remove] 410 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00, initial 411 version, 2014-04-08 413 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01, 2016-02-08 415 o two modes of response to possible neighbor cache DoS 417 o MLD reliability discussion 419 o Expansion on the purpose of using solicited-node multicast groups 421 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02, 2016-02-28 423 o "discard" rather than "drop" to show intentional dropping 425 o text about Strict Mode MLD discovery period 427 7. Informative References 429 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 430 Converting Network Protocol Addresses to 48.bit Ethernet 431 Address for Transmission on Ethernet Hardware", STD 37, 432 RFC 826, DOI 10.17487/RFC0826, November 1982, 433 . 435 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 436 RFC 1112, DOI 10.17487/RFC1112, August 1989, 437 . 439 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 440 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 441 . 443 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 444 Listener Discovery (MLD) for IPv6", RFC 2710, 445 DOI 10.17487/RFC2710, October 1999, 446 . 448 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 449 Listener Discovery (MLD) Protocol", RFC 3590, 450 DOI 10.17487/RFC3590, September 2003, 451 . 453 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 454 Neighbor Discovery (ND) Trust Models and Threats", 455 RFC 3756, DOI 10.17487/RFC3756, May 2004, 456 . 458 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 459 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 460 DOI 10.17487/RFC3810, June 2004, 461 . 463 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 464 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 465 2006, . 467 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 468 "Considerations for Internet Group Management Protocol 469 (IGMP) and Multicast Listener Discovery (MLD) Snooping 470 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 471 . 473 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 474 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 475 DOI 10.17487/RFC4861, September 2007, 476 . 478 [RFC6018] Baker, F., Harrop, W., and G. Armitage, "IPv4 and IPv6 479 Greynets", RFC 6018, DOI 10.17487/RFC6018, September 2010, 480 . 482 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 483 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 484 2011, . 486 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 487 Neighbor Discovery Problems", RFC 6583, 488 DOI 10.17487/RFC6583, March 2012, 489 . 491 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 492 the Internet Group Management Protocol (IGMP) and 493 Multicast Listener Discovery (MLD) for Routers in Mobile 494 and Wireless Networks", RFC 6636, DOI 10.17487/RFC6636, 495 May 2012, . 497 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 498 "Default Address Selection for Internet Protocol Version 6 499 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 500 . 502 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 503 Interface Identifiers with IPv6 Stateless Address 504 Autoconfiguration (SLAAC)", RFC 7217, 505 DOI 10.17487/RFC7217, April 2014, 506 . 508 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 509 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 510 Boundary in IPv6 Addressing", RFC 7421, 511 DOI 10.17487/RFC7421, January 2015, 512 . 514 Author's Address 515 Mark Smith 516 PO BOX 521 517 HEIDELBERG, VIC 3084 518 AU 520 Email: markzzzsmith@gmail.com