idnits 2.17.1 draft-kempf-ipng-netaccess-threats-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 333, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 335, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 341, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-mobileip-mipv6-scrty-reqts-01 -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2284 (ref. '3') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2472 (ref. '4') (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 2462 (ref. '5') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2402 (ref. '6') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-20 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPNG Working Group J. Kempf 3 Internet Draft E. Nordmark 4 draft-kempf-ipng-netaccess-threats-02.txt 5 Expires: December, 2002 7 Threat Analysis for IPv6 Public Multi-Access Links 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference 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 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The Mobile IP Working Group has been conducting a threat analysis 32 for the purpose of securing specific Mobile IPv6 mechanisms. In the 33 process of conducting the analysis, threats were identified that are 34 not specific to Mobile IP but that are amplified by the nature of 35 mobility. These threats are likely to be more or less of an issue 36 within any Public Multi-Access network, regardless of whether 37 mobility is involved. This document discusses threats associated 38 with Public Multi-Access links in IPv6. The document covers non- 39 Mobile IP specific threats uncovered by the Mobile IPv6 study, 40 threats raised in the IPv6 Neighbor Discovery and Stateless Address 41 Autoconfiguration RFCs that have yet to be adequately addressed, and 42 new threats that have not previously been identified. 44 Table of Contents 46 1.0 Introduction 48 The Mobile IP Working Group has been conducting a threat analysis 49 for securing specific Mobile IPv6 mechanisms [1]. While conducting 50 for IPv6 Public Multi-Access Links 52 the analysis, threats were identified that involve host utilization 53 of IPv6 protocols on a Public Multi-Access link, such as 802.11, 54 that were not specific to Mobile IP. Although the initial analysis 55 focused on wireless networks, the identified threats may occur in 56 any Public Multi-Access IPv6 network, such as Ethernet. 58 Despite the initial impetus given to this study by considering 59 wireless Ethernet, this document is not about link-layer specific 60 security issues, e.g. threats specific to 802.11, but is instead 61 about IP layer threats that are independent of the link layer 62 threats. These threats will remain even for multi-access link layers 63 that are completely secure. One way to think about this is to assume 64 that link layer access is somehow granted securely. This could be 65 done by, for example, granting physical access to an Ethernet plug 66 by some physical security mechanism or by being handed the 802.11 67 keys necessary to get access to the link layer. The threats that 68 remain after secure link access has been established are the scope 69 of this study. 71 In this document, threats involved in Neighbor Discovery and 72 Stateless Address Autoconfiguration [2] [5] on a Public Multi-Access 73 link are discussed. The analysis does not recommend any solutions, 74 although it does try to identify what specific part of the IPv6 75 Neighbor Discovery and Stateless Address Autoconfiguration 76 procedures (e.g. Router Solicitation/Advertisement, Neighbor 77 Solicitation/Advertisement, and Duplicate Address Detection) are 78 impacted by the threats. The analysis in this document explicitly 79 excludes point-to-point links, because the nature of a point-to- 80 point link physically excludes the possibility that a third party 81 could intrude on the activities of a legitimate host. The analysis 82 also excludes any discussion of authentication or authorization of 83 host access, because that work is under the charter of a separate 84 working group. 86 2.0 Previous Work 88 The RFCs that specify the IPv6 Neighbor Discovery and Address 89 Autoconfiguration protocols [2] [5] contain the required discussion 90 of security in a Security Considerations section. Some of the 91 threats identified in this document were raised in the original 92 RFCs. The recommended remedy is to include an IPsec AH header [6]. 93 However, this solution is not always possible in a Public Access 94 network. A host attempting to gain access to a Public Access network 95 may or may not have the required IPsec security association set up 96 with the network. In a roaming (but not necessarily mobile) 97 situation, where a user is currently accessing the network through a 98 service provider different from the home provider, it is not likely 99 that the host will have been preconfigured with the proper mutual 100 trust relationship for the foreign provider's network. 102 Any IPsec security association between the host and the last hop 103 routers or other hosts on the link would need to be completely 104 for IPv6 Public Multi-Access Links 106 manually preconfigured, since the Neighbor Discovery and Address 107 Autoconfiguration protocols deal to some extent with how a host 108 obtains initial access to a link. If a security association is 109 required for initial access and the host does not have that 110 association, there is no way that the host can dynamically configure 111 itself with that association, even if it has the necessary minimum 112 prerequisite keying material. This situation could induce 113 administration hardships when events such as re-keying occur. 115 In addition, Neighbor Discovery and Address Autoconfiguration use a 116 few fixed multicast addresses plus a range of 4 billion "solicited 117 node" multicast addresses. A naive application of pre-configured 118 SAs would require pre-configuring an unmanagable number of SAs on 119 each host and router just in case a given solicited node multicast 120 address is used. Preconfigured SAs are impractical for securing such 121 a large potential address range. 123 3.0 IPv6 Public Multi-Access Link Threat Analysis 125 There are two general types of threats: 127 1) Redirect attacks in which a malicious node redirects packets 128 away from the last hop router to another node on the link. 130 2) Denial of Service (DoS) attacks, in which a malicious node 131 prevents communication between the node under attack and all 132 other nodes, or a specific destination address. 134 A redirect attack can be used for DoS purposes by having the node to 135 which the packets were redirected drop the packets, either 136 completely or by selectively forwarding some of them and not 137 others. 139 The subsections below identify specific threats for IPv6 network 140 access. Redirect threats are included first, DOS attacks second. 142 3.1 Malicious Last Hop Router 144 This threat was identified in [1], but was classified as a general 145 IPv6 threat and not specific to Mobile IP. It is also identified in 146 [2]. This threat is a redirect attack. 148 An attacking node on the same subnet as a host attempting to 149 discover a legitimate last hop router could masquerade as an IPv6 150 last hop router by multicasting legitimate-looking IPv6 Router 151 Advertisements or unicasting Router Advertisements in response to 152 multicast Router Advertisement Solicitations from the entering host. 153 If the entering host selects the attacker as its default router, the 154 attacker has the opportunity to siphon off traffic from the host, or 155 mount a man in the middle traffic. The attacker could ensure that 156 the entering host selected itself as the default router by 157 multicasting periodic Router Advertisements for the real last hop 158 for IPv6 Public Multi-Access Links 160 router having a lifetime of zero. This essentially spoofs the 161 entering host into believing that the real access router is not 162 willing to take any traffic. Once accepted as a legitimate router, 163 the attacker could send Redirect messages to hosts, then disappear, 164 thus covering its tracks. 166 This threat involves Router Advertisement and Router Advertisement 167 Solicitation. 169 3.2 Good Router Goes Bad 171 In this attack, a router that previously was trusted is compromised. 172 The attacks available are the same as those in Section 3.1. This is 173 a redirect attack. 175 3.3 Neighbor Solicitation/Advertisement Spoofing 177 An attacking node can cause packets for legitimate nodes, both hosts 178 and routers, to be sent to some other link-layer address. This can 179 be done by either sending a Neighbor Solicitation with a different 180 source link-layer address option, or sending a Neighbor 181 Advertisement with a different target link-layer address option. The 182 address could additionally be the subnet router anycast address, 183 allowing the attacker to capture traffic to that address. The attack 184 results because the Neighbor Cache entry with the new link-layer 185 address overwrites the old. If the spoofed link-layer address is a 186 valid one, as long as the attacker responds to the unicast Neighbor 187 Solicitation messages sent as part of the Neighbor Unreachability 188 Detection, packets will continue to be redirected. This is a 189 redirect attack. 191 This mechanism can be used for a DoS attack by specifying an unused 192 link-layer address, however, the attack is of limited duration since 193 after 30-50 seconds (with default timer values) the Neighbor 194 Unreachability Detection mechanism will discard the bad link-layer 195 address and multicast anew to discover the link-layer address. As a 196 consequence, the attacker will need to keep responding with 197 fabricated link layer addresses if it wants to maintain the attack 198 beyond the timeout. 200 This threat involves Neighbor Solicitation and Neighbor 201 Advertisement messages. 203 3.4 Spoofed Redirect Message 205 The Redirect message can be used to send packets for a given 206 destination to any link-layer address on the link. The attacker uses 207 the link-local address of the current first-hop router in order to 208 send a Redirect message to a legitimate host. Since the host 209 identifies the message by the link-local address as coming from its 210 first hop router, it accepts the Redirect. As long as the attacker 211 responds to Neighbor Unreachability Detection probes to the link- 212 layer address, the Redirect will remain in effect. This is a 213 for IPv6 Public Multi-Access Links 215 redirect attack. 217 This threat involves Redirect messages. 219 3.5 Bogus On-Link Prefix 221 An attacking node can send a Router Advertisement message specifying 222 that some prefix of arbitrary length is on-link. If a sending host 223 thinks the prefix is on-link, it will never send a packet for that 224 prefix to the router. Instead, the host will try to perform address 225 resolution by sending Neighbor Solicitations, but the Neighbor 226 Solicitations will not result in a response, denying service to the 227 attacked host. This is a DoS attack. 229 The attacker can use an arbitrary lifetime on the bogus prefix 230 advertisement. If the lifetime is infinity, the sending host will be 231 denied service until it loses the state in its prefix list e.g. by 232 rebooting, or the same prefix is advertised with a zero lifetime. 233 The attack could also be perpetrated selectively for packets 234 destined to a particular prefix by using 128 bit prefixes, i.e. full 235 addresses. 237 This threat involves Router Advertisement messages. 239 3.6 Bogus Address Configuration Prefix 241 An attacking node can send a Router Advertisement message specifying 242 an invalid subnet prefix to be used by a host for address 243 autoconfiguration. A host executing the address autoconfiguration 244 algorithm uses the advertised prefix to construct an address [5], 245 even though that address is not valid for the subnet. As a result, 246 return packets never reach the host because the host's source 247 address is invalid. This is a DoS attack. 249 This attack has the potential to propagate beyond the immediate 250 attacked host if the attacked host performs a dynamic update to the 251 DNS based on the bogus constructed address. DNS update causes the 252 bogus address to be added to the host's AAAA record in the DNS. 253 Should this occur, applications performing name resolution through 254 the DNS obtain the bogus address and an attempt to contact the host 255 fails. However, well-written applications will fall back and try the 256 other IP address in the AAAA RRset, which may be correct. 258 This threat involves Router Advertisement messages. 260 3.7 Duplicate Address Detection DoS Attack 262 In networks where entering hosts obtain their addresses using 263 stateless address autoconfiguration [5], an attacking node could 264 launch a DOS attack by responding to every duplicate address 265 detection attempt by an entering host. If the attacker claims the 266 address, then the host will never be able to obtain an address. This 267 threat was identified in RFC 2462 [5]. 269 for IPv6 Public Multi-Access Links 271 This attack involves Neighbor Solicitation/Advertisement. 273 3.8 Neighbor Discovery DoS Attack 275 In this attack, the attacking node begins fabricating addresses with 276 the subnet prefix and continuously sending packets to them. The last 277 hop router is obligated to resolve these addresses by sending 278 neighbor solicitation packets. A legitimate host attempting to enter 279 the network may not be able to obtain Neighbor Discovery service 280 from the last hop router as it will be already busy with sending 281 other solicitations. This DoS attack is different from the others in 282 that the attacker may be off link. The resource being attacked in 283 this case is the conceptual neighbor cache, which will be filled 284 with attempts to resolve IPv6 addresses having a valid prefix but 285 invalid suffix. 287 This attack involves Neighbor Advertisement. 289 3.9 Parameter Spoofing 291 IPv6 Router Advertisements contain a few parameters used by hosts 292 when they send packets and to tell hosts whether or not they should 293 perform stateful address configuration [2]. An attacking node could 294 send out a valid-seeming Router Advertisement that duplicates the 295 Router Advertisement from the legitimate default router, except the 296 included parameters are designed to disrupt legitimate traffic. This 297 is a DoS attack. 299 Specific attacks include: 301 1) The attacker includes a Current Hop Limit of one or another 302 small number which the attacker knows will cause legitimate 303 packets to be dropped before they reach their destination. 305 2) The attacker implements a bogus DHCPv6 server or relay and the 306 'M' and/or 'O' flag is set, indicating that stateful address 307 configuration and/or stateful configuration of other 308 parameters should be done. The attacker is then in a position 309 to answer the stateful configuration queries of a legitmate 310 host with its own bogus replies. 312 This attack involves Router Advertisements. 314 4.0 Security Considerations 316 This document discusses security threats to network access in IPv6. 317 As such, it is concerned entirely with security. 319 for IPv6 Public Multi-Access Links 321 5.0 Acknowledgements 323 Thanks to Alper Yegin, DoCoMo Communications Laboratories USA, for 324 identifying the Neighbor Discovery DOS attack. 326 6.0 References 328 [1] Mankin, et. al., "Threat Models introduced by Mobile IPv6 and 329 Requirements for Security in Mobile IPv6," draft-ietf-mobileip- 330 mipv6-scrty-reqts-01.txt, a work in progress. 331 [2] Narten, T., Nordmark, E., and Simson, W., "Neighbor Discovery 332 for IP Version 6 (IPv6)," RFC 2461, December, 1998. 333 [3] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication 334 Protocol (EAP)," RFC 2284, March, 1998. 335 [4] Haskin, D. and Allen, E., "IP Version 6 over PPP," RFC 2472, 336 December, 1998. 337 [5] Thomas, S., and Narten, T., "IPv6 Stateless Address 338 Autoconfiguration," RFC 2462, December, 1998. 339 [6] Kent, S., and Atkinson, R., "IP Authentication Header," RFC 340 2402, November 1998. 341 [7] Droms, R., editor, "Dynamic Host Configuration Protocol for 342 IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-20.txt, a work in 343 progress. 345 7.0 Author's Addresses 347 James Kempf 348 DoCoMo USA Labs 349 181 Metro Drive, Suite 300 Phone: +1 408 451 4711 350 San Jose, CA, 95110 Email: kempf@docomolabs-usa.com 351 USA 353 Erik Nordmark 354 Sun Microsystems Laboratories Phone: +33 4 76 18 88 03 355 29, Chemin du Vieux Chene Fax: +33 4 76 18 88 88 356 38240 Meylan Email: erik.nordmark@sun.com 357 France