idnits 2.17.00 (12 Aug 2021) /tmp/idnits10632/draft-halpern-6man-nd-pre-resolve-addr-00.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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 103: '... 1) SHOULD NOT remove a populated...' RFC 2119 keyword, line 106: '... 2) SHOULD NOT remove a DAD trigg...' RFC 2119 keyword, line 109: '... 3) SHOULD remove remote trigger ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 10, 2014) is 3046 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft I. Chen 3 J. Halpern 4 Category: Informational Ericsson 5 Expires in 6 months January 10, 2014 7 Triggering ND Address Resolution on Receiving DAD-NS 8 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on date. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as 38 the document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This draft proposes a new optional event to trigger address 50 resolution using IPv6 Neighbor Discovery. This helps optimize router 51 performance, and can help mitigate certain potential ND-related 52 denial-of-service attacks. Upon receiving a DAD-NS message, the 53 neighbor solicitation message used to detect duplicate addresses, if 54 the target address encoded in the DAD-NS is not a duplicate address, 55 the receiving device responds by triggering address resolution for 56 the target address in the DAD-NS, in preparation for expectant future 57 communication with the sending device. 59 Table of Contents 61 1. Introduction ....................................................3 62 2. Proposed Trigger for Address Resolution .........................4 63 3. Which Devices to Upgrade and the Consequences ...................6 64 4. Security Considerations .........................................6 65 5. IANA Considerations .............................................6 66 6. References ......................................................6 68 1. Introduction 70 Due to the large address space for IPv6 [RFC2460] and a large /64 71 default subnet size, Neighbor Discovery (ND) for IPv6 [RFC4861] could 72 suffer from off-link flooding Denial-of-Service (DoS) attacks 73 [RFC6583]. In such an attack, a remote malicious device could flood 74 a router with packets destined to billions of unassigned IPv6 75 addresses. Although these packets are destined to unused IPv6 76 addresses, cache misses could occur nonetheless. Without special 77 handling of cache misses, the router would trigger address resolution 78 for billions of unused IPv6 addresses. The sheer volume of IPv6 79 addresses could overwhelm the router's normal ND protocol processing 80 and ultimately prevent the router from forwarding packets destined to 81 legitimate IPv6 addresses. 83 [RFC6583] proposes implementation and operational practices to reduce 84 the impact of an off-link flooding DoS attack without modifying the 85 ND protocol. The Internet Draft [ndmit] goes further and poses the 86 question whether cache misses, an important trigger for address 87 resolution in the ND protocol, are necessary. If cache misses can be 88 ignored, then an off-link flooding DoS attack that uses cache misses 89 to compromise a router can be neutralized. To eliminate the need for 90 cache misses, a router should retain the neighbor cache entries of 91 all legitimate neighbors on the physical link. 93 This draft proposes that a router further triggers address resolution 94 based on an event other than a cache miss. In addition to waiting 95 for a cache miss to trigger address resolution, a router should 96 initiate address resolution for the target address in a DAD-NS, 97 provided that the target address is not a duplicate address of the 98 receiving device or a resolved neighbor. 100 Consequently, to optimize IPv6 router performance and to avoid 101 neighbor cache overrun by remote exploration, an IPv6 device: 103 1) SHOULD NOT remove a populated cache entry to make room for a 104 pending entry based on a received packet trigger. 106 2) SHOULD NOT remove a DAD triggered pending entry to make room 107 for a remote received packet triggered entry. 109 3) SHOULD remove remote trigger pending entries if needed to make 110 room for DAD triggered pending entries. 112 For an even stronger solution to prevent neighbor cache overrun by 113 remote exploration, a router can implement [ndmit] in conjunction 114 with the mechanism in this draft. 116 2. Proposed Trigger for Address Resolution 118 In IPv6, when a device initializes an interface, a special Neighbor 119 Solicitation (NS) message is sent to perform Duplicate Address 120 Detection (DAD) [RFC4862] to determine whether a particular address 121 is already assigned to a different interface on the same multi-access 122 link. This special message, referred to as DAD-NS in the rest of 123 this draft, is an NS message with an unspecified source address. The 124 target address of this DAD-NS is the IPv6 unicast address that is 125 intended for new interface. 127 In addition to the detection of duplicate addresses, a DAD-NS can 128 also be treated as an announcement for a new address, the target 129 address in the DAD-NS, which will be used in the near future, after 130 the DAD algorithm has been completed. Consequently, after allowing 131 time for the DAD algorithm to be completed, rather than waiting for a 132 cache miss, the router that received the DAD-NS can perform address 133 resolution for the target address in the DAD-NS. 135 The proposed steps are similar to how address resolution is initiated 136 when a device receives a regular NS message, one that has a specified 137 source address. The difference in the mechanism proposed by this 138 draft is that the address resolution is not triggered immediately 139 after receiving the DAD-NS. Instead, address resolution is triggered 140 with a time delay to accommodate the DAD algorithm. 142 For example in Figure 1, when DEV2 initializes an interface that is 143 expected to use the IP address 2001::15, a DAD-NS with an unspecified 144 source address and a target address of 2001::15 is multicast on the 145 physical link. Following the DAD algorithm in [RFC4862], when DEV1 146 on the physical link receives such a DAD-NS, the DEV1 device does not 147 respond to the DAD-NS if the target address 2001::15 is not used by 148 one of its interfaces. Assuming that DEV1 implements the proposed 149 DAD-NS response in this draft, then after allowing for the DAD 150 algorithm to be completed, DEV1 can trigger address resolution for 151 2001::15, the target address announced in the previous DAD-NS, 152 without waiting for a cache miss to occur. 154 Furthermore, when DEV2 receives the NS to query for target address 155 2001::15, [RFC4861] Section 7.2.3 specifies that DEV2 respond with an 156 NS query of its own for the source address of the NS that DEV2 just 157 received. Thus, at the end of the DAD-NS, NS, and Neighbor 158 Advertisement (NA) message exchanges that are triggered by the 159 initialization of DEV2's interface, DEV1 and DEV2 have each others' 160 neighbor entries. The two devices can immediately begin 161 communication shortly after DEV2 sends the DAD-NS and very likely 162 before any cache miss occurs. 164 + 165 +----+ | 166 |DEV1|-----------------------| 167 +----+ | +----+ 168 |------------------------|DEV2| 169 | +----+ 170 + 171 2001::1/MAC1 ASSIGNED 2001::15/MAC2 TENTATIVE 173 DAD-NS (source address UNSPECIFIED) (target address 2001::15) 174 <------------------------------------------------------------ 176 Neighbor entry 177 2001::15 INCOMPLETE 179 2001::15/MAC2 ASSIGNED 181 NS (source address 2001::1) (target address 2001::15) 182 ----------------------------------------------------> 184 Neighbor entry 185 2001::1 INCOMPLETE 187 NA (source address 2001:15) (target address 2001::15) (MAC2) 188 <----------------------------------------------------------- 190 Neighbor entry 191 2001::15/MAC2 REACH 193 NS (source address 2001::15) (target address 2001::1) 194 <---------------------------------------------------- 196 NA (source address 2001::1) (target address 2001::1) (MAC1) 197 ----------------------------------------------------------> 199 Neighbor entry 200 2001::1/MAC1 REACH 202 Figure 1. An example of DAD-NS triggering address resolution. 204 3. Which Devices to Upgrade and the Consequences 206 This proposed mechanism does not require changes to [RFC4861]. 207 Further, devices that implement this proposal can interoperate with 208 devices that do not implement this proposal. Ericsson's Smart 209 Services Router implemented this change in early 2013, is deployed in 210 operational IPv6 networks, and has not encountered any problems. 212 The proposed mechanism probably is more useful for routers than for 213 hosts, although nothing prevents a host from implementing this 214 proposal and hosts might benefit from implementing this proposal. 216 If all devices, both routers and hosts, on a physical link implement 217 the proposed change, then when a device restarts, the restarting 218 device can easily recover all the pre-restart neighbor cache entries. 219 Using Figure 1 as an example, assume that DEV2 restarts and re- 220 initializes its interface, and once again wishes to assign its 221 interface the address 2001::15. Because DEV1 implements this draft 222 and responds to the DAD-NS by querying for 2001::15, both DEV1 and 223 DEV2 end up with the same neighbor cache entries from before DEV2 224 restarted. 226 4. Security Considerations 228 The proposed trigger for address resolution might suffer from certain 229 attacks if the attacker is on the same physical link as the new IPv6 230 device and sends bogus DAD-NS messages. However, no mechanism can 231 protect a device when the attacker is on the same physical link as 232 the device, other than ensuring that only authorized devices have 233 access to a physical link (e.g., by using link-layer security 234 mechanisms, such as IEEE 802.1AE link encryption [802.1AE]). 236 5. IANA Considerations 238 No actions are required from IANA as result of the publication of 239 this document. 241 6. References 243 6.1. Normative References 245 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 246 (IPv6) Specification", RFC 2460, December 1998. 248 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 249 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 250 September 2007. 252 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 253 Address Autoconfiguration", RFC 4862, September 2007. 255 6.2. Informative References 257 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 258 Neighbor Discovery Problems", RFC 6583, March 2012. 260 [ndmit] Halpern, J, Work in progress, "draft-halpern-6man-nddos- 261 mitigation-00", October 2011. 263 [802.1AE] IEEE Standards Association, "IEEE Standard for Local and 264 Metropolitan Area Networks: Media Access Control (MAC) 265 Security", IEEE Standard 802.1AE, IEEE, Piscataway, NJ, 266 USA, August 18, 2006. 268 Authors' Addresses 270 I. Chen 271 Ericsson 272 Email: ing-wher.chen@ericsson.com 274 J. Halpern 275 Ericsson 276 EMail: joel.halpern@ericsson.com