idnits 2.17.1 draft-jiang-v6ops-nc-protection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2010) is 5167 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 V6OPS Work Group S. Jiang 2 Internet Draft X. Chen 3 Intended status: Standard Stack X. Song 4 Expires: August 28, 2010 Huawei Technologies Co., Ltd 5 March 2, 2010 7 Neighbor Cache Protection in Neighbor Discover Protocol 8 draft-jiang-v6ops-nc-protection-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on August 28, 2010. 32 Copyright Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the BSD License. 47 Abstract 49 In Neighbor Discover Protocol, routers and hosts record the neighbor 50 information in the local Neighbor Cache database. It is vulnerable by 51 malicious attacks. This document analyzes these security threats and 52 proposes a solution, mainly using reverse detection mechanism, to 53 prevent the potential damage. 55 Table of Contents 57 1. Introduction................................................3 58 2. Terminology.................................................3 59 3. Motivations and Issues.......................................3 60 4. Solution: Reverse Detection..................................4 61 5. Additional Discussion........................................5 62 5.1. Exceptional LLAs........................................5 63 5.2. Looped reverse detection................................6 64 5.3. Rate limit for incoming NS..............................6 65 5.4. CPU & memory protection.................................6 66 6. Security Considerations......................................6 67 7. IANA Considerations.........................................6 68 8. Change Log [RFC Editor please remove]........................7 69 9. References..................................................7 70 9.1. Normative References....................................7 71 9.2. Informative References..................................7 72 Author's Addresses.............................................8 74 1. Introduction 76 In Neighbor Discover protocol (ND, [RFC4861]), routers and hosts 77 record the neighbor information in the local Neighbor Cache (NC) 78 database. It is vulnerable by DOS attacks. In the current definition, 79 it is difficult to detect whether the neighbor information are from a 80 real neighbor or a faked attacker. This document analyzes these 81 security threats. Although SEcure Neighbor Discovery Protocol (SEND) 82 is defined as upgrade/replaced version of ND, it is very complicated 83 and does not widely deployed yet. 85 This document proposes a Neighbor Cache protection solution, mainly 86 using reverse detection mechanism, to prevent the potential damage. 87 This solution is based on the procedures that already defined in the 88 current ND definition, so it is fully compatible with ND. This design 89 principle allows that most of network devices remain on their current 90 ND implementation, only the devices that need advanced NC protection 91 apply the proposed mechanism. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC2119 [RFC2119]. 99 3. Neighbor Cache Threats 101 In the IPv6 edge network, hosts and routers use Neighbor Discovery 102 protocol to resolve the neighbors known to reside on attached links. 103 The neighbors' information, such as the paired mapping of link-layer 104 addresses and IPv6 addresses, is recorded in a local Neighbor Cache 105 database. 107 However, the NC is vulnerable by malicious attacks. A Denial of 108 Service (DoS) attack against the NC of an IPv6 node (host or router) 109 can fill up with faked entries and exhaust the cache's resources. 110 This interrupts the normal functions of the targeted IPv6 node. If 111 the attack is successful in overwhelming a forwarding router, the 112 edge network may be disconnected from the global Internet. By sending 113 a faked Neighbor Solicitation message, an attacker can make the 114 target node allocate a Neighbor Cache entry for a period of time. If 115 the attacker repeats the procedure using faked IPv6 addresses, the NC 116 will grow. Eventually the NC exhausts all memory allocated for it. 117 The same risks exist on proxies and normal hosts that implement 118 Neighbor Discovery protocol. 120 For example, if the attackers send minimally sized Neighbor 121 Solicitation (NS) packets, which is 90 Bytes (14-Byte Ethernet header, 122 40B IPv6 header, 32B NS message, 4B trailer), to target router on a 123 100 Mbps Ethernet link, it can, in theory, build up and sustain 124 perhaps 145k bogus entries in the target's NC. Given that each entry 125 contains at least one Ipv6 address, one MAC address, a state and a 126 few flags, approximately 50 Bytes, this puts memory usage up in the 127 range of 8 MB in this example. This illustrates the scale of the 128 problems an attacker can cause on one interface. An attack on many 129 interfaces that is paired with distributed attackers will be manifold 130 worse. 132 DoS is the most considerable threat among with many others, analyzed 133 in Threats Analysis, Section 11.1, in [RFC4861]. SeND [RFC3971] 134 provides a feasible solution to these problems, based on 135 certification anchors on every network devices. It does require all 136 nodes on a local network to support SeND. The provision of 137 certificate anchors on every network devices is a tough deployment 138 challenges while there are secure issues for itself. 140 4. Security Requirements 142 Accordingly, it would be desirable to provide a defending mechanism 143 against DoS attacks targeting Neighbor Caches. This mechanism SHOULD 144 meet at least anti Dos, anti replay and anti spoofing (L3 spoofing) 145 requirements. 147 The focus for this effort, and the scope for this document explicitly 148 excludes, at this point in time, privacy (or encryption), 149 authentication, message integrity and non-repudiation. 151 5. Solution: Reverse Detection 153 In order to protect the NC against malicious attacks, a Reverse 154 Detection (RD) mechanism is introduced. This solution is based on the 155 messages and the procedures that already defined in the current ND 156 definition, so it is fully compatible with ND. This design principle 157 allows that most of network devices remain on their current ND 158 implementation, only the devices that need advanced NC protection 159 apply the proposed mechanism. The following figure illustrates the NC 160 protection mechanism on a router. (The protected network devices may 161 be a host or a proxy [RFC4389] that implements ND protocol, besides a 162 router.) 163 +----------+ IPv6 +--------+ 164 | Host A | -------------------| Router | 165 +----------+ +--------+ 166 | (1) RS/NS/NA | 167 + ===========================> + 168 | |(2) Create NS record 169 | (3) Reverse Detect NS | 170 + <=========================== + 171 | (4) RD-Reply NA | 172 + ===========================> + 173 | |(5) Create NC entry 174 | (6) RA/NA | 175 + <=========================== + 176 | | 177 Figure: the example of reverse detection for NC protection 179 In the current ND definition, when a router received a RS (Router 180 Solicitation) / NS / NA (Neighbor Advertisement) message (action (1) 181 in the figure), it creates a new NC entry locally (action (5) in the 182 figure) and reply a RA (Router Advertisement) / NA to the node that 183 initiates this RS/NS/NA message action (6) in the figure). 185 According to the analysis in the Section 3, the RS/NS/NA message is 186 not verified at all. Attacks may be carried in these messages. A RD 187 procedure is added after the action (1). By receive the first 188 RS/NS/NA message, the router puts this message into a high speed NS 189 record table (action (2) in the figure). It then sends a RD NS 190 message to the initiated host (action (3) in the figure). The 191 initiated host responds a NS-replied NA message (action (4) in the 192 figure) 194 When the router received the RD-replied NA message, it decides 195 whether the pair of the source IPv6 address and the source MAC 196 address matches any entry in the NS records table. If so, fetch the 197 matched NS record and continue the normal CPU-based slow path NS 198 procedure (action (5) and (6) in the figure). 200 6. Additional Discussion 202 6.1. Exceptional LLAs 204 Before the reverse detection, the router MAY check whether the 205 correspondent MAC address is in the local exceptional LLA table, 206 which stores a few high priority LLAs. If the NS message is from one 207 of such LLAs, the router SHOULD bypass the RD process. 209 This saves message interaction delay for these high priority or 210 trustable hosts. 212 6.2. Looped reverse detection 214 If the initiated host is also NC protected, the reverse detection 215 described, in the Section 4, may be looped between the two devices. 216 In order to avoid the reverse detection loop, the Reverse Detection 217 message should be distinguished from other NS message and should not 218 initiate another RD procedure. 220 6.3. Rate limit for incoming NS 222 As a complementary method to Reverse Detection, router NC can be 223 protected by rate limiting NS traffic up to an acceptable threshold. 224 Configurable access rate allows for NS traffic to be matched based on 225 router interface or same LLA. 227 6.4. CPU & memory protection 229 The router may actively drop the NS, even it is valid, according to 230 the CPU or memory usage status. It prevents the target device from 231 functioning properly due to CPU deadlock or memory exhaustion. 233 7. Security Considerations 235 The proposed NC protection mechanism may increase the new attack 236 mechanism based on the RD procedure: an attacker may send numerous 237 RD-NS messages to try to block a target. However, the reply procedure 238 of RD-NS consumes little CPU and memory. The attacker have to use 239 more resources to feasible such attack. The security risk of such 240 attack is very low. 242 The proposed NC protection mechanism cannot fully prevent the attacks 243 from MAC-spoofing attackers since their NS messages are no different 244 from the normal valid NS messages and they are able to respond to RD- 245 NS messages. However, the RD NC protection mechanism greatly reduces 246 the security risk from such attackers. It forces that the attackers 247 wait RD procedures completed before they can change their MAC 248 addresses for the next round attack. 250 8. IANA Considerations 252 This draft does not request any IANA action. 254 9. Change Log [RFC Editor please remove] 256 draft-jiang-v6ops-nc-protection-00, original version, 2009-09-19 258 draft-jiang-v6ops-nc-protection-01, update version, 2010-03-02 260 10. References 262 10.1. Normative References 264 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure 268 Neighbor Discovery (SEND) ", RFC 3971, March 2005. 270 [RFC4861] T. Narten, E. Nordmark, W. Simpson and H. Soliman, 271 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 272 September 2007. 274 10.2. Informative References 276 [RFC4389] D. Thaler, M. Talwar and C. Patel, "Neighbor Discovery 277 Proxies (ND Proxy)", RFC 4389, April 2006. 279 Author's Addresses 281 Sheng Jiang 282 Huawei Technologies Co., Ltd 283 KuiKe Building, No.9 Xinxi Rd., 284 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 285 P.R. China 286 Phone: 86-10-82836081 287 Email: shengjiang@huawei.com 289 Xu Chen 290 Huawei Technologies Co., Ltd 291 KuiKe Building, No.9 Xinxi Rd., 292 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 293 P.R. China 294 Phone: 86-10-82836074 295 Email: chenxu0128@huawei.com 297 Xuan Song 298 Huawei Technologies Co., Ltd 299 Huawei Building, No.3 Xinxi Rd., 300 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 301 P.R. China 302 Phone: 86-10-82832817 303 Email: songxuan@huawei.com