idnits 2.17.1 draft-halpern-6man-nddos-mitigation-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 17, 2011) is 4574 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Man J. Halpern 3 Internet-Draft Ericsson 4 Expires: April 19, 2012 October 17, 2011 6 Mitigating Neighbor Discovery Based Denial of Service Attacks 7 draft-halpern-6man-nddos-mitigation-00 9 Abstract 11 It has been observed that with the large space of IPv6 addresses 12 within a subnet, remote attackers can send packets that saturate a 13 rotuers ND cache, and potentially saturate a subnet with ND 14 Soliciation messages as well. Some operational techniques and small 15 protocol adjustments have been proposed that can help alleviate this 16 problem. This draft proposes a slightly more drastic optional 17 behavior for routers, which can nearly eliminate this problem. 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 April 19, 2012. 36 Copyright Notice 38 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Problem Summary and Solution Approach . . . . . . . . . . . . . 3 56 4. Basic Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Protocol Enhancements . . . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 It has been observed that with the large space of IPv6 addresses 68 within a subnet, remote attackers can send packets that saturate a 69 routers ND cache, and potentially saturate a subnet with ND 70 Soliciation messages as well. A thorough description of the problem 71 can be found in [ndproblem]. Some operational techniques and small 72 protocol adjustments have been proposed that can help alleviate this 73 problem are described in [ndenhance]. This draft proposes a slightly 74 more drastic optional behavior for routers, which can nearly 75 eliminate this problem. 77 While the basic behavior described here can be looked upon as a local 78 matter, there are robustness issues if a router applies this solution 79 on its own. Therefore, additional enhancements to the basic ND 80 protocol behavior as defined in [RFC4861] are specified in this 81 document. 83 2. Terminology 85 The terminology here follows that defined in [RFC4861] 87 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 88 HOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 89 document, are to be interpreted as described in [RFC2119]. 91 3. Problem Summary and Solution Approach 93 The basic problem under discussion is the ability for a remote 94 attacker to fill a routers neighbor cache with unresolved, and 95 unresolvable, entries. If done at a sufficient rate, this may 96 prevent the router from maintaining the necessaary entries for 97 actually reaching the hosts on a subnet the router directly serves. 98 Depending upon circumstances, the rate of Neighbor Soliciations 99 messages on the subnet may be high enough to casue difficulties, 100 since these are multicast messages. 102 An attacker causes this problem by sending IPv6 datagrams addressed 103 to distinct hypothetical nonexistant host systems on the subnet. the 104 attacker sends these messages continusously. The router receives 105 these messasges, and as specified in [RFC4861] it generates Neighbor 106 solicitation emssages for each unknown destination, and creates 107 INCOMPLETE Neighbor cache entries for each one. The attacker can use 108 random destination addresses, or even sequential addresses and count 109 on passing the actual hosts quickly. With IPv4, this problem could 110 be coped with in most cases by simply having a table large enough for 111 all the values in the subnet. With IPv6, which reommends subnets be 112 /64s, such sizing is no longer possible. 114 This proposals asks the question, what if the router never accepts 115 packets for unknown hosts on local subnets? In such a case, it would 116 never create INCOMPLETE cache entries, and would never generate 117 Neighbor Solicitation messages based upon received traffic. Instead 118 of soliciating such information, the router would learn of the hosts 119 (and neighboring routers) on the subnet from received information. 121 4. Basic Behavior 123 The basic operational model for the router is still that it maintains 124 a neighbor cache with IPv6->Media address resolution information. It 125 populates this cache upon receiving Rotuer Solicitation or Neighbor 126 Advertisement messages from hosts on the subnet. 128 It is still important thaat the router be able to tell whether hosts 129 are still reachable. As such, routers should assign lifetime 130 information to this ifnormation. As the lifetime approaches, rather 131 than discarding the information, the rotuer can issue a Neighbor 132 Soliciation message to revalidate the information. In the absence of 133 a response, such revalidaiton should be attempted several times. On 134 links were power consumption is a significant issue, it may make 135 sense to simply keep the neighbor cache information without 136 expiration or revalidation. 138 5. Protocol Enhancements 140 While the above description prevents the attack of concern, it has 141 several failure modes. In particular, if a rotuer comes up after a 142 subnet is operational, it will not learn the necessary information. 143 Also, it would seem desirable to provide additional robustness in the 144 learning process, in case too many messages get lost. 146 There are three protocol enhancements that can be used to help this 147 problem. The first mechanism, which has also been proposed for other 148 reasosn, is simply for all hosts on the subnet to keep sending Router 149 Solicitation messages, rather than ceasing after only three 150 transmissions. The rate of sending could be reduced. The message 151 load on the subnet would not be excessive. One might want to adjust 152 the router response to such messages, allowing the router to simply 153 maintain the steady rate of advertisement. This would ensure the 154 router learned of all the hosts on the network in a reasoanble time 155 even if there were unexpected behaviors (partition repair at the link 156 level, for example) which would otherwise interfere. 158 As a variation on the above, one could deefine a "please respond" 159 flag in the Router Advertisement, whcih the routers could set 160 tointermittently to refresh information. As the repeated Router 161 Solicitiations address other issues as well, that seems preferred. 163 While the above enhancement would be sufficient to ensure robustness, 164 it is desirable to be able to deploy this solution before all the 165 hsots on the subnet are upgraded to exhibit that behavior. As such, 166 other robustness techniques are recommended. These approaches rely 167 on the fact that the primary problem occurs when a new router joins 168 an active subnet with an already active serving router providing the 169 same prefix the new router would provide. 171 One thing the existing router could do, which would provided the 172 needed robustness, is to cause all the hsots it knows about to send 173 new Neighbor Advertisements. It can do this by sending each host a 174 Neghbor soliciation with a source address of the unspecified address. 175 This will cause the host to multicast the Neghbor Advertisement it 176 responds with. 178 One may consider that the message exchanges of such a triggering and 179 responding sequence is excessive. As a fall-back, one could easily 180 define an exchange protocol by which an operational router on the 181 subnet could send its neighbor cache to the new router. As this is 182 more complex, more detailed work on that is deferred until it is 183 deemed necessary. 185 6. IANA Considerations 187 There are currently no IANA considerations or assignments in this 188 document. 190 7. Security Considerations 192 There are presumably security implications of this behavioral change, 193 but they have not been evaluated yet. 195 8. References 197 8.1. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 203 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 204 September 2007. 206 8.2. Informative References 208 [ndproblem] 209 Kumari, W., Gashinsky, I., and J. Jaegglie, 210 "I-D.gashinsky-v6ops-v6nd-problems-00.txt", 2011. 212 [ndenhance] 213 Kumari, W., Gashinsky, I., and J. Jaegglie, 214 "I-D.gashinsky-v6nd-enhance-00.txt", October 2011. 216 Author's Address 218 Joel M. Halpern 219 Ericsson 220 P. O. Box 6049 221 Leesburg, VA 20178 222 US 224 Email: joel.halpern@ericsson.com