| TOC |
|
This document is concerned with security vulnerabilities in the ISATAP and 6to4 tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between a tunnel's overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. We describe these security vulnerabilities and the attacks which exploit them. We further recommend on solutions to remove the vulnerabilities.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 5, 2010.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
1.
Introduction
2.
Detailed Descriptions of the Attacks
2.1.
Attack #1: 6to4 Relay to ISATAP Router
2.2.
Attack #2: ISATAP Router to 6to4 Relay
2.3.
Attack #3: ISATAP Router to ISATAP Router
3.
Recommended Solutions
3.1.
Destination and Source Address Check
3.1.1.
Known IPv6 Prefix Check
3.2.
Neighbor Cache Check
3.3.
Known IPv4 Address Check
4.
IANA Considerations
5.
Security Considerations
6.
Acknowledgments
7.
References
7.1.
Normative References
7.2.
Informative References
§
Authors' Addresses
| TOC |
Recent research [USENIX09] (Nakibly, G. and M. Arov, “Routing Loop Attacks using IPv6 Tunnels,” USENIX WOOT, August 2009.) has pointed out the existence of some security vulnerabilities in the design of the automatic tunnels ISATAP [RFC5214] (Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP),” March 2008.) and 6to4 [RFC3056] (Carpenter, B. and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds,” February 2001.). These vulnerabilities allow a specially crafted packet to loop back and forth between ISATAP routers or 6to4 relays thereby overloading them.
In automatic tunnels a packet's egress node's IPv4 address is computationally derived from the destination IPv6 address of the packet. This feature eliminates the need to keep an explicit routing table at the tunnel's end points. In particular, the end points do not have to be updated as peers join and leave the tunnel. In fact, the end points of an automatic tunnel do not know which other end points are currently part of the tunnel. However, all end points operate on the implicit assumption that once a packet arrives at the tunnel, its destination indeed is part of the tunnel. This assumption poses a security vulnerability since it may result in an inconsistency between a tunnel's overlay IPv6 routing state and the native IPv6 routing state there by allowing a routing loop to be formed.
An attacker can exploit this vulnerability by crafting a packet which is routed over a tunnel to a node that is not participating in that tunnel. This node may forward the packet out of the tunnel to a native IPv6 network. In that network, the packet is routed back to the ingress point that forwards it back into the tunnel. Consequently, the packet will loop in and out of the tunnel.
A loop terminates only when the Hop Limit field in the IPv6 header of the packet is zeroed out. The maximum value that can be assigned to this field is 255. Note that when the packet is tunneled over IPv4 routers, the Hop Limit does not decrease. Every attack packet will traverse each hop along the loop 255/N times, where N is the number of IPv6 routers on the loop. As a result, the loops can be used as traffic amplification tools with a ratio of 255/N. The number of IPv6 routers on the loop is determined by the positions of the two victims. The closer the two victims are, the larger the amplification ratio will be.
| TOC |
For the sake of completeness, this section details the three attacks from [USENIX09] (Nakibly, G. and M. Arov, “Routing Loop Attacks using IPv6 Tunnels,” USENIX WOOT, August 2009.) that exemplify how the security vulnerability described above may be exploited.
| TOC |
The two victims of this attack are a 6to4 relay and an ISATAP router. Let IPa and IPb denote the IPv4 address of the ISATAP router and the 6to4 relay, respectively. Let Prfa denote the IPv6 64-bit prefix of the ISATAP tunnel. The attack is depicted in Figure Figure 1 (Attack #1: 6to4 Relay to ISATAP Router). It is initiated by sending an IPv6 packet (packet 0 in Figure Figure 1 (Attack #1: 6to4 Relay to ISATAP Router)) to a 6to4 destination address with an embedded router address of IPa, i.e., the destination address begins with 2002:IPa::/48. The source address of the packet is an ISATAP address with Prfa as the prefix and IPb as the embedded IPv4 address. As the destination address is 6to4, the packet will be routed over the IPv6 network to the closest 6to4 relay. The relay receives the packet through its IPv6 interface and processes it as a normal IPv6 packet that needs to be delivered to the appropriate 6to4 site. Hence, the packet is forwarded over the relay's IPv4 interface with an IPv4 header having a destination address derived from the IPv6 destination, i.e., IPa. The source address is the address of the 6to4 relay, IPb. The packet (packet 1 in Figure Figure 1 (Attack #1: 6to4 Relay to ISATAP Router).) is routed over the IPv4 network to the ISATAP router. The router receives the packet on its IPv4 interface. It processes the packet as a regular IPv4 packet that originates from one of the end points of the ISATAP tunnel. Since the IPv4 source address corresponds to the IPv6 source address, the packet will be decapsulated. Since the packet's IPv6 destination is outside the ISATAP tunnel, the packet will be forwarded onto the native IPv6 interface. The forwarded packet (packet 2 in Figure Figure 1 (Attack #1: 6to4 Relay to ISATAP Router).) is identical to the original attack packet. Hence, it will be routed back to the closest 6to4 relay, in which the loop will start again.
ISATAP Router 6to4 Relay
(IPa) (IPb)
| | 0
| 1 |<------
|<===============|
| 2 |
|--------------->|
| . |
| . |
1 - IPv4: IPb --> IPa
IPv6: Prfa::0200:5EFE:IPb --> 2002:IPa:*
0,2- IPv6: Prfa::0200:5EFE:IPb --> 2002:IPa:*
Legend: ====> - tunneled IPv6, ---> - native IPv6
| Figure 1: Attack #1: 6to4 Relay to ISATAP Router |
| TOC |
The two victims in this attack are again a 6to4 relay and an ISATAP router, but here they have swapped roles. This time the ISATAP router accepts the attack packet and forwards it on its ISATAP tunnel to the 6to4 relay, which decapsulates it and forwards it back to the ISATAP router on the IPv6 network. Let IPa, IPa and Prfa be the same as above. The attack is depicted in Figure Figure 2 (Attack #2: ISATAP Router to 6to4 Relay). This attack is initiated by sending an IPv6 packet (packet 0 in Figure Figure 2 (Attack #2: ISATAP Router to 6to4 Relay)) with a destination ISATAP address having Prfa as the prefix and IPb as the embedded IPv4 address. The source address of the packet is a 6to4 address with a router having the IPa address , i.e., the destination address begins with 2002:IPa::/48. The packet will be routed over the IPv6 network to the ISATAP router. The router receives the packet through its IPv6 interface and processes it as a normal IPv6 packet that needs to be delivered to the appropriate end point in the ISATAP tunnel. Hence, the packet is forwarded over the router's IPv4 interface with an IPv4 encapsulation having a destination address derived from the IPv6 destination , i.e., IPb. The source address is the address of the ISATAP router, IPa. The packet (packet 1 in Figure Figure 2 (Attack #2: ISATAP Router to 6to4 Relay)) is routed over the IPv4 network to the 6to4 relay. The relay receives the packet on its IPv4 interface. It processes the packet as a normal IPv4 packet that originates from one of the end points of the 6to4 tunnel. Since the IPv4 source address corresponds to the IPv6 source address, the packet will be admitted and decapsulated. Since the packet's IPv6 destination is outside the 6to4 tunnel, the packet will be forwarded out on the native IPv6 interface. The forwarded packet (packet 2 in Figure Figure 2 (Attack #2: ISATAP Router to 6to4 Relay)) is identical to the original attack packet. Hence, it will be routed back to the ISATAP router, in which the loop will start again.
ISATAP Router 6to4 Relay
(IPa) (IPb)
0 | |
----->| 1 |
|===============>|
| 2 |
|<---------------|
| . |
| . |
1 - IPv4: IPa --> IPb
IPv6: 2002:IPa:* --> Prfa::0200:5EFE:IPb
0,2- IPv6: 2002:IPa:* --> Prfa::0200:5EFE:IPb
Legend: ====> - tunneled IPv6, ---> - native IPv6
| Figure 2: Attack #2: ISATAP Router to 6to4 Relay |
| TOC |
The two victims in this attack are two ISATAP routers -- router A and router B -- having addresses IPa and IPb, respectively. Let Prfa and Prfb be the prefixes of the ISATAP tunnels of router A and router B, respectively. Note that the two routers do not participate in the same ISATAP tunnel. However, they may reside at the same or different sites. The attack is depicted in Figure Figure 3 (Attack #3: ISATAP Router to ISATAP Router). It is initiated by sending an IPv6 packet (packet 0 in Figure Figure 3 (Attack #3: ISATAP Router to ISATAP Router)) with a destination ISATAP address having Prfa as the prefix and IPb as the embedded IPv4 address. The source address of the packet is an ISATAP address having Prfb as the prefix and IPa as the embedded IPv4 address. The packet will be routed over the IPv6 network to router A. The router receives the packet through its IPv6 interface and processes it as a normal IPv6 packet that needs to be delivered to the appropriate end point of its ISATAP tunnel. The fact that the source address is also an ISATAP address does not matter here; the important thing is that the packet originated outside of the tunnel A. Hence, the packet is forwarded over the router's IPv4 interface with an IPv4 encapsulation having a destination address derived from the IPv6 destination , i.e., IPb. The source address is the address of the router A, IPa. The packet (marked with 1 in Figure Figure 3 (Attack #3: ISATAP Router to ISATAP Router)) is routed over the IPv4 network to router B. The router receives the packet on its IPv4 interface. It processes the packet as a regular IPv4 packet that originates from one of the end points of its tunnel. Since the IPv4 source address corresponds to the IPv6 source address, the packet will be decapsulated. The packet's IPv6 destination is outside of router B's tunnel; hence the packet is forwarded out onto the IPv6 interface. The forwarded packet (packet 2 in Figure Figure 3 (Attack #3: ISATAP Router to ISATAP Router)) is identical to the original attack packet. Hence, it will be routed back to router A, in which the loop will start again.
The attack can also be launched on two ISATAP routers having private IPv4 addresses in th same IPv4 routing region.
ISATAP Router ISATAP Router
(IPa) (IPb)
0 | |
----->| 1 |
|===============>|
| 2 |
|<---------------|
| . |
| . |
1 - IPv4: IPa --> IPb
IPv6: Prfb::0200:5EFE:IPa --> Prfa::0200:5EFE:IPb
0,2- IPv6: Prfb::0200:5EFE:IPa --> Prfa::0200:5EFE:IPb
Legend: ====> - tunneled IPv6, ---> - native IPv6
| Figure 3: Attack #3: ISATAP Router to ISATAP Router |
| TOC |
This section describes the recommended solutions that mitigate the attacks above. For each solution we shall discuss its advantages and disadvantages.
| TOC |
Tunnel routers can use a source address check mitigation when they forward an IPv6 packet into a tunnel interface with an IPv6 source address that embeds one of the router's configured IPv4 addresses. Similarly, tunnel routers can use a destination address check mitigation when they receive an IPv6 packet on a tunnel interface with an IPv6 destination address that embeds one of the router's configured IPv4 addresses. These checks should correspond to both tunnels' IPv6 address formats, regardless of the type of tunnel the router employs.
For example, if tunnel router A (ISATAP router or 6to4 relay) forwards a packet into a tunnel interface with an IPv6 source address that matches the 6to4 prefix 2002:IPa::/48, the router discards the packet if IPa is one of its own IPv4 addresses. In a second example, if tunnel router B (ISATAP router or 6to4 relay) receives an IPv6 packet on a tunnel interface with an IPv6 destination address that matches the ISATAP address suffix ::0200:5EFE:IPb, the router discards the packet if IPb is one of its own IPv4 addresses. In both of these examples, the router can unambiguously check the addresses IPa and IPb since both are known to be public IPv4 addresses by definition of the 6to4 and ISATAP address formats. However, the router cannot perform the simple check if the embedded IPv4 address is a private one [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) since it is ambiguous in scope. This reservation is relevant only to attacks of type #3 (a loop between two ISATAP routers) since the other two types of attack involves a 6to4 tunnel which always embeds public IPv4 addresses.
When a tunnel router (ISATAP, 6to4) has a way of knowing whether an embedded IPv4 address is one of its own addresses, it can avoid the routing loop attack scenarios depicted in Figures 1, 2 and 3 by performing the following simple checks:
This approach can be employed by an ISATAP router or 6to4 relay. As noted above the router must perform the embedded IPv4 address inspections for both ISATAP and 6to4 IPv6 address formats even if the router does not implement one of those tunnels. This approach has the advantage that it is easy to implement and that no ancillary state is required, since checking is through static lookup in the lists of IPv4 and IPv6 addresses belonging to the router.
As noted above, this simple approach alone cannot be used when the embedded IPv4 address in the ISATAP address is private, because the address may be legitimately allocated to another node in another routing region. To apply this check the router must first unambiguously determine the scope of the address. The following check serves this purpose.
| TOC |
The known IPv6 prefix check is tied to the conceptual ISATAP link model. It observes that an ISATAP link spans a portion of a connected IPv4 routing region up to (but not beyond) the entire connected IPv4 routing region itself. For example, if there were no physical or logical segmentations (e.g., enterprise network border gateways) the entire public IPv4 Internet would be spanned by a single ISATAP link. Similarly, a private IPv4 address routing region can be spanned by one or more ISATAP links that are distinct from the links that span other private IPv4 routing regions.
Each IPv4 routing region can be segmented through logical or physical segmentation, e.g., through ip-proto-41 filters, firewalls, etc. In that case, each distinct segment is spanned by a distinct ISATAP link. As for any links, multiple distinct ISATAP links can be joined together by bridges or IPv6 routers.
Each ISATAP link configures a set of IPv6 subnet prefixes, where each subnet prefix spans either the entire link or only a portion of the link. Therefore, if the router can determine the full list of IPv6 subnet prefixes assigned to ISATAP interfaces attached to the link, it can use the list to determine when static destination and source address checks are necessary. By keeping track of the list of IPv6 prefixes assigned to ISATAP interfaces connected to the link, an ISATAP router can perform the following checks on an ISATAP address which embeds a private IPv4 address:
The disadvantage of this approach is the administrative overhead for maintaining the list of IPv6 subnet prefixes associated with an ISATAP link may become unwieldy should that list be long and/or frequently updated.
| TOC |
The neighbor cache check mitigation observes that the routing loop attack scenarios depicted in Figures 1, 2 and 3 specifically target the ISATAP IPv6 on-link subnet model. In this approach, hosts configure IPv6 addresses and assign IPv6 subnet prefixes on an ISATAP interface based on the Prefix Information Options included in the unicast Router Advertisement (RA) messages they receive from routers. Moreover, ISATAP hosts must first send Router Solicitation (RS) messages to routers in order to elicit these RAs since the ISATAP link model is Non-Broadcast, Multiple Access (NBMA). Therefore, ISATAP routers can keep track of the hosts from which they have recently received RS messages by maintaining entries in their ISATAP interface neighbor cache that are keyed on the IPv6 unicast link-local source addresses received in the RS messages. The ISATAP router can then determine which hosts are willing participants in the ISATAP IPv6 on-link subnets.
By keeping track of the hosts that have recently sent RS messages, an ISATAP router can perform the following simple checks:
This approach can only be employed by an ISATAP router. It has the advantage that the ISATAP router discards only those IPv6 packets that could cause the looping conditions, i.e., those packets with source and/or destination addresses taken from an ISATAP IPv6 on-link subnet prefix but for which no corresponding neighbor cache entry exists. In contrast, other approaches could in some cases discard IPv6 packets that pertain to legitimate communications. The approach is also easy to implement, and naturally leverages the relationship between the router's advertised prefix lifetimes and the interval between the host's successive RS transmissions according to the specifications in [RFC5214] (Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP),” March 2008.).
This approach requires the ISATAP router to maintain a neighbor cache with entries created or updated by the reception of ISATAP host RS messages. These entries must be retained for a duration that is at least as long as the router's advertised prefix lifetimes, i.e., even if the entries transition into the STALE state. This may require an implementation to adjust its garbage-collection interval for stale neighbor cache entries. The approach further requires that hosts perform the RS/RA exchanges specified in Section 8.3.4 of [RFC5214] (Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP),” March 2008.), i.e., the host-initiated RS/RA exchanges must be performed. Finally, this approach assumes that the neighbor cache will remain coherent and not subject to malicious attack, which must be confirmed based on specific deployment scenarios. One possible way for an attacker to subvert the neighbor cache is to send false RS messages with a spoofed source address.
| TOC |
The known IPv4 address check method observes that each on-link IPv6 subnet prefix on an ISATAP interface is configured over a limited set of IPv4 addresses, since each ISATAP Potential Router List will be used only by a finite set of hosts. Therefore, only those hosts configured from a subset of the IPv4 addresses in an IPv4 routing region are authorized to configure IPv6 addresses and subnet prefixes advertised by a given ISATAP router. By keeping track of the set of IPv4 addresses that are authorized to use an ISATAP on-link IPv6 subnet, an ISATAP router can perform the following simple checks:
This approach can only be employed by an ISATAP router, and offers a close analogy to the neighbor cache check discussed in Section 3.2. Indeed, one possible interpretation of this approach is that the router should simply cache the IPv4 addresses of hosts that have sent it an RS message. In this interpretation, the only difference between this approach and the neighbor cache check discussed in Section 3.2 is the nature of the internal data structure used to store the IPv4 addresses, which is likely to be an implementation detail. Therefore, the same set of advantages and disadvantages as described in Section 3.2 apply.
Alternatively, the ISATAP router could pre-configure a static list of known IPv4 host addresses. This list would be discovered through some unspecified means (e.g., manual configuration), and would serve as a "Potential Host List (PHL)" for the ISATAP interface.
| TOC |
This document has no IANA considerations.
| TOC |
This document aims at mitigating routing loops which involves ISATAP routers and 6to4 relays. It contains various checks that aim to recognize and drop specific packets that have strong potential to cause a routing loop. These checks does not introduce new security threats.
| TOC |
This work has benefited from discussions on the V6OPS, 6MAN and SECDIR mailing lists. Remi Despres and Christian Huitema are acknowledged for their contributions.
| TOC |
| TOC |
| [RFC1918] | Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” BCP 5, RFC 1918, February 1996 (TXT). |
| [RFC3056] | Carpenter, B. and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds,” RFC 3056, February 2001 (TXT). |
| [RFC5214] | Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP),” RFC 5214, March 2008 (TXT). |
| TOC |
| [USENIX09] | Nakibly, G. and M. Arov, “Routing Loop Attacks using IPv6 Tunnels,” USENIX WOOT, August 2009. |
| TOC |
| Gabi Nakibly | |
| National EW Research & Simulation Center | |
| P.O. Box 2250 (630) | |
| Haifa 31021 | |
| Israel | |
| Email: | gnakibly@yahoo.com |
| Fred L. Templin (editor) | |
| Boeing Research & Technology | |
| P.O. Box 3707 MC 7L-49 | |
| Seattle, WA 98124 | |
| USA | |
| Email: | fltemplin@acm.org |