idnits 2.17.1 draft-ietf-v6ops-tunnel-loops-04.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 (March 09, 2011) is 4796 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 5214 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: Standards Track Simulation Center 5 Expires: September 10, 2011 F. Templin 6 Boeing Research & Technology 7 March 09, 2011 9 Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and 10 Proposed Mitigations 11 draft-ietf-v6ops-tunnel-loops-04.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. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. A Detailed Description of the Attack . . . . . . . . . . . . . 4 60 3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6 61 3.1. Verification of end point existence . . . . . . . . . . . 6 62 3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 6 63 3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 7 64 3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 7 65 3.2.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 8 66 3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 8 67 3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9 68 3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 9 69 3.3. Destination and Source Address Checks . . . . . . . . . . 21 70 3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 22 71 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 23 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 80 1. Introduction 82 IPv6-in-IPv4 tunnels are an essential part of many migration plans 83 for IPv6. They allow two IPv6 nodes to communicate over an IPv4-only 84 network. Automatic tunnels that assign non-link-local IPv6 prefixes 85 with stateless address mapping properties (hereafter called 86 "automatic tunnels") are a category of tunnels in which a tunneled 87 packet's egress IPv4 address is embedded within the destination IPv6 88 address of the packet. An automatic tunnel's router is a router that 89 respectively encapsulates and decapsulates the IPv6 packets into and 90 out of the tunnel. 92 Ref. [USENIX09] pointed out the existence of a vulnerability in the 93 design of IPv6 automatic tunnels. Tunnel routers operate on the 94 implicit assumption that the destination address of an incoming IPv6 95 packet is always an address of a valid node that can be reached via 96 the tunnel. The assumption of path validity poses a denial of 97 service risk as inconsistency between the IPv4 routing state and the 98 IPv6 routing state allows a routing loop to be formed. 100 An attacker can exploit this vulnerability by crafting a packet which 101 is routed over a tunnel to a node that is not participating in that 102 tunnel. This node may forward the packet out of the tunnel to the 103 native IPv6 network. There the packet is routed back to the ingress 104 point that forwards it back into the tunnel. Consequently, the 105 packet loops in and out of the tunnel. The loop terminates only when 106 the Hop Limit field in the IPv6 header of the packet is decremented 107 to zero. This vulnerability can be abused as a vehicle for traffic 108 amplification to facilitate DoS attacks [RFC4732]. 110 Without compensating security measures in place, all IPv6 automatic 111 tunnels that are based on protocol-41 encapsulation [RFC4213] are 112 vulnerable to such an attack including ISATAP [RFC5214], 6to4 113 [RFC3056] and 6rd [RFC5969]. It should be noted that this document 114 does not consider non-protocol-41 encapsulation attacks. In 115 particular, we do not address the Teredo [RFC4380] attacks described 116 in [USENIX09]. These attacks are considered in 117 [I-D.gont-6man-teredo-loops]. 119 The aim of this document is to shed light on the routing loop attack 120 and describe possible mitigation measures that should be considered 121 by operators of current IPv6 automatic tunnels and by designers of 122 future ones. We note that tunnels may be deployed in various 123 operational environments, e.g. service provider network, enterprise 124 network, etc. Specific issues related to the attack which are 125 derived from the operational environment are not considered in this 126 document. 128 2. A Detailed Description of the Attack 130 In this section we shall denote an IPv6 address of a node reached via 131 a given tunnel by the prefix of the tunnel and an IPv4 address of the 132 tunnel end point, i.e., Addr(Prefix, IPv4). Note that the IPv4 133 address may or may not be part of the prefix (depending on the 134 specification of the tunnel's protocol). The IPv6 address may be 135 dependent on additional bits in the interface ID, however for our 136 discussion their exact value is not important. 138 The two victims of this attack are routers - R1 and R2 - of two 139 different tunnels - T1 and T2. Both routers have the capability to 140 forward IPv6 packets in and out of their respective tunnels. The two 141 tunnels need not be based on the same tunnel protocol. The only 142 condition is that the two tunnel protocols be based on protocol-41 143 encapsulation. The IPv4 address of R1 is IP1, while the prefix of 144 its tunnel is Prf1. IP2 and Prf2 are the respective values for R2. 145 We assume that IP1 and IP2 belong to the same address realm, i.e., 146 they are either both public, or both private and belong to the same 147 internal network. The following network diagram depicts the 148 locations of the two routers. The numbers indicate the packets of 149 the attack and the path they traverse as described below. 151 ####### 152 # R1 # 153 ####### 154 // \ 155 T1 // 2 \ 1 156 interface // \ 157 _______________//_ __\________________ 158 | | | | 159 | IPv4 Network | | IPv6 Network | 160 |__________________| |___________________| 161 \\ / 162 \\ / 163 T2 \\ 2 / 0,1 164 interface \\ / 165 ####### 166 # R2 # 167 ####### 169 Figure 1: The network setting of the attack 171 The attack is depicted in Figure 2. It is initiated by sending an 172 IPv6 packet (packet 0 in Figure 2) destined to a fictitious end point 173 that appears to be reached via T2 and has IP1 as its IPv4 address, 174 i.e., Addr(Prf2, IP1). The source address of the packet is a T1 175 address with Prf1 as the prefix and IP2 as the embedded IPv4 address, 176 i.e., Addr(Prf1, IP2). As the prefix of the destination address is 177 Prf2, the packet will be routed over the IPv6 network to T2. 179 We assume that R2 is the packet's entry point to T2. R2 receives the 180 packet through its IPv6 interface and forwards it over its T2 181 interface encapsulated with an IPv4 header having a destination 182 address derived from the IPv6 destination, i.e., IP1. The source 183 address is the address of R2, i.e., IP2. The packet (packet 1 in 184 Figure 2.) is routed over the IPv4 network to R1, which receives the 185 packet on its IPv4 interface. It processes the packet as a packet 186 that originates from one of the end nodes of T1. 188 Since the IPv4 source address corresponds to the IPv6 source address, 189 R1 will decapsulate the packet. Since the packet's IPv6 destination 190 is outside of T1, R1 will forward the packet onto a native IPv6 191 interface. The forwarded packet (packet 2 in Figure 2) is identical 192 to the original attack packet. Hence, it is routed back to R2, in 193 which the loop starts again. Note that the packet may not 194 necessarily be transported from R1 over native IPv6 network. R1 may 195 be connected to the IPv6 network through another tunnel. 197 R1 R2 198 | | 0 199 | 1 |<------ 200 |<===============| 201 | 2 | 202 |--------------->| 203 | . | 204 | . | 206 1 - IPv4: IP2 --> IP1 207 IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) 208 0,2- IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) 210 Legend: ====> - tunneled IPv6, ---> - native IPv6 212 Figure 2: Routing loop attack between two tunnels' routers 214 The crux of the attack is as follows. The attacker exploits the fact 215 that R2 does not know that R1 does not take part of T2 and that R1 216 does not know that R2 does not take part of T1. The IPv4 network 217 acts as a shared link layer for the two tunnels. Hence, the packet 218 is repeatedly forwarded by both routers. It is noted that the attack 219 will fail when the IPv4 network can not transport packets between the 220 tunnels. For example, when the two routers belong to different IPv4 221 address realms or when ingress/egress filtering is exercised between 222 the routes. 224 The loop will stop when the Hop Limit field of the packet reaches 225 zero. After a single loop the Hop Limit field is decreased by the 226 number of IPv6 routers on path from R1 and R2. Therefore, the number 227 of loops is inversely proportional to the number of IPv6 hops between 228 R1 and R2. 230 The tunnel pair T1 and T2 may be any combination of automatic tunnel 231 types, e.g., ISATAP, 6to4 and 6rd. This has the exception that both 232 tunnels can not be of type 6to4, since two 6to4 routers can not 233 belong to different tunnels (there is only one 6to4 tunnel in the 234 Internet). For example, if the attack were to be launched on an 235 ISATAP router (R1) and 6to4 relay (R2), then the destination and 236 source addresses of the attack packet would be 2002:IP1:* and Prf1:: 237 0200:5EFE:IP2, respectively. 239 3. Proposed Mitigation Measures 241 This section presents some possible mitigation measures for the 242 attack described above. For each measure we shall discuss its 243 advantages and disadvantages. 245 The proposed measures fall under the following three categories: 247 o Verification of end point existence 249 o Operational measures 251 o Destination and source addresses checks 253 3.1. Verification of end point existence 255 The routing loop attack relies on the fact that a router does not 256 know whether there is an end point that can reached via its tunnel 257 that has the source or destination address of the packet. This 258 category includes mitigation measures which aim to verify that there 259 is a node which participate in the tunnel and its address corresponds 260 to the packet's destination or source addresses, as appropriate. 262 3.1.1. Neighbor Cache Check 264 One way that the router can verify that an end host exists and can be 265 reached via the tunnel is by checking whether a valid entry exists 266 for it in the neighbor cache of the corresponding tunnel interface. 267 The neighbor cache entry can be populated through, e.g., an initial 268 reachability check, receipt of neighbor discovery messages, 269 administrative configuration, etc. 271 When the router has a packet to send to a potential tunnel host for 272 which there is no neighbor cache entry, it can perform an initial 273 reachability check on the packet's destination address, e.g., as 274 specified in the second paragraph of Section 8.4 of [RFC5214]. (The 275 router can similarly perform a "reverse reachability" check on the 276 packet's source address when it receives a packet from a potential 277 tunnel host for which there is no neighbor cache entry.) This 278 reachability check parallels the address resolution specifications in 279 Section 7.2 of [RFC4861], i.e., the router maintains a small queue of 280 packets waiting for reachability confirmation to complete. If 281 confirmation succeeds, the router discovers that a legitimate tunnel 282 host responds to the address. Otherwise, the router discards 283 subsequent packets and returns ICMP destination unreachable 284 indications as specified in Section 7.2.2 of [RFC4861]. 286 Note that this approach assumes that the neighbor cache will remain 287 coherent and not subject to malicious attack, which must be confirmed 288 based on specific deployment scenarios. One possible way for an 289 attacker to subvert the neighbor cache is to send false neighbor 290 discovery messages with a spoofed source address. 292 3.1.2. Known IPv4 Address Check 294 Another approach that enables a router to verify that an end host 295 exists and can be reached via the tunnel is simply by pre-configuring 296 the router with the set of IPv4 addresses that are authorized to use 297 the tunnel. Upon this configuration the router can perform the 298 following simple checks: 300 o When the router forwards an IPv6 packet into the tunnel interface 301 with a destination address that matches an on-link prefix and that 302 embeds the IPv4 address IP1, it discards the packet if IP1 does 303 not belong to the configured list of IPv4 addresses. 305 o When the router receives an IPv6 packet on the tunnel's interface 306 with a source address that matches a on-link prefix and that 307 embeds the IPv4 address IP2, it discards the packet if IP2 does 308 not belong to the configured list of IPv4 addresses. 310 3.2. Operational Measures 312 The following measures can be taken by the network operator. Their 313 aim is to configure the network in such a way that the attacks can 314 not take place. 316 3.2.1. Avoiding a Shared IPv4 Link 318 As noted above, the attack relies on having an IPv4 network as a 319 shared link-layer between more than one tunnel. From this the 320 following two mitigation measures arise: 322 3.2.1.1. Filtering IPv4 Protocol-41 Packets 324 In this measure a tunnel router may drop all IPv4 protocol-41 packets 325 received or sent over interfaces that are attached to an untrusted 326 IPv4 network. This will cut-off any IPv4 network as a shared link. 327 This measure has the advantage of simplicity. However, such a 328 measure may not always be suitable for scenarios where IPv4 329 connectivity is essential on all interfaces. 331 3.2.1.2. Operational Avoidance of Multiple Tunnels 333 This measure mitigates the attack by simply allowing for a single 334 IPv6 tunnel to operate in a bounded IPv4 network. For example, the 335 attack can not take place in broadband home networks. In such cases 336 there is a small home network having a single residential gateway 337 which serves as a tunnel router. A tunnel router is vulnerable to 338 the attack only if it has at least two interfaces with a path to the 339 Internet: a tunnel interface and a native IPv6 interface (as depicted 340 in Figure 1). However, a residential gateway usually has only a 341 single interface to the Internet, therefore the attack can not take 342 place. Moreover, if there are only one or a few tunnel routers in 343 the IPv4 network and all participate in the same tunnel then there is 344 no opportunity for perpetuating the loop. 346 This approach has the advantage that it avoids the attack profile 347 altogether without need for explicit mitigations. However, it 348 requires careful configuration management which may not be tenable in 349 large and/or unbounded IPv4 networks. 351 3.2.2. A Single Border Router 353 It is reasonable to assume that a tunnel router shall accept or 354 forward tunneled packets only over its tunnel interface. It is also 355 reasonable to assume that a tunnel router shall accept or forward 356 IPv6 packets only over its IPv6 interface. If these two interfaces 357 are physically different then the network operator can mitigate the 358 attack by ensuring that the following condition holds: there is no 359 path between these two interfaces that does not go through the tunnel 360 router. 362 The above condition ensures that an encapsulated packet which is 363 transmitted over the tunnel interface will not get to another tunnel 364 router and from there to the IPv6 interface of the first router. The 365 condition also ensures the reverse direction, i.e., an IPv6 packet 366 which is transmitted over the IPv6 interface will not get to another 367 tunnel router and from there to the tunnel interface of the first 368 router. This condition is essentially translated to a scenario in 369 which the tunnel router is the only border router between the IPv6 370 network and the IPv4 network to which it is attached (as in broadband 371 home network scenario mentioned above). 373 3.2.3. A Comprehensive List of Tunnel Routers 375 If a tunnel router can be configured with a comprehensive list of 376 IPv4 addresses of all other tunnel routers in the network, then the 377 router can use the list as a filter to discard any tunneled packets 378 coming from other routers. For example, a tunnel router can use the 379 network's ISATAP Potential Router List (PRL) [RFC5214] as a filter as 380 long as there is operational assurance that all ISATAP routers are 381 listed and that no other types of tunnel routers are present in the 382 network. 384 This measure parallels the one proposed for 6rd in [RFC5969] where 385 the 6rd BR filters all known relay addresses of other tunnels inside 386 the ISP's network. 388 This measure is especially useful for intra-site tunneling 389 mechanisms, such as ISATAP and 6rd, since filtering can be exercised 390 on well-defined site borders. 392 3.2.4. Avoidance of On-link Prefixes 394 The looping attack exploits the fact that a router is permitted to 395 assign non-link-local IPv6 prefixes on its tunnel interfaces, which 396 could cause it to send tunneled packets to other routers that do not 397 configure an address from the prefix. Therefore, if the router does 398 not assign non-link-local IPv6 prefixes on its tunnel interfaces 399 there is no opportunity for it to initiate the loop. If the router 400 further ensures that the routing state is consistent for the packets 401 it receives on its tunnel interfaces there is no opportunity for it 402 to propagate a loop initiated by a different router. 404 This mitigation is available only to ISATAP routers, since the ISATAP 405 stateless address mapping operates only on the Interface Identifier 406 portion of the IPv6 address, and not on the IPv6 prefix. . The 407 mitigation is also only applicable on ISATAP links on which IPv4 408 source address spoofing is disabled. This section specifies new 409 operational procedures and mechanisms needed to implement the 410 mitigation; it therefore updates [RFC5214]. 412 3.2.4.1. ISATAP Router Interface Types 414 ISATAP provides a Potential Router List (PRL) to further ensure a 415 loop-free topology. Routers that are members of the provider network 416 PRL configure their provider network ISATAP interfaces as advertising 417 router interfaces (see: [RFC4861], Section 6.2.2), and therefore may 418 send Router Advertisement (RA) messages that include non-zero Router 419 Lifetimes. Routers that are not members of the provider network PRL 420 configure their provider network ISATAP interfaces as non-advertising 421 router interfaces. 423 3.2.4.2. ISATAP Source Address Verification 425 ISATAP nodes employ the source address verification checks specified 426 in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of 427 packets received on an ISATAP interface. To enable the on-link 428 prefix avoidance procedures outlined in this section, ISATAP nodes 429 must employ an additional source address verification check; namely, 430 the node also considers the outer IPv4 source address correct for the 431 inner IPv6 source address if: 433 o a forwarding table entry exists that lists the packet's IPv4 434 source address as the link-layer address corresponding to the 435 inner IPv6 source address via the ISATAP interface. 437 3.2.4.3. ISATAP Host Behavior 439 ISATAP hosts send Router Solicitation (RS) messages to obtain RA 440 messages from an advertising ISATAP router. Whether or not non-link- 441 local IPv6 prefixes are advertised, the host can acquire IPv6 442 addresses, e.g., through the use of DHCPv6 stateful address 443 autoconfiguration [RFC3315]. To acquire addresses, the host performs 444 standard DHCPv6 exchanges while mapping the IPv6 445 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to 446 the IPv4 address of the advertising router (hence, the advertising 447 router must configure either a DHCPv6 relay or server function). The 448 host should also use DHCPv6 Authentication, and the DHCPv6 server 449 should refuse to process requests from hosts that cannot be 450 authenticated. 452 After the host receives IPv6 addresses, it assigns them to its ISATAP 453 interface and forwards any of its outbound IPv6 packets via the 454 advertising router as a default router. The advertising router in 455 turn maintains IPv6 forwarding table entries in the CURRENT state 456 that list the IPv4 address of the host as the link-layer address of 457 the delegated IPv6 addresses, and generates redirection messages to 458 inform the host of a better next hop when appropriate. 460 3.2.4.4. ISATAP Router Behavior 462 In many use case scenarios (e.g., small enterprise networks, etc.), 463 advertising and non-advertising ISATAP routers can engage in a full- 464 or partial-topology dynamic IPv6 routing protocol, so that IPv6 465 routing/forwarding tables can be populated and standard IPv6 466 forwarding between ISATAP routers can be used. In other scenarios 467 (e.g., large ISP networks, etc.) this might be impractical dues to 468 scaling and security issues. 470 When a dynamic routing protocol cannot be used, non-advertising 471 ISATAP routers send RS messages to obtain RA messages from an 472 advertising ISATAP router, i.e., they act as "hosts" on their non- 473 advertising ISATAP interfaces. Non-advertising routers can also 474 acquire IPv6 prefixes, e.g., through the use of DHCPv6 Prefix 475 Delegation [RFC3633] via an advertising router in the same fashion as 476 described above for host-based DHCPv6 stateful address 477 autoconfiguration. 479 After the non-advertising router acquires IPv6 prefixes, it can sub- 480 delegate them to routers and links within its attached IPv6 edge 481 networks, then can forward any outbound IPv6 packets coming from its 482 edge networks via the advertising router as a default router. The 483 advertising router in turn maintains IPv6 forwarding table entries in 484 the CURRENT state that list the IPv4 address of the non-advertising 485 router as the link-layer address of the next hop toward the delegated 486 IPv6 prefixes, and generates redirection messages to inform the non- 487 advertising router of a better next hop when appropriate. 489 This implies that the advertising router considers the delegated 490 prefixes as identifying the non-advertising router as an on-link 491 neighbor for the purpose of generating redirection messages, and that 492 the non-advertising router accepts redirection messages coming from 493 the advertising router as though its ISATAP interface were configured 494 as a host interface. 496 3.2.4.5. Reference Operational Scenario 498 Figure 3 depicts a reference ISATAP network topology for operational 499 avoidance of on-link non-link-local IPv6 prefixes. The scenario 500 shows an advertising ISATAP router, a non-advertising ISATAP router, 501 an ISATAP host and a non-ISATAP IPv6 host in a typical deployment 502 configuration: 504 .-(::::::::) 505 .-(::: IPv6 :::)-. 506 (:::: Internet ::::) 507 `-(::::::::::::)-' 508 `-(::::::)-' 509 ,-. 510 ,-----+-/-+--' \+------. 511 / ,~~~~~~~~~~~~~~~~~, : 512 / |companion gateway| |. 513 ,-' '~~~~~~~~~~~~~~~~~' `. 514 ; +--------------+ ) 515 : | Router A | / 516 : | (isatap) | ; 517 +- +--------------+ -+ 518 ; fe80::5efe:192.0.2.1 : 519 | ; 520 : IPv4 Provider Network -+-' 521 `-. (PRL: 192.0.2.1) .) 522 \ _) 523 `-----+--------)----+'----' 524 fe80::5efe:192.0.2.2 fe80::5efe:192.0.2.3 525 2001:db8:0:1::1 +--------------+ 526 +--------------+ | (isatap) | 527 | (isatap) | | Router C | 528 | Host B | +--------------+ 529 +--------------+ 2001:db8:2::/48 530 .-. 531 ,-( _)-. +------------+ 532 .-(_ IPv6 )-. |(non-isatap)| 533 (__Edge Network )--| Host D | 534 `-(______)-' +------------+ 535 2001:db8:2:1::1 537 Figure 3: Reference ISATAP Network Topology 539 In Figure 3, router 'A' within the IPv4 provider network connects to 540 the IPv6 Internet, either directly or via a companion gateway. 'A' 541 configures a provider network IPv4 interface with address 192.0.2.1 542 and arranges to add the address to the provider network PRL. 'A' 543 next configures an advertising ISATAP router interface with link- 544 local IPv6 address fe80::5efe:192.0.2.1 over the IPv4 interface. 546 Host 'B' connects to the provider network via an IPv4 interface with 547 address 192.0.2.2, and also configures an ISATAP host interface with 548 link-local address fe80::5efe:192.0.2.2 over the IPv4 interface. 'B' 549 next configures a default IPv6 route with next-hop address fe80:: 550 5efe:192.0.2.1 via the ISATAP interface, then receives the IPv6 551 address 2001:db8:0:1::1 from a DHCPv6 address configuration exchange 552 via 'A'. When 'B' receives the IPv6 address, it assigns the address 553 to the ISATAP interface but does not assign a non-link-local IPv6 554 prefix to the interface. 556 Router 'C' connects to one or more IPv6 edge networks and also 557 connects to the provider network via an IPv4 interface with address 558 192.0.2.3, but does not add the address to the provider network PRL. 559 'C' next configures a non-advertising ISATAP router interface with 560 link-local address fe80::5efe:192.0.2.3 over the IPv4 interface, but 561 does not engage in an IPv6 routing protocol over the interface. 'C' 562 therefore configures a default IPv6 route with next-hop address 563 fe80::5efe:192.0.2.1 via the ISATAP interface, and receives the IPv6 564 prefix 2001:db8:2::/48 through a DHCPv6 prefix delegation exchange 565 via 'A'. 'C' finally sub-delegates the prefix to its IPv6 edge 566 networks and configures its IPv6 edge network interfaces as 567 advertising router interfaces. 569 In this example, when 'B' has an IPv6 packet to send to host 'D' 570 within an IPv6 edge network connected by 'C', it prepares the IPv6 571 packet with source address 2001:db8:0:1::1 and destination address 572 2001:db8:2:1::1. 'B' then uses ISATAP encapsulation to forward the 573 packet to 'A' as its default router. 'A' forwards the packet to 'C', 574 and also sends redirection messages to inform 'B' that 'C' is a 575 better next hop toward 'D'. Future packets sent from 'B' to 'D' 576 therefore go directly to 'C' without involving 'A'. An analogous 577 redirection exchange occurs in the reverse direction when 'D' has a 578 packet to send to 'B' (via 'C'). Details of the redirection 579 exchanges are described in Section 3.2.4.6 581 3.2.4.6. ISATAP Predirection 583 With respect to the reference operational scenario depicted in 584 Figure 3, when ISATAP router 'A' receives an IPv6 packet on an 585 advertising ISATAP interface that it will forward back out the same 586 interface, 'A' must arrange to redirect the originating ISATAP node 587 'B' to a better next hop ISATAP node 'C' that is closer to the final 588 destination 'D'. First, however, 'A' must direct 'C' to establish a 589 forwarding table entry in order to satisfy the source address 590 verification check specified in Section 3.2.4.2. This process is 591 accommodated via a unidirectional reliable exchange in which 'A' 592 first informs 'C', then 'C' informs 'B' via 'A' as a trusted 593 intermediary. 'B' therefore knows that 'C' will accept the packets 594 it sends as long as 'C' retains the forwarding table entry. We call 595 this process "predirection", which stands in contrast to ordinary 596 IPv6 redirection. 598 Consider the alternative in which 'A' informs both 'B' and 'C' 599 separately via independent IPv6 Redirect messages (see: [RFC4861]). 601 In that case, several conditions can occur that could result in 602 communications failures. First, if 'B' receives the Redirect message 603 but 'C' does not, subsequent packets sent by 'B' would disappear into 604 a black hole since 'C' would not have a forwarding table entry to 605 verify their source addresses. Second, if 'C' receives the Redirect 606 message but 'B' does not, subsequent packets sent in the reverse 607 direction by 'C' would be lost. Finally, timing issues surrounding 608 the establishment and garbage collection of forwarding table entries 609 at 'B' and 'C' could yield unpredictable behavior. For example, 610 unless the timing were carefully coordinated through some form of 611 synchronization loop, there would invariably be instances in which 612 one node has the correct forwarding table state and the other node 613 does not resulting in non-deterministic packet loss. 615 The following subsections discuss the predirection steps that support 616 the reference operational scenario: 618 3.2.4.6.1. 'A' Sends Predirect Forward To 'C' 620 When 'A' forwards an original IPv6 packet sent by 'B' out the same 621 ISATAP interface that it arrived on, it sends a "Predirect" message 622 forward toward 'C' instead of sending a Redirect message back to 'B'. 623 The Predirect message is simply an ISATAP-specific version of an 624 ordinary IPv6 Redirect message as depicted in Section 4.5 of 625 [RFC4861], and is identified by two new backward-compatible bits 626 taken from the Reserved field as shown in Figure 4: 628 0 1 2 3 629 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Type (=137) | Code (=0) | Checksum | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 |I|P| Reserved | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | | 636 + + 637 | | 638 + Target Address + 639 | | 640 + + 641 | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | | 644 + + 645 | | 646 + Destination Address + 647 | | 648 + + 649 | | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Options ... 652 +-+-+-+-+-+-+-+-+-+-+-+- 654 Figure 4: ISATAP-Specific IPv6 Redirect Message Format 656 Where the new bits are defined as: 658 I (1) the "ISATAP" bit. Set to 1 to indicate an ISATAP-specific 659 Redirect message, and set to 0 to indicate an ordinary IPv6 660 Redirect message. 662 P (1) the "Predirect" bit. Set to 1 to indicate a Predirect 663 message, and set to 0 to indicate a Redirect response to a 664 Predirect message. (This bit is valid only when the I bit is set 665 to 1.) 667 Using this new Predirect message format, 'A' prepares the message in 668 a similar fashion as for an ordinary ISATAP-encapsulated IPv6 669 Redirect message as follows: 671 o the outer IPv4 source address is set to 'A's IPv4 address. 673 o the outer IPv4 destination address is set to 'C's IPv4 address. 675 o the inner IPv6 source address is set to 'A's ISATAP link-local 676 address. 678 o the inner IPv6 destination address is set to 'C's ISATAP link- 679 local address. 681 o the Predirect Target and Destination Addresses are both set to 682 'B's ISATAP link-local address. 684 o the Predirect message includes a Route Information Option (RIO) 685 [RFC4191] that encodes an IPv6 prefix taken from 'B's address/ 686 prefix delegations that covers the IPv6 source address of the 687 originating IPv6 packet. 689 o the Predirect message includes a Redirected Header Option (RHO) 690 that contains at least the header of the originating IPv6 packet. 692 o the I and P bits in the Predirect message header are both set to 693 1. 695 'A' then sends the Predirect message forward to 'C'. 697 3.2.4.6.2. 'C' Processes the Predirect and Sends Redirect Back To 'A' 699 When 'C' receives the Predirect message, it decapsulates the message 700 according to Section 7.3 of [RFC5214] since the outer IPv4 source 701 address is a member of the PRL. 703 'C' then uses the message validation checks specified in Section 8.1 704 of [RFC4861], except that instead of verifying that the "IP source 705 address of the Redirect is the same as the current first-hop router 706 for the specified ICMP Destination Address" (i.e., the 6th 707 verification check), it accepts the message if the "outer IP source 708 address of the Predirect is the same as the current first-hop router 709 for the prefix specified in the RIO". (Note that this represents an 710 ISATAP-specific adaptation of the verification checks.) Finally, 'C' 711 only accepts the message if the destination address of the 712 originating IPv6 packet encapsulated in the RHO is covered by one of 713 its CURRENT delegated addresses/prefixes (see Section 3.2.4.9). 715 'C' then either creates or updates an IPv6 forwarding table entry 716 with the prefix encoded in the RIO option as the target prefix, and 717 the IPv6 Target Address of the Predirect message (i.e., 'B's ISATAP 718 link-local address) as the next hop. 'C' places the entry in the 719 FILTERING state, then sets/resets a filtering expiration timer value 720 of 40 seconds. If the filtering timer expires, the node clears the 721 FILTERING state and deletes the forwarding table entry if it is not 722 in the FORWARDING state. This suggests that 'C's ISATAP interface 723 should maintain a private forwarding table separate from the common 724 IPv6 forwarding table, since the entry must be managed by the ISATAP 725 interface itself. 727 After processing the Predirect message and establishing the 728 forwarding table entry, 'C' prepares an ISATAP Redirect message in 729 response to the Predirect as follows: 731 o the outer IPv4 source address is set to 'C's IPv4 address. 733 o the outer IPv4 destination address is set to 'A's IPv4 address. 735 o the inner IPv6 source address, is set to 'C's ISATAP link-local 736 address. 738 o the inner IPv6 destination address is set to 'A's ISATAP link- 739 local address. 741 o the Redirect Target and the Redirect Destination Addresses are 742 both set to 'C's ISATAP link-local address. 744 o the Redirect message includes an RIO that encodes an IPv6 prefix 745 taken from 'C's address/prefix delegations that covers the IPv6 746 destination address of the originating IPv6 packet encapsulated in 747 the Redirected Header option of the Predirect. 749 o the Redirect message includes an RHO copied from the corresponding 750 Predirect message. 752 o the (I, P) bits in the Redirect message header are set to (1, 0). 754 'C' then sends the Redirect message to 'A'. 756 3.2.4.6.3. 'A' Processes the Redirect then Proxies it Back To 'B' 758 When 'A' receives the Predirect message, it decapsulates the message 759 according to Section 7.3 of [RFC5214] since the inner IPv6 source 760 address embeds the outer IPv4 source address. 762 'A' next accepts the message only if it satisfies the same message 763 validation checks specified for Predirects in Section 3.2.4.6.2. 765 'A' then locates a forwarding table entry that covers the IPv6 source 766 address of the packet segment in the RHO (i.e., a forwarding table 767 entry with next hop 'B'), then proxies the Redirect message back 768 toward 'B'. Without decrementing the IPv6 hop limit in the Redirect 769 message, 'A' next changes the IPv4 source address of the Redirect 770 message to its own IPv4 address, changes the IPv4 destination address 771 to 'B's IPv4 address, changes the IPv6 source address to its own IPv6 772 link-local address, and changes the IPv6 destination address to 'B's 773 IPv6 link-local address. 'A' then sends the proxied Redirect message 774 to 'B'. 776 3.2.4.6.4. 'B' Processes The Redirect Message 778 When 'B' receives the Redirect message, it decapsulates the message 779 according to Section 7.3 of [RFC5214] since the outer IPv4 source 780 address is a member of the PRL. 782 'B' next accepts the message only if it satisfies the same message 783 validation checks specified for Predirects in Section 3.2.4.6.2. 785 'B' then either creates or updates an IPv6 forwarding table entry 786 with the prefix encoded in the RIO option as the target prefix, and 787 the IPv6 Target Address of the Redirect message (i.e., 'C's ISATAP 788 link-local address) as the next hop. 'B' places the entry in the 789 FORWARDING state, then sets/resets a forwarding expiration timer 790 value of 30 seconds. If the forwarding timer expires, the node 791 clears the FORWARDING state and deletes the forwarding table entry if 792 it is not in the FILTERING state. Again, this suggests that 'B's 793 ISATAP interface should maintain a private forwarding table separate 794 from the common IPv6 forwarding table, since the entry must be 795 managed by the ISATAP interface itself. 797 Now, 'B' has a forwarding table entry in the FORWARDING state, and 798 'C' has a forwarding table entry in the FILTERING state. Therefore, 799 'B' may send ordinary IPv6 data packets with destination addresses 800 covered by 'C's prefix directly to 'C' without involving 'A'. 'C' 801 will in turn accept the packets since they satisfy the source address 802 verification rule specified in Section 3.2.4.2. 804 To enable packet forwarding from 'C' directly to 'B', a reverse- 805 predirection operation is required which is the mirror-image of the 806 forward-predirection operation described above. Following the 807 reverse predirection, both 'B' and 'C' will have forwarding table 808 entries in the "(FORWARDING | FILTERING)" state, and IPv6 packets can 809 be exchanged bidirectionally without involving 'A'. 811 3.2.4.6.5. 'B' Sends Periodic Predirect Messages Forward to 'A' 813 In order to keep forwarding table entries alive while data packets 814 are actively flowing, 'B' can periodically send additional Predirect 815 messages via 'A' to solicit Redirect messages from 'C'. When 'B' 816 forwards an IPv6 packet via 'C', and the corresponding forwarding 817 table entry FORWARDING state timer is nearing expiration, 'B' sends 818 Predirect messages (subject to rate limiting) prepared as follows: 820 o the outer IPv4 source address is set to 'B's IPv4 address. 822 o the outer IPv4 destination address is set to 'A's IPv4 address. 824 o the inner IPv6 source address is set to 'B's ISATAP link-local 825 address. 827 o the inner IPv6 destination address is set to 'A's ISATAP link- 828 local address. 830 o the Predirect Target and Destination Addresses are both set to 831 'B's ISATAP link-local address. 833 o the Predirect message includes an RIO that encodes an IPv6 prefix 834 taken from 'B's address/prefix delegations that covers the IPv6 835 source address of the originating IPv6 packet. 837 o the Predirect message includes an RHO that contains at least the 838 header of the originating IPv6 packet. 840 o the I and P bits in the Predirect message header are both set to 841 1. 843 When 'A' receives the Predirect message, it decapsulates the message 844 according to Section 7.3 of [RFC5214] since the inner IPv6 source 845 address embeds the outer IPv4 source address. 847 'A' next accepts the message only if it satisfies the same message 848 validation checks specified for Predirects in Section 3.2.4.6.2. 850 'A' then locates a forwarding table entry that covers the IPv6 851 destination address of the packet segment in the RHO (in this case, a 852 forwarding table entry with next hop 'C'). Without decrementing the 853 IPv6 hop limit in the Redirect message, 'A' next changes the IPv4 854 source address of the Predirect message to its own IPv4 address, 855 changes the IPv4 destination address to 'C's IPv4 address, changes 856 the IPv6 source address to its own IPv6 link-local address, and 857 changes the IPv6 destination address to 'C's IPv6 link-local address. 858 'A' then sends the proxied Predirect message to 'C'. When 'C' 859 receives the proxied message, it processes the message the same as if 860 it had originated from 'A' as described in Section 3.2.4.6.2. 862 3.2.4.7. Scaling Considerations 864 Figure 3 depicts an ISATAP network topology with only a single 865 advertising ISATAP router within the provider network. In order to 866 support larger numbers of non-advertising ISATAP routers and ISATAP 867 hosts, the provider network can deploy more advertising ISATAP 868 routers to support load balancing and generally shortest-path 869 routing. 871 Such an arrangement requires that the advertising ISATAP routers 872 participate in an IPv6 routing protocol instance so that IPv6 873 address/prefix delegations can be mapped to the correct router. The 874 routing protocol instance can be configured as either a full mesh 875 topology involving all advertising ISATAP routers, or as a partial 876 mesh topology with each ISATAP router associating with one or more 877 companion gateways and a full mesh between companion gateways. 879 3.2.4.8. Proxy Chaining 881 In large ISATAP deployments, there may be many advertising ISATAP 882 routers, each serving many ISATAP clients (i.e., both non-advertising 883 routers and simple hosts). The advertising ISATAP routers then 884 either require full topology knowledge, or a default route to a 885 companion gateway that does have full topology knowledge. For 886 example, if Client 'A' connects to advertising ISATAP router 'B', and 887 Client 'E' connects to advertising ISATAP router 'D', then 'B' and 888 'D' must either have full topology knowledge or have a default route 889 to a companion gateway (e.g., 'C') that does. 891 In that case, when 'A' sends an initial packet to 'E', 'B' generates 892 a Predirect message toward 'C', which proxies the message toward 'D' 893 which finally proxies the message toward 'E'. 895 In the reverse direction, when 'E' sends a Redirect response message 896 to 'A', it first sends the message to 'D', which proxies the message 897 toward 'C', which proxies the message toward 'B', which finally 898 proxies the message toward 'A'. 900 3.2.4.9. Mobility 902 An ISATAP router 'A' can configure both a non-advertising ISATAP 903 interface on a provider network and an advertising ISATAP interface 904 on an edge network. In that case, 'A' can service ISATAP clients 905 (i.e. both non-advertising routers and simple hosts) within the edge 906 network by acting as a DHCPv6 relay. When a client 'B' in the edge 907 network that has obtained IPv6 addresses/prefixes moves to a 908 different edge network, however, 'B' can release its address/prefix 909 delegations via 'A' and re-establish them via a different ISATAP 910 router 'C' in the new edge network. 912 When 'B' releases its address/prefix delegations via 'A', 'A' marks 913 the IPv6 forwarding table entries that cover the addresses/prefixes 914 as DEPARTED (i.e., it clears the CURRENT state). 'A' therefore 915 ceases to respond to Predirect messages correlated with the DEPARTED 916 entries, and also schedules a garbage-collection timer of 60 seconds, 917 after which it deletes the DEPARTED entries. 919 When 'A' receives IPv6 packets destined to an address covered by the 920 DEPARTED IPv6 forwarding table entries, it forwards them to the last- 921 known edge network link-layer address of 'B' as a means for avoiding 922 mobility-related packet loss during routing changes. Eventually, 923 correspondents will receive new Redirect messages from the network to 924 discover that 'B' is now associated with 'C'. 926 Note that this mobility management method works the same way when the 927 edge networks comprise native IPv6 links (i.e., and not just for 928 ISATAP links), however any IPv6 packets forwarded by 'A' via an IPv6 929 forwarding table entry in the DEPARTED state may be lost if the 930 mobile node moves off-link with respect to its previous edge network 931 point of attachment. This should not be a problem for large links 932 (e.g., large cellular network deployments, large ISP networks, etc.) 933 in which all/most mobility events are intra-link. 935 3.3. Destination and Source Address Checks 937 Tunnel routers can use a source address check mitigation when they 938 forward an IPv6 packet into a tunnel interface with an IPv6 source 939 address that embeds one of the router's configured IPv4 addresses. 940 Similarly, tunnel routers can use a destination address check 941 mitigation when they receive an IPv6 packet on a tunnel interface 942 with an IPv6 destination address that embeds one of the router's 943 configured IPv4 addresses. These checks should correspond to both 944 tunnels' IPv6 address formats, regardless of the type of tunnel the 945 router employs. 947 For example, if tunnel router R1 (of any tunnel protocol) forwards a 948 packet into a tunnel interface with an IPv6 source address that 949 matches the 6to4 prefix 2002:IP1::/48, the router discards the packet 950 if IP1 is one of its own IPv4 addresses. In a second example, if 951 tunnel router R2 receives an IPv6 packet on a tunnel interface with 952 an IPv6 destination address with an off-link prefix but with an 953 interface identifier that matches the ISATAP address suffix ::0200: 954 5EFE:IP2, the router discards the packet if IP2 is one of its own 955 IPv4 addresses. 957 Hence a tunnel router can avoid the attack by performing the 958 following checks: 960 o When the router forwards an IPv6 packet into a tunnel interface, 961 it discards the packet if the IPv6 source address has an off-link 962 prefix but embeds one of the router's configured IPv4 addresses. 964 o When the router receives an IPv6 packet on a tunnel interface, it 965 discards the packet if the IPv6 destination address has an off- 966 link prefix but embeds one of the router's configured IPv4 967 addresses. 969 This approach has the advantage that that no ancillary state is 970 required, since checking is through static lookup in the lists of 971 IPv4 and IPv6 addresses belonging to the router. However, this 972 approach has some inherent limitations 974 o The checks incur an overhead which is proportional to the number 975 of IPv4 addresses assigned to the router. If a router is assigned 976 many addresses, the additional processing overhead for each packet 977 may be considerable. Note that an unmitigated attack packet would 978 be repetitively processed by the router until the Hop Limit 979 expires, which may require as many as 255 iterations. Hence, an 980 unmitigated attack will consume far more aggregate processing 981 overhead than per-packet address checks even if the router assigns 982 a large number of addresses. 984 o The checks should be performed for the IPv6 address formats of 985 every existing automatic IPv6 tunnel protocol (which uses 986 protocol-41 encapsulation). Hence, the checks must be updated as 987 new protocols are defined. 989 o Before the checks can be performed the format of the address must 990 be recognized. There is no guarantee that this can be generally 991 done. For example, one can not determine if an IPv6 address is a 992 6rd one, hence the router would need to be configured with a list 993 of all applicable 6rd prefixes (which may be prohibitively large) 994 in order to unambiguously apply the checks. 996 o The checks cannot be performed if the embedded IPv4 address is a 997 private one [RFC1918] since it is ambiguous in scope. Namely, the 998 private address may be legitimately allocated to another node in 999 another routing region. 1001 The last limitation may be relieved if the router has some 1002 information that allows it to unambiguously determine the scope of 1003 the address. The check in the following subsection is one example 1004 for this. 1006 3.3.1. Known IPv6 Prefix Check 1008 A router may be configured with the full list of IPv6 subnet prefixes 1009 assigned to the tunnels attached to its current IPv4 routing region. 1010 In such a case it can use the list to determine when static 1011 destination and source address checks are possible. By keeping track 1012 of the list of IPv6 prefixes assigned to the tunnels in the IPv4 1013 routing region, a router can perform the following checks on an 1014 address which embeds a private IPv4 address: 1016 o When the router forwards an IPv6 packet into its tunnel with a 1017 source address that embeds a private IPv4 address and matches an 1018 IPv6 prefix in the prefix list, it determines whether the packet 1019 should be discarded or forwarded by performing the source address 1020 check specified in Section 3.3. Otherwise, the router forwards 1021 the packet. 1023 o When the router receives an IPv6 packet on its tunnel interface 1024 with a destination address that embeds a private IPv4 address and 1025 matches an IPv6 prefix in the prefix list, it determines whether 1026 the packet should be discarded or forwarded by performing the 1027 destination address check specified in Section 3.3. Otherwise, 1028 the router forwards the packet. 1030 The disadvantage of this approach is the administrative overhead for 1031 maintaining the list of IPv6 subnet prefixes associated with an IPv4 1032 routing region may become unwieldy should that list be long and/or 1033 frequently updated. 1035 4. Recommendations 1037 In light of the mitigation measures proposed above we make the 1038 following recommendations in decreasing order: 1040 1. When possible, it is recommended that the attacks are 1041 operationally eliminated (as per one of the measures proposed in 1042 Section 3.2). 1044 2. For tunnel routers that keep a coherent and trusted neighbor 1045 cache which includes all legitimate end-points of the tunnel, we 1046 recommend exercising the Neighbor Cache Check. 1048 3. For tunnel routers that can implement the Neighbor Reachability 1049 Check, we recommend exercising it. 1051 4. For tunnels having small and static list of end-points we 1052 recommend exercising Known IPv4 Address Check. 1054 5. We generally do not recommend using the Destination and Source 1055 Address Checks since they can not mitigate routing loops with 6rd 1056 routers. Therefore, these checks should not be used alone unless 1057 there is operational assurance that other measures are exercised 1058 to prevent routing loops with 6rd routers. 1060 As noted earlier, tunnels may be deployed in various operational 1061 environments. There is a possibility that other mitigations may be 1062 feasible in specific deployment scenarios. The above recommendations 1063 are general and do not attempt to cover such scenarios. 1065 5. IANA Considerations 1067 This document has no IANA considerations. 1069 6. Security Considerations 1071 This document aims at presenting possible solutions to the routing 1072 loop attack which involves automatic tunnels' routers. It contains 1073 various checks that aim to recognize and drop specific packets that 1074 have strong potential to cause a routing loop. These checks do not 1075 introduce new security threats. 1077 7. Acknowledgments 1079 This work has benefited from discussions on the V6OPS, 6MAN and 1080 SECDIR mailing lists. Remi Despres, Christian Huitema, Dmitry 1081 Anipko, Dave Thaler and Fernando Gont are acknowledged for their 1082 contributions. 1084 8. References 1086 8.1. Normative References 1088 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1089 E. Lear, "Address Allocation for Private Internets", 1090 BCP 5, RFC 1918, February 1996. 1092 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1093 via IPv4 Clouds", RFC 3056, February 2001. 1095 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1096 and M. Carney, "Dynamic Host Configuration Protocol for 1097 IPv6 (DHCPv6)", RFC 3315, July 2003. 1099 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1100 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1101 December 2003. 1103 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1104 More-Specific Routes", RFC 4191, November 2005. 1106 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1107 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1109 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1110 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1111 September 2007. 1113 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1114 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1115 March 2008. 1117 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1118 Infrastructures (6rd) -- Protocol Specification", 1119 RFC 5969, August 2010. 1121 8.2. Informative References 1123 [I-D.gont-6man-teredo-loops] 1124 Gont, F., "Mitigating Teredo Rooting Loop Attacks", 1125 draft-gont-6man-teredo-loops-00 (work in progress), 1126 September 2010. 1128 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1129 Network Address Translations (NATs)", RFC 4380, 1130 February 2006. 1132 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1133 Service Considerations", RFC 4732, December 2006. 1135 [USENIX09] 1136 Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 1137 Tunnels", USENIX WOOT, August 2009. 1139 Authors' Addresses 1141 Gabi Nakibly 1142 National EW Research & Simulation Center 1143 P.O. Box 2250 (630) 1144 Haifa 31021 1145 Israel 1147 Email: gnakibly@yahoo.com 1148 Fred L. Templin 1149 Boeing Research & Technology 1150 P.O. Box 3707 MC 7L-49 1151 Seattle, WA 98124 1152 USA 1154 Email: fltemplin@acm.org