idnits 2.17.1 draft-ietf-v6ops-tunnel-loops-02.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 (January 24, 2011) is 4840 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: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 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: Informational Simulation Center 5 Expires: July 28, 2011 F. Templin 6 Boeing Research & Technology 7 January 24, 2011 9 Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and 10 Proposed Mitigations 11 draft-ietf-v6ops-tunnel-loops-02.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 July 28, 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. Destination and Source Address Checks . . . . . . . . . . 6 62 3.1.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 8 63 3.2. Verification of end point existence . . . . . . . . . . . 8 64 3.2.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 8 65 3.2.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 9 66 3.3. Operational Measures . . . . . . . . . . . . . . . . . . . 9 67 3.3.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 10 68 3.3.2. A Single Border Router . . . . . . . . . . . . . . . . 10 69 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 IPv6-in-IPv4 tunnels are an essential part of many migration plans 81 for IPv6. They allow two IPv6 nodes to communicate over an IPv4-only 82 network. Automatic tunnels that use stateless address mapping 83 (hereafter called "automatic tunnels") are a category of tunnels in 84 which a tunneled packet's egress IPv4 address is embedded within the 85 destination IPv6 address of the packet. An automatic tunnel's router 86 is a router that respectively encapsulates and decapsulates the IPv6 87 packets into and out of the tunnel. 89 Ref. [USENIX09] pointed out the existence of a vulnerability in the 90 design of IPv6 automatic tunnels. Tunnel routers operate on the 91 implicit assumption that the destination address of an incoming IPv6 92 packet is always an address of a valid node that can be reached via 93 the tunnel. The assumption of path validity poses a denial of 94 service risk as inconsistency between the IPv4 routing state and the 95 IPv6 routing state allows a routing loop to be formed. 97 An attacker can exploit this vulnerability by crafting a packet which 98 is routed over a tunnel to a node that is not participating in that 99 tunnel. This node may forward the packet out of the tunnel to the 100 native IPv6 network. There the packet is routed back to the ingress 101 point that forwards it back into the tunnel. Consequently, the 102 packet loops in and out of the tunnel. The loop terminates only when 103 the Hop Limit field in the IPv6 header of the packet is decremented 104 to zero. This vulnerability can be abused as a vehicle for traffic 105 amplification to facilitate DoS attacks [RFC4732]. 107 Without compensating security measures in place, all IPv6 automatic 108 tunnels that are based on protocol-41 encapsulation [RFC4213] are 109 vulnerable to such an attack including ISATAP [RFC5214], 6to4 110 [RFC3056] and 6rd [RFC5569]. It should be noted that this document 111 does not consider non-protocol-41 encapsulation attacks. In 112 particular, we do not address the Teredo [RFC4380] attacks described 113 in [USENIX09]. These attacks are considered in 114 [I-D.gont-6man-teredo-loops]. 116 The aim of this document is to shed light on the routing loop attack 117 and describe possible mitigation measures that should be considered 118 by operators of current IPv6 automatic tunnels and by designers of 119 future ones. We note that tunnels may be deployed in various 120 operational environments, e.g. service provider network, enterprise 121 network, etc. Specific issues related to the attack which are 122 derived from the operational environment are not considered in this 123 document. 125 2. A Detailed Description of the Attack 127 In this section we shall denote an IPv6 address of a node reached via 128 a given tunnel by the prefix of the tunnel and an IPv4 address of the 129 tunnel end point, i.e., Addr(Prefix, IPv4). Note that the IPv4 130 address may or may not be part of the prefix (depending on the 131 specification of the tunnel's protocol). The IPv6 address may be 132 dependent on additional bits in the interface ID, however for our 133 discussion their exact value is not important. 135 The two victims of this attack are routers - R1 and R2 - of two 136 different tunnels - T1 and T2. Both routers have the capability to 137 forward IPv6 packets in and out of their respective tunnels. The two 138 tunnels need not be based on the same tunnel protocol. The only 139 condition is that the two tunnel protocols be based on protocol-41 140 encapsulation. The IPv4 address of R1 is IP1, while the prefix of 141 its tunnel is Prf1. IP2 and Prf2 are the respective values for R2. 142 We assume that IP1 and IP2 belong to the same address realm, i.e., 143 they are either both public, or both private and belong to the same 144 internal network. The following network diagram depicts the 145 locations of the two routers. 147 ####### 148 # R1 # 149 ####### 150 // \ 151 T1 // \ 152 interface // \ 153 _______________//_ __\________________ 154 | | | | 155 | IPv4 Network | | IPv6 Network | 156 |__________________| |___________________| 157 \\ / 158 \\ / 159 T2 \\ / 160 interface \\ / 161 ####### 162 # R2 # 163 ####### 165 Figure 1: The network setting of the attack 167 The attack is depicted in Figure 2. It is initiated by sending an 168 IPv6 packet (packet 0 in Figure 2) destined to a fictitious end point 169 that appears to be reached via T2 and has IP1 as its IPv4 address, 170 i.e., Addr(Prf2, IP1). The source address of the packet is a T1 171 address with Prf1 as the prefix and IP2 as the embedded IPv4 address, 172 i.e., Addr(Prf1, IP2). As the prefix of the destination address is 173 Prf2, the packet will be routed over the IPv6 network to T2. 175 We assume that R2 is the packet's entry point to T2. R2 receives the 176 packet through its IPv6 interface and forwards it over its T2 177 interface encapsulated with an IPv4 header having a destination 178 address derived from the IPv6 destination, i.e., IP1. The source 179 address is the address of R2, i.e., IP2. The packet (packet 1 in 180 Figure 2.) is routed over the IPv4 network to R1, which receives the 181 packet on its IPv4 interface. It processes the packet as a packet 182 that originates from one of the end nodes of T1. 184 Since the IPv4 source address corresponds to the IPv6 source address, 185 R1 will decapsulate the packet. Since the packet's IPv6 destination 186 is outside of T1, R1 will forward the packet onto a native IPv6 187 interface. The forwarded packet (packet 2 in Figure 2) is identical 188 to the original attack packet. Hence, it is routed back to R2, in 189 which the loop starts again. Note that the packet may not 190 necessarily be transported from R1 over native IPv6 network. R1 may 191 be connected to the IPv6 network through another tunnel. 193 R1 R2 194 | | 0 195 | 1 |<------ 196 |<===============| 197 | 2 | 198 |--------------->| 199 | . | 200 | . | 202 1 - IPv4: IP2 --> IP1 203 IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) 204 0,2- IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) 206 Legend: ====> - tunneled IPv6, ---> - native IPv6 208 Figure 2: Routing loop attack between two tunnels' routers 210 The crux of the attack is as follows. The attacker exploits the fact 211 that R2 does not know that R1 does not take part of T2 and that R1 212 does not know that R2 does not take part of T1. The IPv4 network 213 acts as a shared link layer for the two tunnels. Hence, the packet 214 is repeatedly forwarded by both routers. It is noted that the attack 215 will fail when the IPv4 network can not transport packets between the 216 tunnels. For example, when the two routers belong to different IPv4 217 address realms or when ingress/egress filtering is exercised between 218 the routes. 220 The loop will stop when the Hop Limit field of the packet reaches 221 zero. After a single loop the Hop Limit field is decreased by the 222 number of IPv6 routers on path from R1 and R2. Therefore, the number 223 of loops is inversely proportional to the number of IPv6 hops between 224 R1 and R2. 226 The tunnel pair T1 and T2 may be any combination of automatic tunnel 227 types, e.g., ISATAP, 6to4 and 6rd. This has the exception that both 228 tunnels can not be of type 6to4, since two 6to4 routers can not 229 belong to different tunnels (there is only one 6to4 tunnel in the 230 Internet). For example, if the attack were to be launched on an 231 ISATAP router (R1) and 6to4 relay (R2), then the destination and 232 source addresses of the attack packet would be 2002:IP1:* and Prf1:: 233 0200:5EFE:IP2, respectively. 235 3. Proposed Mitigation Measures 237 This section presents some possible mitigation measures for the 238 attack described above. For each measure we shall discuss its 239 advantages and disadvantages. 241 The proposed measures fall under the following three categories: 243 o Destination and source addresses checks 245 o Verification of end point existence 247 o Operational measures 249 3.1. Destination and Source Address Checks 251 Tunnel routers can use a source address check mitigation when they 252 forward an IPv6 packet into a tunnel interface with an IPv6 source 253 address that embeds one of the router's configured IPv4 addresses. 254 Similarly, tunnel routers can use a destination address check 255 mitigation when they receive an IPv6 packet on a tunnel interface 256 with an IPv6 destination address that embeds one of the router's 257 configured IPv4 addresses. These checks should correspond to both 258 tunnels' IPv6 address formats, regardless of the type of tunnel the 259 router employs. 261 For example, if tunnel router R1 (of any tunnel protocol) forwards a 262 packet into a tunnel interface with an IPv6 source address that 263 matches the 6to4 prefix 2002:IP1::/48, the router discards the packet 264 if IP1 is one of its own IPv4 addresses. In a second example, if 265 tunnel router R2 receives an IPv6 packet on a tunnel interface with 266 an IPv6 destination address with an off-link prefix but with an 267 interface identifier that matches the ISATAP address suffix ::0200: 268 5EFE:IP2, the router discards the packet if IP2 is one of its own 269 IPv4 addresses. 271 Hence a tunnel router can avoid the attack by performing the 272 following checks: 274 o When the router forwards an IPv6 packet into a tunnel interface, 275 it discards the packet if the IPv6 source address has an off-link 276 prefix but embeds one of the router's configured IPv4 addresses. 278 o When the router receives an IPv6 packet on a tunnel interface, it 279 discards the packet if the IPv6 destination address has an off- 280 link prefix but embeds one of the router's configured IPv4 281 addresses. 283 This approach has the advantage that that no ancillary state is 284 required, since checking is through static lookup in the lists of 285 IPv4 and IPv6 addresses belonging to the router. However, this 286 approach has some inherent limitations 288 o The checks incur an overhead which is proportional to the number 289 of IPv4 addresses assigned to the router. If a router is assigned 290 many addresses, the additional processing overhead for each packet 291 may be considerable. Note that an unmitigated attack packet would 292 be repetitively processed by the router until the Hop Limit 293 expires, which may require as many as 255 iterations. Hence, an 294 unmitigated attack will consume far more aggregate processing 295 overhead than per-packet address checks even if the router assigns 296 a large number of addresses. 298 o The checks should be performed for the IPv6 address formats of 299 every existing automatic IPv6 tunnel protocol (which uses 300 protocol-41 encapsulation). Hence, the checks must be updated as 301 new protocols are defined. 303 o Before the checks can be performed the format of the address must 304 be recognized. There is no guarantee that this can be generally 305 done. For example, one can not determine if an IPv6 address is a 306 6rd one, hence the router would need to be configured with a list 307 of all applicable 6rd prefixes (which may be prohibitively large) 308 in order to unambiguously apply the checks. 310 o The checks cannot be performed if the embedded IPv4 address is a 311 private one [RFC1918] since it is ambiguous in scope. Namely, the 312 private address may be legitimately allocated to another node in 313 another routing region. 315 The last limitation may be relieved if the router has some 316 information that allows it to unambiguously determine the scope of 317 the address. The check in the following subsection is one example 318 for this. 320 3.1.1. Known IPv6 Prefix Check 322 A router may be configured with the full list of IPv6 subnet prefixes 323 assigned to the tunnels attached to its current IPv4 routing region. 324 In such a case it can use the list to determine when static 325 destination and source address checks are possible. By keeping track 326 of the list of IPv6 prefixes assigned to the tunnels in the IPv4 327 routing region, a router can perform the following checks on an 328 address which embeds a private IPv4 address: 330 o When the router forwards an IPv6 packet into its tunnel with a 331 source address that embeds a private IPv4 address and matches an 332 IPv6 prefix in the prefix list, it determines whether the packet 333 should be discarded or forwarded by performing the source address 334 check specified in Section 3.1. Otherwise, the router forwards 335 the packet. 337 o When the router receives an IPv6 packet on its tunnel interface 338 with a destination address that embeds a private IPv4 address and 339 matches an IPv6 prefix in the prefix list, it determines whether 340 the packet should be discarded or forwarded by performing the 341 destination address check specified in Section 3.1. Otherwise, 342 the router forwards the packet. 344 The disadvantage of this approach is the administrative overhead for 345 maintaining the list of IPv6 subnet prefixes associated with an IPv4 346 routing region may become unwieldy should that list be long and/or 347 frequently updated. 349 3.2. Verification of end point existence 351 The routing loop attack relies on the fact that a router does not 352 know whether there is an end point that can reached via its tunnel 353 that has the source or destination address of the packet. This 354 category includes mitigation measures which aim to verify that there 355 is a node which participate in the tunnel and its address corresponds 356 to the packet's destination or source addresses, as appropriate. 358 3.2.1. Neighbor Cache Check 360 One way that the router can verify that an end host exists and can be 361 reached via the tunnel is by checking whether a valid entry exists 362 for it in the neighbor cache of the corresponding tunnel interface. 364 The neighbor cache entry can be populated through, e.g., an initial 365 reachability check, receipt of neighbor discovery messages, 366 administrative configuration, etc. 368 When the router has a packet to send to a potential tunnel host for 369 which there is no neighbor cache entry, it can perform an initial 370 reachability check on the packet's destination address, e.g., as 371 specified in the second paragraph of Section 8.4 of [RFC5214]. (The 372 router can similarly perform a "reverse reachability" check on the 373 packet's source address when it receives a packet from a potential 374 tunnel host for which there is no neighbor cache entry.) This 375 reachability check parallels the address resolution specifications in 376 Section 7.2 of [RFC4861], i.e., the router maintains a small queue of 377 packets waiting for reachability confirmation to complete. If 378 confirmation succeeds, the router discovers that a legitimate tunnel 379 host responds to the address. Otherwise, the router discards 380 subseqent packets and returns ICMP destination unreachable 381 indications as specified in Section 7.2.2 of [RFC4861]. 383 Note that this approach assumes that the neighbor cache will remain 384 coherent and not subject to malicious attack, which must be confirmed 385 based on specific deployment scenarios. One possible way for an 386 attacker to subvert the neighbor cache is to send false neighbor 387 discovery messages with a spoofed source address. 389 3.2.2. Known IPv4 Address Check 391 Another approach that enables a router to verify that an end host 392 exists and can be reached via the tunnel is simply by pre-configuring 393 the router with the set of IPv4 addresses that are authorized to use 394 the tunnel. Upon this configuration the router can perform the 395 following simple checks: 397 o When the router forwards an IPv6 packet into the tunnel interface 398 with a destination address that matches an on-link prefix and that 399 embeds the IPv4 address IP1, it discards the packet if IP1 does 400 not belong to the configured list of IPv4 addresses. 402 o When the router receives an IPv6 packet on the tunnel's interface 403 with a source address that matches a on-link prefix and that 404 embeds the IPv4 address IP2, it discards the packet if IP2 does 405 not belong to the configured list of IPv4 addresses. 407 3.3. Operational Measures 409 The following measures can be taken by the network operator. Their 410 aim is to configure the network in such a way that the attacks can 411 not take place. 413 3.3.1. Avoiding a Shared IPv4 Link 415 As noted above, the attack relies on having an IPv4 network as a 416 shared link-layer between more than one tunnel. From this the 417 following two mitigation measures arise: 419 3.3.1.1. Filtering IPv4 Protocol-41 Packets 421 In this measure a tunnel router may drop all IPv4 protocol-41 packets 422 received or sent over interfaces that are attached to an untrusted 423 IPv4 network. This will cut-off any IPv4 network as a shared link. 424 This measure has the advantage of simplicity. However, such a 425 measure may not always be suitable for scenarios where IPv4 426 connectivity is essential on all interfaces. 428 3.3.1.2. Operational Avoidance of Multiple Tunnels 430 This measure mitigates the attack by simply allowing for a single 431 IPv6 tunnel to operate in a bounded IPv4 network. For example, the 432 attack can not take place in broadband home networks. In such cases 433 there is a small home network having a single residential gateway 434 which serves as a tunnel router. A tunnel router is vulnerable to 435 the attack only if it has at least two interfaces with a path to the 436 Internet: a tunnel interface and a native IPv6 interface (as depicted 437 in Figure 1). However, a residential gateway usually has only a 438 single interface to the Internet, therefore the attack can not take 439 place. Moreover, if there are only one or a few tunnel routers in 440 the IPv4 network and all participate in the same tunnel then there is 441 no opportunity for perpetuating the loop. 443 This approach has the advantage that it avoids the attack profile 444 altogether without need for explicit mitigations. However, it 445 requires careful configuration management which may not be tenable in 446 large and/or unbounded IPv4 networks. 448 3.3.2. A Single Border Router 450 It is reasonable to assume that a tunnel router shall accept or 451 forward tunneled packets only over its tunnel interface. It is also 452 reasonable to assume that a tunnel router shall accept or forward 453 IPv6 packets only over its IPv6 interface. If these two interfaces 454 are physically different then the network operator can mitigate the 455 attack by ensuring that the following condition holds: there is no 456 path between these two interfaces that does not go through the tunnel 457 router. 459 The above condition ensures that an encapsulated packet which is 460 transmitted over the tunnel interface will not get to another tunnel 461 router and from there to the IPv6 interface of the first router. The 462 condition also ensures the reverse direction, i.e., an IPv6 packet 463 which is transmitted over the IPv6 interface will not get to another 464 tunnel router and from there to the tunnel interface of the first 465 router. This condition is essentially translated to a scenario in 466 which the tunnel router is the only border router between the IPv6 467 network and the IPv4 network to which it is attached (as in broadband 468 home network scenario mentioned above). 470 4. Recommendations 472 In light of the mitigation measures proposed above we make the 473 following recommendations in decreasing order: 475 1. When possible, it is recommended that the attacks are 476 operationally eliminated (as per one of the measures proposed in 477 Section 3.3). 479 2. For tunnel routers that keep a coherent and trusted neighbor 480 cache which includes all legitimate end-points of the tunnel, we 481 recommend exercising the Neighbor Cache Check. 483 3. For tunnel routers that can implement the Neighbor Reachability 484 Check, we recommend exercising it. 486 4. For tunnels having small and static list of end-points we 487 recommend exercising Known IPv4 Address Check. 489 5. For all other cases we recommend the Destination and Source 490 Address Checks. This is the least preferable measure since it 491 generally can not mitigate routing loops with 6rd routers. 493 As noted earlier, tunnels may be deployed in various operational 494 environments. There is a possibility that other mitigations may be 495 feasible in specific deployment scenarios. The above recommendations 496 are general and do not attempt to cover such scenarios. 498 5. IANA Considerations 500 This document has no IANA considerations. 502 6. Security Considerations 504 This document aims at presenting possible solutions to the routing 505 loop attack which involves automatic tunnels' routers. It contains 506 various checks that aim to recognize and drop specific packets that 507 have strong potential to cause a routing loop. These checks do not 508 introduce new security threats. 510 7. Acknowledgments 512 This work has benefited from discussions on the V6OPS, 6MAN and 513 SECDIR mailing lists. Remi Despres, Christian Huitema, Dmitry 514 Anipko, Dave Thaler and Fernando Gont are acknowledged for their 515 contributions. 517 8. References 519 8.1. Normative References 521 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 522 E. Lear, "Address Allocation for Private Internets", 523 BCP 5, RFC 1918, February 1996. 525 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 526 via IPv4 Clouds", RFC 3056, February 2001. 528 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 529 for IPv6 Hosts and Routers", RFC 4213, October 2005. 531 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 532 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 533 September 2007. 535 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 536 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 537 March 2008. 539 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 540 Infrastructures (6rd)", RFC 5569, January 2010. 542 8.2. Informative References 544 [I-D.gont-6man-teredo-loops] 545 Gont, F., "Mitigating Teredo Rooting Loop Attacks", 546 draft-gont-6man-teredo-loops-00 (work in progress), 547 September 2010. 549 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 550 Network Address Translations (NATs)", RFC 4380, 551 February 2006. 553 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 554 Service Considerations", RFC 4732, December 2006. 556 [USENIX09] 557 Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 558 Tunnels", USENIX WOOT, August 2009. 560 Authors' Addresses 562 Gabi Nakibly 563 National EW Research & Simulation Center 564 P.O. Box 2250 (630) 565 Haifa 31021 566 Israel 568 Email: gnakibly@yahoo.com 570 Fred L. Templin 571 Boeing Research & Technology 572 P.O. Box 3707 MC 7L-49 573 Seattle, WA 98124 574 USA 576 Email: fltemplin@acm.org