idnits 2.17.00 (12 Aug 2021) /tmp/idnits9131/draft-kempf-ipng-netaccess-threats-01.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 328, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 330, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 336, 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: draft-ietf-dhc-dhcpv6 has been published as RFC 3315 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-01.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. 155 The attacker could ensure that the entering host selected itself as 156 the default router by multicasting periodic Router Advertisements 157 for the real last hop router having a lifetime of zero. This 158 for IPv6 Public Multi-Access Links 160 essentially spoofs the entering host into believing that the real 161 access router is not willing to take any traffic. Once accepted as a 162 legitimate router, the attacker could send Redirect messages to 163 hosts, then disappear, thus covering its tracks. 165 This threat involves Router Advertisement and Router Advertisement 166 Solicitation. 168 3.2 Good Router Goes Bad 170 In this attack, a router that previously was trusted is compromised. 171 The attacks available are the same as those in Section 3.1. This is 172 a redirect attack. 174 3.3 Neighbor Solicitation/Advertisement Spoofing 176 An attacking node can cause packets for legitimate nodes, both hosts 177 and routers, to be sent to some other link-layer address. This can 178 be done by either sending a Neighbor Solicitation with a different 179 source link-layer address option, or sending a Neighbor 180 Advertisement with a different target link-layer address option. 181 If the spoofed link-layer address is a valid one, as long as the 182 attacker responds to the unicast Neighbor Solicitation messages sent 183 as part of the Neighbor Unreachability Detection, packets will 184 continue to be redirected. This is a redirect attack. 186 This mechanism can be used for a DoS attack by specifying an unused 187 link-layer address, however, the attack is of limited duration since 188 after 30-50 seconds (with default timer values) the Neighbor 189 Unreachability Detection mechanism will discard the bad link-layer 190 address and multicast anew to discover the link-layer address. As a 191 consequence, the attacker will need to keep responding with 192 fabricated link layer addresses if it wants to maintain the attack 193 beyond the timeout. 195 This threat involves Neighbor Solicitation and Neighbor 196 Advertisement messages. 198 3.4 Spoofed Redirect Message 200 The Redirect message can be used to send packets for a given 201 destination to any link-layer address on the link. The attacker uses 202 the link-local address of the current first-hop router in order to 203 send a Redirect message to a legitimate host. Since the host 204 identifies the message by the link-local address as coming from its 205 first hop router, it accepts the Redirect. As long as the attacker 206 responds to Neighbor Unreachability Detection probes to the link- 207 layer address, the Redirect will remain in effect. This is a 208 redirect attack. 210 This threat involves Redirect messages. 212 for IPv6 Public Multi-Access Links 214 3.5 Bogus On-Link Prefix 216 An attacking node can send a Router Advertisement message specifying 217 that some prefix of arbitrary length is on-link. If a sending host 218 thinks the prefix is on-link, it will never send a packet for that 219 prefix to the router. Instead, the host will try to perform address 220 resolution by sending Neighbor Solicitations, but the Neighbor 221 Solicitations will not result in a response, denying service to the 222 attacked host. This is a DoS attack. 224 The attacker can use an arbitrary lifetime on the bogus prefix 225 advertisement. If the lifetime is infinity, the sending host will be 226 denied service until it loses the state in its prefix list e.g. by 227 rebooting, or the same prefix is advertised with a zero lifetime. 228 The attack could also be perpetrated selectively for packets 229 destined to a particular prefix by using 128 bit prefixes, i.e. full 230 addresses. 232 This threat involves Router Advertisement messages. 234 3.6 Bogus Address Configuration Prefix 236 An attacking node can send a Router Advertisement message specifying 237 an invalid subnet prefix to be used by a host for address 238 autoconfiguration. A host executing the address autoconfiguration 239 algorithm uses the advertised prefix to construct an address [5], 240 even though that address is not valid for the subnet. As a result, 241 return packets never reach the host because the host's source 242 address is invalid. This is a DoS attack. 244 This attack has the potential to propagate beyond the immediate 245 attacked host if the attacked host performs a dynamic update to the 246 DNS based on the bogus constructed address. DNS update causes the 247 bogus address to be added to the host's AAAA record in the DNS. 248 Should this occur, applications performing name resolution through 249 the DNS obtain the bogus address and an attempt to contact the host 250 fails. However, well-written applications will fall back and try the 251 other IP address in the AAAA RRset, which may be correct. 253 This threat involves Router Advertisement messages. 255 3.7 Duplicate Address Detection DoS Attack 257 In networks where entering hosts obtain their addresses using 258 stateless address autoconfiguration [5], an attacking node could 259 launch a DOS attack by responding to every duplicate address 260 detection attempt by an entering host. If the attacker claims the 261 address, then the host will never be able to obtain an address. This 262 threat was identified in RFC 2462 [5]. 264 This attack involves Neighbor Solicitation/Advertisement. 266 for IPv6 Public Multi-Access Links 268 3.8 Neighbor Discovery DoS Attack 270 In this attack, the attacking node begins fabricating addresses with 271 the subnet prefix and continuously sending packets to them. The last 272 hop router is obligated to resolve these addresses by sending 273 neighbor solicitation packets. A legitimate host attempting to enter 274 the network may not be able to obtain Neighbor Discovery service 275 from the last hop router as it will be already busy with sending 276 other solicitations. This DoS attack is different from the others in 277 that the attacker may be off link. The resource being attacked in 278 this case is the conceptual neighbor cache, which will be filled 279 with attempts to resolve IPv6 addresses having a valid prefix but 280 invalid suffix. 282 This attack involves Neighbor Advertisement. 284 3.9 Parameter Spoofing 286 IPv6 Router Advertisements contain a few parameters used by hosts 287 when they send packets and to tell hosts whether or not they should 288 perform stateful address configuration [2]. An attacking node could 289 send out a valid-seeming Router Advertisement that duplicates the 290 Router Advertisement from the legitimate default router, except the 291 included parameters are designed to disrupt legitimate traffic. This 292 is a DoS attack. 294 Specific attacks include: 296 1) The attacker includes a Current Hop Limit of one or another 297 small number which the attacker knows will cause legitimate 298 packets to be dropped before they reach their destination. 300 2) The attacker implements a bogus DHCPv6 server or relay and the 301 'M' and/or 'O' flag is set, indicating that stateful address 302 configuration and/or stateful configuration of other 303 parameters should be done. The attacker is then in a position 304 to answer the stateful configuration queries of a legitmate 305 host with its own bogus replies. 307 This attack involves Router Advertisements. 309 4.0 Security Considerations 311 This document discusses security threats to network access in IPv6. 312 As such, it is concerned entirely with security. 314 5.0 Acknowledgements 316 Thanks to Alper Yegin, DoCoMo Communications Laboratories USA, for 317 identifying the Neighbor Discovery DOS attack. 319 for IPv6 Public Multi-Access Links 321 6.0 References 323 [1] Mankin, et. al., "Threat Models introduced by Mobile IPv6 and 324 Requirements for Security in Mobile IPv6," draft-ietf-mobileip- 325 mipv6-scrty-reqts-01.txt, a work in progress. 326 [2] Narten, T., Nordmark, E., and Simson, W., "Neighbor Discovery 327 for IP Version 6 (IPv6)," RFC 2461, December, 1998. 328 [3] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication 329 Protocol (EAP)," RFC 2284, March, 1998. 330 [4] Haskin, D. and Allen, E., "IP Version 6 over PPP," RFC 2472, 331 December, 1998. 332 [5] Thomas, S., and Narten, T., "IPv6 Stateless Address 333 Autoconfiguration," RFC 2462, December, 1998. 334 [6] Kent, S., and Atkinson, R., "IP Authentication Header," RFC 335 2402, November 1998. 336 [7] Droms, R., editor, "Dynamic Host Configuration Protocol for 337 IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-20.txt, a work in 338 progress. 340 7.0 Author's Addresses 342 James Kempf 343 DoCoMo USA Labs 344 181 Metro Drive, Suite 300 Phone: +1 408 451 4711 345 San Jose, CA, 95110 Email: kempf@docomolabs-usa.com 346 USA 348 Erik Nordmark 349 Sun Microsystems Laboratories Phone: +33 4 76 18 88 03 350 29, Chemin du Vieux Chene Fax: +33 4 76 18 88 88 351 38240 Meylan Email: erik.nordmark@sun.com 352 France