idnits 2.17.1 draft-ietf-v6ops-tunnel-loops-07.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 : ---------------------------------------------------------------------------- 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 date (May 7, 2011) is 4731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-02) exists of draft-ietf-v6ops-6to4-advisory-01 == Outdated reference: A later version (-12) exists of draft-templin-aero-00 == Outdated reference: A later version (-19) exists of draft-templin-v6ops-isops-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Nakibly 3 Internet-Draft National EW Research & 4 Intended status: Informational Simulation Center 5 Expires: November 8, 2011 F. Templin 6 Boeing Research & Technology 7 May 7, 2011 9 Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and 10 Proposed Mitigations 11 draft-ietf-v6ops-tunnel-loops-07.txt 13 Abstract 15 This document is concerned with security vulnerabilities in IPv6-in- 16 IPv4 automatic tunnels. These vulnerabilities allow an attacker to 17 take advantage of inconsistencies between the IPv4 routing state and 18 the IPv6 routing state. The attack forms a routing loop which can be 19 abused as a vehicle for traffic amplification to facilitate DoS 20 attacks. The first aim of this document is to inform on this attack 21 and its root causes. The second aim is to present some possible 22 mitigation measures. It should be noted that at the time of this 23 writing there are no known reports of malicious attacks exploiting 24 these vulnerabilities. Nonetheless, these vulnerabilities can be 25 activated by accidental misconfiguarion. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 8, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. A Detailed Description of the Attack . . . . . . . . . . . . . 4 63 3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6 64 3.1. Verification of end point existence . . . . . . . . . . . 7 65 3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 7 66 3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 8 67 3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 8 68 3.2.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 8 69 3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 9 70 3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9 71 3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 10 72 3.3. Destination and Source Address Checks . . . . . . . . . . 15 73 3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 16 74 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 IPv6-in-IPv4 tunnels are an essential part of many migration plans 86 for IPv6. They allow two IPv6 nodes to communicate over an IPv4-only 87 network. Automatic tunnels that assign IPv6 prefixes with stateless 88 address mapping properties (hereafter called "automatic tunnels") are 89 a category of tunnels in which a tunneled packet's egress IPv4 90 address is embedded within the destination IPv6 address of the 91 packet. An automatic tunnel's router is a router that respectively 92 encapsulates and decapsulates the IPv6 packets into and out of the 93 tunnel. 95 Ref. [USENIX09] pointed out the existence of a vulnerability in the 96 design of IPv6 automatic tunnels. Tunnel routers operate on the 97 implicit assumption that the destination address of an incoming IPv6 98 packet is always an address of a valid node that can be reached via 99 the tunnel. The assumption of path validity can introduce routing 100 loops as the inconsistency between the IPv4 routing state and the 101 IPv6 routing state allows a routing loop to be formed. Although 102 those loops will not trap normal data, they will catch traffic 103 targeted at addresses that have become unavailable, and misconfigured 104 traffic can enter the loop. 106 The looping vulnerability can be triggered accidentally or exploited 107 maliciously by an attacker crafting a packet which is routed over a 108 tunnel to a node that is not associated with the packet's 109 destination. This node may forward the packet out of the tunnel to 110 the native IPv6 network. There the packet is routed back to the 111 ingress point that forwards it back into the tunnel. Consequently, 112 the packet loops in and out of the tunnel. The loop terminates only 113 when the Hop Limit field in the IPv6 header of the packet is 114 decremented to zero. This vulnerability can be abused as a vehicle 115 for traffic amplification to facilitate DoS attacks [RFC4732]. 117 Without compensating security measures in place, all IPv6 automatic 118 tunnels that are based on protocol-41 encapsulation [RFC4213] are 119 vulnerable to such an attack including ISATAP [RFC5214], 6to4 120 [RFC3056] and 6rd [RFC5969]. It should be noted that this document 121 does not consider non-protocol-41 encapsulation attacks. In 122 particular, we do not address the Teredo [RFC4380] attacks described 123 in [USENIX09]. These attacks are considered in 124 [I-D.gont-6man-teredo-loops]. 126 The aim of this document is to shed light on the routing loop attack 127 and describe possible mitigation measures that should be considered 128 by operators of current IPv6 automatic tunnels and by designers of 129 future ones. We note that tunnels may be deployed in various 130 operational environments, e.g. service provider network, enterprise 131 network, etc. Specific issues related to the attack which are 132 derived from the operational environment are not considered in this 133 document. 135 Routing loops pose a risk to the stability of a network. 136 Furthermore, they provide an opening for denial of service attacks 137 that exploit the existence of the loop to increase the traffic load 138 in the network. Section 3 of this document discusses a number of 139 mitigation measures. The most desirable mitigation, however, is to 140 operate the network in such a way that routing loops can not take 141 place (see Section 3.2). 143 2. A Detailed Description of the Attack 145 In this section we shall denote an IPv6 address of a node by an IPv6 146 prefix assigned to the tunnel and an IPv4 address of the tunnel end 147 point, i.e., Addr(Prefix, IPv4). Note that the IPv4 address may or 148 may not be part of the prefix (depending on the specification of the 149 tunnel's protocol). The IPv6 address may be dependent on additional 150 bits in the interface ID, however for our discussion their exact 151 value is not important. 153 The two victims of this attack are routers - R1 and R2 - that service 154 two different tunnel prefixes - Prf1 and Prf2. Both routers have the 155 capability to forward IPv6 packets in and out of their respective 156 tunnels. The two tunnels need not be based on the same tunnel 157 protocol. The only condition is that the two tunnel protocols be 158 based on protocol-41 encapsulation. The IPv4 address of R1 is IP1, 159 while the prefix of its tunnel is Prf1. IP2 and Prf2 are the 160 respective values for R2. We assume that IP1 and IP2 belong to the 161 same address realm, i.e., they are either both public, or both 162 private and belong to the same internal network. The following 163 network diagram depicts the locations of the two routers. The 164 numbers indicate the packets of the attack and the path they traverse 165 as described below. 167 [ Packet 1 ] 168 v6src = Addr(Prf1, IP2) [ Packet 2 ] 169 v6dst = Addr(Prf2, IP1) v6src = Addr(Prf1, IP2) 170 v4src = IP2; v4dst = IP1 +----------+ v6dst = Addr(Prf2, IP1) 171 //===========>| Router |-----------------\ 172 || | R1 | | 173 || +----------+ v 174 .-. .-. 175 ,-( _)-. ,-( _)-. 176 .-(_ IPv4 )-. .-(_ IPv6 )-. 177 (__ Network ) (__ Network ) 178 `-(______)-' `-(______)-' 179 ^^ | 180 || +----------+ | 181 \\============| Router |<----------------/ 182 [ Packet 1 ] | R2 | [ Packets 0 and 2 ] 183 v6src = Addr(Prf1, IP2) +----------+ v6src = Addr(Prf1, IP2) 184 v6dst = Addr(Prf2, IP1) v6dst = Addr(Prf2, IP1) 185 v4src = IP2; v4dst = IP1 187 Figure 1: The network setting of the attack 189 The attack is depicted in Figure 2. It is initiated by an 190 accidentally or maliciously produced IPv6 packet (packet 0 in 191 Figure 2) destined to a fictitious end point that appears to be 192 reached via Prf2 and has IP1 as its IPv4 address, i.e., Addr(Prf2, 193 IP1). The source address of the packet is an address with Prf1 as 194 the prefix and IP2 as the embedded IPv4 address, i.e., Addr(Prf1, 195 IP2). As the prefix of the destination address is Prf2, the packet 196 will be routed over the IPv6 network to R2. 198 R2 receives the packet through its IPv6 interface and forwards it 199 into the tunnel with an IPv4 header having a destination address 200 derived from the IPv6 destination, i.e., IP1. The source address is 201 the address of R2, i.e., IP2. The packet (packet 1 in Figure 2) is 202 routed over the IPv4 network to R1, which receives the packet on its 203 IPv4 interface. It processes the packet as a packet that originates 204 from one of the end nodes of Prf1. 206 Since the IPv4 source address corresponds to the IPv6 source address, 207 R1 will decapsulate the packet. Since the packet's IPv6 destination 208 is outside of Prf1, R1 will forward the packet onto a native IPv6 209 interface. The forwarded packet (packet 2 in Figure 2) is identical 210 to the original attack packet. Hence, it is routed back to R2, in 211 which the loop starts again. Note that the packet may not 212 necessarily be transported from R1 over native IPv6 network. R1 may 213 be connected to the IPv6 network through another tunnel. 215 R1 R2 216 | | 0 217 | 1 |<------ 218 |<===============| 219 | 2 | 220 |--------------->| 221 | . | 222 | . | 224 1 - IPv4: IP2 --> IP1 225 IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) 226 0,2- IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) 228 Legend: ====> - tunneled IPv6, ---> - native IPv6 230 Figure 2: Routing loop attack between two tunnels' routers 232 The crux of the attack is as follows. The attacker exploits the fact 233 that R2 does not know that R1 does not configure addresses from Prf2 234 and that R1 does not know that R2 does not configure addresses from 235 Prf1. The IPv4 network acts as a shared link layer for the two 236 tunnels. Hence, the packet is repeatedly forwarded by both routers. 237 It is noted that the attack will fail when the IPv4 network can not 238 transport packets between the tunnels. For example, when the two 239 routers belong to different IPv4 address realms or when ingress/ 240 egress filtering is exercised between the routers. 242 The loop will stop when the Hop Limit field of the packet reaches 243 zero. After a single loop the Hop Limit field is decreased by the 244 number of IPv6 routers on path from R1 to R2. Therefore, the number 245 of loops is inversely proportional to the number of IPv6 hops between 246 R1 and R2. 248 The tunnels used by R1 and R2 may be any combination of automatic 249 tunnel types, e.g., ISATAP, 6to4 and 6rd. This has the exception 250 that both tunnels can not be of type 6to4, since two 6to4 routers 251 share the same IPv6 prefix, i.e., there is only one 6to4 prefix 252 (2002::/16) in the Internet. For example, if the attack were to be 253 launched on an ISATAP router (R1) and 6to4 relay (R2), then the 254 destination and source addresses of the attack packet would be 2002: 255 IP1:* and Prf1::0200:5EFE:IP2, respectively. 257 3. Proposed Mitigation Measures 259 This section presents some possible mitigation measures for the 260 attack described above. For each measure we shall discuss its 261 advantages and disadvantages. 263 The proposed measures fall under the following three categories: 265 o Verification of end point existence 267 o Operational measures 269 o Destination and source addresses checks 271 3.1. Verification of end point existence 273 The routing loop attack relies on the fact that a router does not 274 know whether there is an end point that can reached via its tunnel 275 that has the source or destination address of the packet. This 276 category includes mitigation measures which aim to verify that there 277 is a node which participate in the tunnel and its address corresponds 278 to the packet's destination or source addresses, as appropriate. 280 3.1.1. Neighbor Cache Check 282 One way that the router can verify that an end host exists and can be 283 reached via the tunnel is by checking whether a valid entry exists 284 for it in the neighbor cache of the corresponding tunnel interface. 285 The neighbor cache entry can be populated through, e.g., an initial 286 reachability check, receipt of neighbor discovery messages, 287 administrative configuration, etc. 289 When the router has a packet to send to a potential tunnel host for 290 which there is no neighbor cache entry, it can perform an initial 291 reachability check on the packet's destination address, e.g., as 292 specified in the second paragraph of Section 8.4 of [RFC5214]. (The 293 router can similarly perform a "reverse reachability" check on the 294 packet's source address when it receives a packet from a potential 295 tunnel host for which there is no neighbor cache entry.) This 296 reachability check parallels the address resolution specifications in 297 Section 7.2 of [RFC4861], i.e., the router maintains a small queue of 298 packets waiting for reachability confirmation to complete. If 299 confirmation succeeds, the router discovers that a legitimate tunnel 300 host responds to the address. Otherwise, the router discards 301 subsequent packets and returns ICMP destination unreachable 302 indications as specified in Section 7.2.2 of [RFC4861]. 304 Note that this approach assumes that the neighbor cache will remain 305 coherent and not subject to malicious attack, which must be confirmed 306 based on specific deployment scenarios. One possible way for an 307 attacker to subvert the neighbor cache is to send false neighbor 308 discovery messages with a spoofed source address. 310 3.1.2. Known IPv4 Address Check 312 Another approach that enables a router to verify that an end host 313 exists and can be reached via the tunnel is simply by pre-configuring 314 the router with the set of IPv4 addresses that are authorized to use 315 the tunnel. Upon this configuration the router can perform the 316 following simple checks: 318 o When the router forwards an IPv6 packet into the tunnel interface 319 with a destination address that matches an on-link prefix and that 320 embeds the IPv4 address IP1, it discards the packet if IP1 does 321 not belong to the configured list of IPv4 addresses. 323 o When the router receives an IPv6 packet on the tunnel's interface 324 with a source address that matches a on-link prefix and that 325 embeds the IPv4 address IP2, it discards the packet if IP2 does 326 not belong to the configured list of IPv4 addresses. 328 3.2. Operational Measures 330 The following measures can be taken by the network operator. Their 331 aim is to configure the network in such a way that the attacks can 332 not take place. 334 3.2.1. Avoiding a Shared IPv4 Link 336 As noted above, the attack relies on having an IPv4 network as a 337 shared link-layer between more than one tunnel. From this the 338 following two mitigation measures arise: 340 3.2.1.1. Filtering IPv4 Protocol-41 Packets 342 In this measure a tunnel router may drop all IPv4 protocol-41 packets 343 received or sent over interfaces that are attached to an untrusted 344 IPv4 network. This will cut-off any IPv4 network as a shared link. 345 This measure has the advantage of simplicity. However, such a 346 measure may not always be suitable for scenarios where IPv4 347 connectivity is essential on all interfaces. Most notably, filtering 348 of IPv4 protocol-41 packets that belong to a 6to4 tunnel can have 349 real adverse affects on unsuspecting users 350 [I-D.ietf-v6ops-6to4-advisory]. 352 3.2.1.2. Operational Avoidance of Multiple Tunnels 354 This measure mitigates the attack by simply allowing for a single 355 IPv6 tunnel to operate in a bounded IPv4 network. For example, the 356 attack can not take place in broadband home networks. In such cases 357 there is a small home network having a single residential gateway 358 which serves as a tunnel router. A tunnel router is vulnerable to 359 the attack only if it has at least two interfaces with a path to the 360 Internet: a tunnel interface and a native IPv6 interface (as depicted 361 in Figure 1). However, a residential gateway usually has only a 362 single interface to the Internet, therefore the attack can not take 363 place. Moreover, if there are only one or a few tunnel routers in 364 the IPv4 network and all participate in the same tunnel then there is 365 no opportunity for perpetuating the loop. 367 This approach has the advantage that it avoids the attack profile 368 altogether without need for explicit mitigations. However, it 369 requires careful configuration management which may not be tenable in 370 large and/or unbounded IPv4 networks. 372 3.2.2. A Single Border Router 374 It is reasonable to assume that a tunnel router shall accept or 375 forward tunneled packets only over its tunnel interface. It is also 376 reasonable to assume that a tunnel router shall accept or forward 377 IPv6 packets only over its IPv6 interface. If these two interfaces 378 are physically different then the network operator can mitigate the 379 attack by ensuring that the following condition holds: there is no 380 path between these two interfaces that does not go through the tunnel 381 router. 383 The above condition ensures that an encapsulated packet which is 384 transmitted over the tunnel interface will not get to another tunnel 385 router and from there to the IPv6 interface of the first router. The 386 condition also ensures the reverse direction, i.e., an IPv6 packet 387 which is transmitted over the IPv6 interface will not get to another 388 tunnel router and from there to the tunnel interface of the first 389 router. This condition is essentially translated to a scenario in 390 which the tunnel router is the only border router between the IPv6 391 network and the IPv4 network to which it is attached (as in broadband 392 home network scenario mentioned above). 394 3.2.3. A Comprehensive List of Tunnel Routers 396 If a tunnel router can be configured with a comprehensive list of 397 IPv4 addresses of all other tunnel routers in the network, then the 398 router can use the list as a filter to discard any tunneled packets 399 coming from or destined to other routers. For example, a tunnel 400 router can use the network's ISATAP Potential Router List (PRL) 401 [RFC5214] as a filter as long as there is operational assurance that 402 all ISATAP routers are listed and that no other types of tunnel 403 routers are present in the network. 405 This measure parallels the one proposed for 6rd in [RFC5969] where 406 the 6rd BR filters all known relay addresses of other tunnels inside 407 the ISP's network. 409 This measure is especially useful for intra-site tunneling 410 mechanisms, such as ISATAP and 6rd, since filtering can be exercised 411 on well-defined site borders. A specific ISATAP operational scenario 412 for which this mitigation applies is described in Section 3 of 413 [I-D.templin-v6ops-isops]. 415 3.2.4. Avoidance of On-link Prefixes 417 The looping attack exploits the fact that a router is permitted to 418 assign non-link-local IPv6 prefixes on its tunnel interfaces, which 419 could cause it to send tunneled packets to other routers that do not 420 configure an address from the prefix. Therefore, if the router does 421 not assign non-link-local IPv6 prefixes on its tunnel interfaces 422 there is no opportunity for it to initiate the loop. If the router 423 further ensures that the routing state is consistent for the packets 424 it receives on its tunnel interfaces there is no opportunity for it 425 to propagate a loop initiated by a different router. 427 This mitigation is available only to ISATAP routers, since the ISATAP 428 stateless address mapping operates only on the Interface Identifier 429 portion of the IPv6 address, and not on the IPv6 prefix. The 430 mitigation is also only applicable on ISATAP links on which IPv4 431 source address spoofing is disabled. The following sections discuss 432 the operational configurations necessary to implement the mitigation. 434 3.2.4.1. ISATAP Router Interface Types 436 ISATAP provides a Potential Router List (PRL) to further ensure a 437 loop-free topology. Routers that are members of the PRL for the site 438 configure their site-facing ISATAP interfaces as advertising router 439 interfaces (see: [RFC4861], Section 6.2.2), and therefore may send RA 440 messages that include non-zero Router Lifetimes. Routers that are 441 not members of the PRL for the site configure their site-facing 442 ISATAP interfaces as non-advertising router interfaces. 444 3.2.4.2. ISATAP Source Address Verification 446 ISATAP nodes employ the source address verification checks specified 447 in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of 448 packets received on an ISATAP interface. To enable the on-link 449 prefix avoidance procedures outlined in this section, ISATAP nodes 450 must employ an additional source address verification check; namely, 451 the node also considers the outer IPv4 source address correct for the 452 inner IPv6 source address if: 454 o a forwarding table entry exists that lists the packet's IPv4 455 source address as the link-layer address corresponding to the 456 inner IPv6 source address via the ISATAP interface. 458 3.2.4.3. ISATAP Host Behavior 460 ISATAP hosts send RS messages to obtain RA messages from an 461 advertising ISATAP router. Whether or not non-link-local IPv6 462 prefixes are advertised, the host can acquire IPv6 addresses, e.g., 463 through the use of DHCPv6 stateful address autoconfiguration 464 [RFC3315]. 466 To acquire addresses, the host performs standard DHCPv6 exchanges 467 while mapping the IPv6 "All_DHCP_Relay_Agents_and_Servers" link- 468 scoped multicast address to the IPv4 address of the advertising 469 router (hence, the advertising router must configure either a DHCPv6 470 relay or server function). The host should also use DHCPv6 471 Authentication in environments where authentication of the DHCPv6 472 exchanges is required. 474 After the host receives IPv6 addresses, it assigns them to its ISATAP 475 interface and forwards any of its outbound IPv6 packets via the 476 advertising router as a default router. The advertising router in 477 turn maintains IPv6 forwarding table entries that list the IPv4 478 address of the host as the link-layer address of the delegated IPv6 479 addresses. 481 3.2.4.4. ISATAP Router Behavior 483 In many use case scenarios (e.g., enterprise networks, MANETs, etc.), 484 advertising and non-advertising ISATAP routers can engage in a 485 proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.) 486 over their ISATAP interfaces so that IPv6 routing/forwarding tables 487 can be populated and standard IPv6 forwarding between ISATAP routers 488 can be used. In other scenarios (e.g., large enterprise networks, 489 etc.), this might be impractical due to scaling issues. When a 490 proactive dynamic routing protocol cannot be used, non-advertising 491 ISATAP routers send RS messages to obtain RA messages from an 492 advertising ISATAP router, i.e., they act as "hosts" on their non- 493 advertising ISATAP interfaces. 495 Non-advertising ISATAP routers can also acquire IPv6 prefixes, e.g., 496 through the use of DHCPv6 Prefix Delegation [RFC3633] via an 497 advertising router in the same fashion as described above for host- 498 based DHCPv6 stateful address autoconfiguration. The advertising 499 router in turn maintains IPv6 forwarding table entries that list the 500 IPv4 address of the non-advertising router as the link-layer address 501 of the next hop toward the delegated IPv6 prefixes. 503 After the non-advertising router acquires IPv6 prefixes, it can sub- 504 delegate them to routers and links within its attached IPv6 edge 505 networks, then can forward any outbound IPv6 packets coming from its 506 edge networks via other ISATAP nodes on the link. 508 3.2.4.5. Reference Operational Scenario 510 Figure 3 depicts a reference ISATAP network topology for operational 511 avoidance of on-link non-link-local IPv6 prefixes. The scenario 512 shows two advertising ISATAP routers ('A', 'B'), two non-advertising 513 ISATAP routers ('C', 'E'), an ISATAP host ('G'), and three ordinary 514 IPv6 hosts ('D', 'F', 'H') in a typical deployment configuration: 516 .-(::::::::) 2001:db8:3::1 517 .-(::: IPv6 :::)-. +-------------+ 518 (:::: Internet ::::) | IPv6 Host H | 519 `-(::::::::::::)-' +-------------+ 520 `-(::::::)-' 521 ,~~~~~~~~~~~~~~~~~, 522 ,----|companion gateway|--. 523 / '~~~~~~~~~~~~~~~~~' : 524 / |. 525 ,-' `. 526 ; +------------+ +------------+ ) 527 : | Router A | | Router B | / fe80::*192.0.2.5 528 : | (isatap) | | (isatap) | ; 2001:db8:2::1 529 + +------------+ +------------+ \ +--------------+ 530 ; fe80::*192.0.2.1 fe80::*192.0.2.2 : | (isatap) | 531 | ; | Host G | 532 : IPv4 Site -+-' +--------------+ 533 `-. (PRL: 192.0.2.1, 192.0.2.2) .) 534 \ _) 535 `-----+--------)----+'----' 536 fe80::*192.0.2.3 fe80::*192.0.2.4 .-. 537 +--------------+ +--------------+ ,-( _)-. 538 | (isatap) | | (isatap) | .-(_ IPv6 )-. 539 | Router C | | Router E |--(__Edge Network ) 540 +--------------+ +--------------+ `-(______)-' 541 2001:db8:0::/48 2001:db8:1::/48 | 542 | 2001:db8:1::1 543 .-. +-------------+ 544 ,-( _)-. 2001:db8::1 | IPv6 Host F | 545 .-(_ IPv6 )-. +-------------+ +-------------+ 546 (__Edge Network )--| IPv6 Host D | 547 `-(______)-' +-------------+ 549 (* == "5efe:") 550 Figure 3: Reference ISATAP Network Topology 552 In Figure 3, advertising ISATAP routers 'A' and 'B' within the IPv4 553 site connect to the IPv6 Internet, either directly or via a companion 554 gateway. 'A' configures a provider network IPv4 interface with 555 address 192.0.2.1 and arranges to add the address to the provider 556 network PRL. 'A' next configures an advertising ISATAP router 557 interface with link-local IPv6 address fe80::5efe:192.0.2.1 over the 558 IPv4 interface. In the same fashion, 'B' configures the IPv4 559 interface address 192.0.2.2, adds the address to the PRL, then 560 configures the IPv6 ISATAP interface link-local address fe80::5efe: 561 192.0.2.2. 563 Non-advertising ISATAP router 'C' connects to one or more IPv6 edge 564 networks and also connects to the site via an IPv4 interface with 565 address 192.0.2.3, but it does not add the IPv4 address to the site's 566 PRL. 'C' next configures a non-advertising ISATAP router interface 567 with link-local address fe80::5efe:192.0.2.3, then receives the IPv6 568 prefix 2001:db8::/48 through a DHCPv6 prefix delegation exchange via 569 one of 'A' or 'B'. 'C' then engages in an IPv6 routing protocol over 570 its ISATAP interface and announces the delegated IPv6 prefix. 'C' 571 finally sub-delegates the prefix to its attached edge networks, where 572 IPv6 host 'D' autoconfigures the address 2001:db8::1. 574 Non-advertising ISATAP router 'E' connects to the site, configures 575 its ISATAP interface, receives a DHCPv6 prefix delegation, and 576 engages in the IPv6 routing protocol the same as for router 'C'. In 577 particular, 'E' configures the IPv4 address 192.0.2.4, the ISATAP 578 link-local address fe80::5efe:192.0.2.4, and the delegated IPv6 579 prefix 2001:db8:1::/48. 'E' finally sub-delegates the prefix to its 580 attached edge networks, where IPv6 host 'F' autoconfigures IPv6 581 address 2001:db8:1::1. 583 ISATAP host 'G' connects to the site via an IPv4 interface with 584 address 192.0.2.5, and also configures an ISATAP host interface with 585 link-local address fe80::5efe:192.0.2.5 over the IPv4 interface. 'G' 586 next configures a default IPv6 route with next-hop address fe80:: 587 5efe:192.0.2.2 via the ISATAP interface, then receives the IPv6 588 address 2001:db8:2::1 from a DHCPv6 address configuration exchange 589 via 'B'. When 'G' receives the IPv6 address, it assigns the address 590 to the ISATAP interface but does not assign a non-link-local IPv6 591 prefix to the interface. 593 Finally, IPv6 host 'H' connects to an IPv6 network outside of the 594 ISATAP domain. 'H' configures its IPv6 interface in a manner 595 specific to its attached IPv6 link, and autoconfigures the IPv6 596 address 2001:db8:3::1. 598 Following this autoconfiguration, when host 'D' has an IPv6 packet to 599 send to host 'F', it prepares the packet with source address 2001: 600 db8::1 and destination address 2001:db8:1::1, then sends the packet 601 into the edge network where it will eventually be forwarded to router 602 'C'. 'C' then uses ISATAP encapsulation to forward the packet to 603 router 'E', since it has discovered a route to 2001:db8:1::/48 with 604 next hop 'E' via dynamic routing over the ISATAP interface. Router 605 'E' finally forwards the packet to host 'F'. 607 In a second scenario, when 'D' has a packet to send to ISATAP host 608 'G', it prepares the packet with source address 2001:db8::1 and 609 destination address 2001:db8:2::1, then sends the packet into the 610 edge network where it will eventually be forwarded to router 'C' the 611 same as above. 'C' then uses ISATAP encapsulation to forward the 612 packet to router 'A' (i.e., a router that advertises "default"), 613 which in turn forwards the packet to 'G'. Note that this operation 614 entails two hops across the ISATAP link (i.e., one from 'C' to 'A', 615 and a second from 'A' to 'G'). If 'G' also participates in the 616 dynamic IPv6 routing protocol, however, 'C' could instead forward the 617 packet directly to 'G' without involving 'A'. 619 In a third scenario, when 'D' has a packet to send to host 'H' in the 620 IPv6 Internet, the packet is forwarded to 'C' the same as above. 'C' 621 then forwards the packet to 'A', which forwards the packet into the 622 IPv6 Internet. 624 In a final scenario, when 'G' has a packet to send to host 'H' in the 625 IPv6 Internet, the packet is forwarded directly to 'B', which 626 forwards the packet into the IPv6 Internet. 628 3.2.4.6. Scaling Considerations 630 Figure 3 depicts an ISATAP network topology with only two advertising 631 ISATAP routers within the provider network. In order to support 632 larger numbers of non-advertising ISATAP routers and ISATAP hosts, 633 the provider network can deploy more advertising ISATAP routers to 634 support load balancing and generally shortest-path routing. 636 Such an arrangement requires that the advertising ISATAP routers 637 participate in an IPv6 routing protocol instance so that IPv6 638 address/prefix delegations can be mapped to the correct router. The 639 routing protocol instance can be configured as either a full mesh 640 topology involving all advertising ISATAP routers, or as a partial 641 mesh topology with each advertising ISATAP router associating with 642 one or more companion gateways. Each such companion gateway would in 643 turn participate in a full mesh between all companion gateways. 645 3.2.4.7. On-Demand Dynamic Routing 647 With respect to the reference operational scenario depicted in 648 Figure 3, there will be many use cases in which a proactive dynamic 649 IPv6 routing protocol cannot be used. For example, in large 650 enterprise network deployments it would be impractical for all 651 routers to engage in a common routing protocol instance due to 652 scaling considerations. 654 In those cases, an on-demand routing capability can be enabled in 655 which ISATAP nodes send initial packets via an advertising ISATAP 656 router and receive redirection messages back. For example, when a 657 non-advertising ISATAP router 'B' has a packet to send to a host 658 located behind non-advertising ISATAP router 'D', it can send the 659 initial packets via advertising router 'A' which will return 660 redirection messages to inform 'B' that 'D' is a better first hop. 661 Protocol details for this ISATAP redirection are specified in 662 [I-D.templin-aero]. 664 3.3. Destination and Source Address Checks 666 Tunnel routers can use a source address check mitigation when they 667 forward an IPv6 packet into a tunnel interface with an IPv6 source 668 address that embeds one of the router's configured IPv4 addresses. 669 Similarly, tunnel routers can use a destination address check 670 mitigation when they receive an IPv6 packet on a tunnel interface 671 with an IPv6 destination address that embeds one of the router's 672 configured IPv4 addresses. These checks should correspond to both 673 tunnels' IPv6 address formats, regardless of the type of tunnel the 674 router employs. 676 For example, if tunnel router R1 (of any tunnel protocol) forwards a 677 packet into a tunnel interface with an IPv6 source address that 678 matches the 6to4 prefix 2002:IP1::/48, the router discards the packet 679 if IP1 is one of its own IPv4 addresses. In a second example, if 680 tunnel router R2 receives an IPv6 packet on a tunnel interface with 681 an IPv6 destination address with an off-link prefix but with an 682 interface identifier that matches the ISATAP address suffix ::0200: 683 5EFE:IP2, the router discards the packet if IP2 is one of its own 684 IPv4 addresses. 686 Hence a tunnel router can avoid the attack by performing the 687 following checks: 689 o When the router forwards an IPv6 packet into a tunnel interface, 690 it discards the packet if the IPv6 source address has an off-link 691 prefix but embeds one of the router's configured IPv4 addresses. 693 o When the router receives an IPv6 packet on a tunnel interface, it 694 discards the packet if the IPv6 destination address has an off- 695 link prefix but embeds one of the router's configured IPv4 696 addresses. 698 This approach has the advantage that no ancillary state is required, 699 since checking is through static lookup in the lists of IPv4 and IPv6 700 addresses belonging to the router. However, this approach has some 701 inherent limitations: 703 o The checks incur an overhead which is proportional to the number 704 of IPv4 addresses assigned to the router. If a router is assigned 705 many addresses, the additional processing overhead for each packet 706 may be considerable. Note that an unmitigated attack packet would 707 be repetitively processed by the router until the Hop Limit 708 expires, which may require as many as 255 iterations. Hence, an 709 unmitigated attack will consume far more aggregate processing 710 overhead than per-packet address checks even if the router assigns 711 a large number of addresses. 713 o The checks should be performed for the IPv6 address formats of 714 every existing automatic IPv6 tunnel protocol (which uses 715 protocol-41 encapsulation). Hence, the checks must be updated as 716 new protocols are defined. 718 o Before the checks can be performed the format of the address must 719 be recognized. There is no guarantee that this can be generally 720 done. For example, one can not determine if an IPv6 address is a 721 6rd one, hence the router would need to be configured with a list 722 of all applicable 6rd prefixes (which may be prohibitively large) 723 in order to unambiguously apply the checks. 725 o The checks cannot be performed if the embedded IPv4 address is a 726 private one [RFC1918] since it is ambiguous in scope. Namely, the 727 private address may be legitimately allocated to another node in 728 another routing region. 730 The last limitation may be relieved if the router has some 731 information that allows it to unambiguously determine the scope of 732 the address. The check in the following subsection is one example 733 for this. 735 3.3.1. Known IPv6 Prefix Check 737 A router may be configured with the full list of IPv6 subnet prefixes 738 assigned to the tunnels attached to its current IPv4 routing region. 739 In such a case it can use the list to determine when static 740 destination and source address checks are possible. By keeping track 741 of the list of IPv6 prefixes assigned to the tunnels in the IPv4 742 routing region, a router can perform the following checks on an 743 address which embeds a private IPv4 address: 745 o When the router forwards an IPv6 packet into its tunnel with a 746 source address that embeds a private IPv4 address and matches an 747 IPv6 prefix in the prefix list, it determines whether the packet 748 should be discarded or forwarded by performing the source address 749 check specified in Section 3.3. Otherwise, the router forwards 750 the packet. 752 o When the router receives an IPv6 packet on its tunnel interface 753 with a destination address that embeds a private IPv4 address and 754 matches an IPv6 prefix in the prefix list, it determines whether 755 the packet should be discarded or forwarded by performing the 756 destination address check specified in Section 3.3. Otherwise, 757 the router forwards the packet. 759 The disadvantage of this approach is the administrative overhead for 760 maintaining the list of IPv6 subnet prefixes associated with an IPv4 761 routing region may become unwieldy should that list be long and/or 762 frequently updated. 764 4. Recommendations 766 In light of the mitigation measures proposed above we make the 767 following recommendations in decreasing order: 769 1. When possible, it is recommended that the attacks are 770 operationally eliminated (as per one of the measures proposed in 771 Section 3.2). 773 2. For tunnel routers that keep a coherent and trusted neighbor 774 cache which includes all legitimate end-points of the tunnel, we 775 recommend exercising the Neighbor Cache Check. 777 3. For tunnel routers that can implement the Neighbor Reachability 778 Check, we recommend exercising it. 780 4. For tunnels having small and static list of end-points we 781 recommend exercising Known IPv4 Address Check. 783 5. We generally do not recommend using the Destination and Source 784 Address Checks since they can not mitigate routing loops with 6rd 785 routers. Therefore, these checks should not be used alone unless 786 there is operational assurance that other measures are exercised 787 to prevent routing loops with 6rd routers. 789 As noted earlier, tunnels may be deployed in various operational 790 environments. There is a possibility that other mitigations may be 791 feasible in specific deployment scenarios. The above recommendations 792 are general and do not attempt to cover such scenarios. 794 5. IANA Considerations 796 This document has no IANA considerations. 798 6. Security Considerations 800 This document aims at presenting possible solutions to the routing 801 loop attack which involves automatic tunnels' routers. It contains 802 various checks that aim to recognize and drop specific packets that 803 have strong potential to cause a routing loop. These checks do not 804 introduce new security threats. 806 7. Acknowledgments 808 This work has benefited from discussions on the V6OPS, 6MAN and 809 SECDIR mailing lists. The document has further benefitted from 810 comments received from members of the IESG during their review. 811 Dmitry Anipko, Fred Baker, Stewart Bryant, Remi Despres, Adrian 812 Farrell, Fernando Gont, Christian Huitema, Joel Jaeggli, and Dave 813 Thaler are acknowledged for their contributions. 815 8. References 817 8.1. Normative References 819 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 820 E. Lear, "Address Allocation for Private Internets", 821 BCP 5, RFC 1918, February 1996. 823 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 824 via IPv4 Clouds", RFC 3056, February 2001. 826 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 827 and M. Carney, "Dynamic Host Configuration Protocol for 828 IPv6 (DHCPv6)", RFC 3315, July 2003. 830 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 831 Host Configuration Protocol (DHCP) version 6", RFC 3633, 832 December 2003. 834 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 835 for IPv6 Hosts and Routers", RFC 4213, October 2005. 837 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 838 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 839 September 2007. 841 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 842 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 843 March 2008. 845 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 846 Infrastructures (6rd) -- Protocol Specification", 847 RFC 5969, August 2010. 849 8.2. Informative References 851 [I-D.gont-6man-teredo-loops] 852 Gont, F., "Mitigating Teredo Rooting Loop Attacks", 853 draft-gont-6man-teredo-loops-00 (work in progress), 854 September 2010. 856 [I-D.ietf-v6ops-6to4-advisory] 857 Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 858 draft-ietf-v6ops-6to4-advisory-01 (work in progress), 859 April 2011. 861 [I-D.templin-aero] 862 Templin, F., "Asymmetric Extended Route Optimization 863 (AERO)", draft-templin-aero-00 (work in progress), 864 March 2011. 866 [I-D.templin-v6ops-isops] 867 Templin, F., "Operational Guidance for IPv6 Deployment in 868 IPv4 Sites using ISATAP", draft-templin-v6ops-isops-00 869 (work in progress), May 2011. 871 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 872 Network Address Translations (NATs)", RFC 4380, 873 February 2006. 875 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 876 Service Considerations", RFC 4732, December 2006. 878 [USENIX09] 879 Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 880 Tunnels", USENIX WOOT, August 2009. 882 Authors' Addresses 884 Gabi Nakibly 885 National EW Research & Simulation Center 886 P.O. Box 2250 (630) 887 Haifa 31021 888 Israel 890 Email: gnakibly@yahoo.com 892 Fred L. Templin 893 Boeing Research & Technology 894 P.O. Box 3707 MC 7L-49 895 Seattle, WA 98124 896 USA 898 Email: fltemplin@acm.org