RFC 6324
Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations
RFC 6324: Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations ✨
Okay bestie, here's the header info 🎀 This RFC comes from the IETF (Internet Engineering Task Force). G. Nakibly (NEWRSC) and F. Templin (Boeing Research & Technology) wrote it. It's Informational, which means it's published for information and is not a Standards Track spec 📚 It was published in August 2011, and its ISSN is 2070-1721. This header doesn't list anything it obsoletes or updates 💅
Abstract 🌸
Okay so this doc is about security holes in IPv6-in-IPv4 automatic tunnels 🚨 These holes let an attacker exploit mismatches between the IPv4 routing state and the IPv6 routing state. The attack creates a routing loop, and that loop can get used as a traffic amplifier for denial-of-service (DoS) attacks 💀 The doc has two goals: first, explain the attack and its root causes, and second, suggest some possible mitigations. At the time of writing, there are no known reports of malicious attacks using these holes. Still, these vulnerabilities can get triggered by accidental misconfiguration 🙈
Status of This Memo 📜
This document is not an Internet Standards Track specification. It's published for informational purposes 🦋
This document is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for more on that 🫶
For info on the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6324 ✨
Copyright Notice 💜
Copyright (c) 2011 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 publication date. Please read these carefully, because they explain your rights and restrictions for this document 👀 Code components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License 🎀
Table of Contents 📚
1. Introduction ....................................................2
2. A Detailed Description of the Attack ............................4
3. Proposed Mitigation Measures ....................................6
3.1. Verification of Endpoint Existence .........................6
3.1.1. Neighbor Cache Check ................................6
3.1.2. Known IPv4 Address Check ............................7
3.2. Operational Measures .......................................7
3.2.1. Avoiding a Shared IPv4 Link .........................7
3.2.2. A Single Border Router ..............................8
3.2.3. A Comprehensive List of Tunnel Routers ..............9
3.2.4. Avoidance of On-Link Prefixes .......................9
3.3. Destination and Source Address Checks .....................15
3.3.1. Known IPv6 Prefix Check ............................16
4. Recommendations ................................................17
5. Security Considerations ........................................17
6. Acknowledgments ................................................18
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................191. Introduction 🦋
Okay, IPv6-in-IPv4 tunnels are a huge part of a lot of IPv6 migration plans 🧚 They let two IPv6 nodes talk to each other over a network that only speaks IPv4. Automatic tunnels are a category where the packet's egress IPv4 address is embedded inside its destination IPv6 address. They use stateless address mapping to assign IPv6 prefixes, which is so clever 😭 An automatic tunnel's router is the router that encapsulates IPv6 packets going into the tunnel and decapsulates them coming out.
Reference [USENIX09] pointed out a vulnerability in how IPv6 automatic tunnels are designed 🙈 Tunnel routers quietly assume that the destination address of any incoming IPv6 packet belongs to a valid node that can be reached through the tunnel. That assumption about path validity can create routing loops, since the mismatch between the IPv4 routing state and the IPv6 routing state lets a loop form. Those loops won't trap normal data, but they will catch traffic aimed at addresses that have become unavailable, and misconfigured traffic can end up in the loop too 💅
The looping bug can get triggered by accident, or an attacker can exploit it on purpose by crafting a packet that gets routed through a tunnel to a node that doesn't match the packet's destination 👀 That node may forward the packet out of the tunnel onto the native IPv6 network. From there, the packet gets routed back to the ingress point, which sends it right back into the tunnel. So the packet loops in and out of the tunnel over and over. The loop only stops when the Hop Limit field in the packet's IPv6 header gets decremented to zero ⏳ This bug can be abused as a traffic amplifier to make DoS attacks worse [RFC4732] 💀
Unless there are compensating security measures in place, every IPv6 automatic tunnel based on protocol-41 encapsulation [RFC4213] is vulnerable to this attack 🚨 That includes the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], 6to4 [RFC3056], and 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures) [RFC5969]. Note that this document doesn't cover non-protocol-41 encapsulation attacks. In particular, it doesn't address the Teredo [RFC4380] attacks described in [USENIX09]. Those are covered in [TEREDO-LOOPS] instead 🌸
The goal of this document is to shed light on the routing loop attack and describe possible mitigations. Operators of current IPv6 automatic tunnels should consider them, and so should designers of future ones 🎀 Tunnels can be deployed in different operational environments, like service provider networks or enterprise networks, for example. This document doesn't look at issues specific to the attack that come from the operational environment 🧠
Routing loops are a risk to network stability 😬 They also open the door to denial-of-service attacks, which exploit the loop to pile extra traffic onto the network. Section 3 of this document covers a bunch of mitigation measures. The most desirable mitigation, though, is operating the network so that routing loops can't happen in the first place (see Section 3.2) 👑
2. A Detailed Description of the Attack ✨
okay so bestie, first we need a shorthand 🎀 for an IPv6 address of a node: we write it as Addr(Prefix, IPv4), where the Prefix is the IPv6 prefix assigned to the tunnel and the IPv4 is the IPv4 address of the tunnel endpoint. the IPv4 address might or might not be part of the prefix, depending on the tunnel's protocol spec. the IPv6 address can also depend on extra bits in the interface ID, but for this story those bits don't matter 🦋
the two victims are routers, R1 and R2 🌸 they each serve a different tunnel prefix (Prf1 and Prf2), and both can forward IPv6 packets in and out of their tunnels. the two tunnels don't have to use the same tunnel protocol, the only requirement is that both are based on protocol-41 encapsulation 💅. R1's IPv4 address is IP1 and its tunnel prefix is Prf1. R2 has IP2 and Prf2. we assume IP1 and IP2 are in the same address realm, so they're either both public, or both private and inside the same internal network 🫶 the diagram below shows where the two routers sit. the numbers mark the packets of the attack and the path each one takes 🍓
[ Packet 1 ]
v6src = Addr(Prf1, IP2) [ Packet 2 ]
v6dst = Addr(Prf2, IP1) v6src = Addr(Prf1, IP2)
v4src = IP2; v4dst = IP1 +----------+ v6dst = Addr(Prf2, IP1)
//===========>| Router |-----------------\
|| | R1 | |
|| +----------+ v
.-. .-.
,-( _)-. ,-( _)-.
.-(_ IPv4 )-. .-(_ IPv6 )-.
(__ Network ) (__ Network )
`-(______)-' `-(______)-'
^^ |
|| +----------+ |
\\============| Router |<----------------/
[ Packet 1 ] | R2 | [ Packets 0 and 2 ]
v6src = Addr(Prf1, IP2) +----------+ v6src = Addr(Prf1, IP2)
v6dst = Addr(Prf2, IP1) v6dst = Addr(Prf2, IP1)
v4src = IP2; v4dst = IP1
Legend: ====> - tunneled IPv6, ---> - native IPv6
Figure 1: The Network Setting of the Attackso the attack kicks off with an IPv6 packet (packet 0 in Figure 1) that's either an accident or made on purpose 😈 it's headed to a made-up endpoint that looks like it's reached via Prf2 and has IP1 as its IPv4 address, so Addr(Prf2, IP1). its source is an address with Prf1 as the prefix and IP2 embedded as the IPv4 address, so Addr(Prf1, IP2) 💜 since the destination prefix is Prf2, the packet gets routed over the IPv6 network to R2 ✨
R2 gets the packet on its IPv6 interface and forwards it into the tunnel. the IPv4 header's destination comes from the IPv6 destination, so it's IP1, and the source is R2's own address, IP2 🎀 the packet (packet 1 in Figure 1) gets routed over the IPv4 network to R1, which receives it on its IPv4 interface. R1 handles it like a packet from one of the end nodes of Prf1 🦋
because the IPv4 source matches the IPv6 source, R1 decapsulates the packet 💅 and since the IPv6 destination is outside Prf1, R1 forwards it out onto a native IPv6 interface 🌈 the forwarded packet (packet 2 in Figure 1) is identical to the original attack packet, so it gets routed back to R2 and the loop starts over 😭 the packet doesn't have to travel from R1 over the native IPv6 network, by the way. R1 could be connected to the IPv6 network through another tunnel instead 🧚
here's the crux, and it's giving chaos 💀 the attacker takes advantage of the fact that R2 doesn't know R1 doesn't configure addresses from Prf2, and R1 doesn't know R2 doesn't configure addresses from Prf1 🙈 the IPv4 network acts like a shared link layer for both tunnels, so both routers keep forwarding the same packet over and over 🔥 the attack fails if the IPv4 network can't carry packets between the tunnels, like when the two routers are in different IPv4 address realms or when ingress/egress filtering is applied between them 🫶
the loop ends when the Hop Limit field hits zero ✨ each loop lowers the Hop Limit by the number of IPv6 routers on the path from R1 to R2, so the number of loops is inversely proportional to the number of IPv6 hops between R1 and R2 💖
the tunnels used by R1 and R2 can be any mix of automatic tunnel types, like ISATAP, 6to4, and 6rd 🌸 the one exception is that both can't be 6to4, because two 6to4 routers share the same IPv6 prefix, and there's only one 6to4 prefix (2002::/16) on the Internet 💅 for example, if the attack targeted an ISATAP router (R1) and a 6to4 relay (R2), the destination and source addresses of the attack packet would be 2002:IP1:* and Prf1::0200:5efe:IP2, respectively 🦋
3. Proposed Mitigation Measures 🎀
this section covers some possible mitigations for the attack we just went through, and we'll talk about the pros and cons of each one 💜
there are three categories of proposed measures:
- Verification of endpoint existence 🌸
- Operational measures 🫶
- Destination and source address checks ✨
3.1. Verification of Endpoint Existence 💖
the routing loop attack works because a router has no idea whether an endpoint reachable through its tunnel has the packet's source or destination address 🙈 this category has mitigations that check that a node really takes part in the tunnel, and that its address matches the packet's destination or source address, whichever applies 🧚
3.1.1. Neighbor Cache Check 🦋
one way for a router to confirm that an end host exists and can be reached through the tunnel is to check whether there's a valid entry for it in the neighbor cache of the matching tunnel interface 💅 that entry can be filled in through, for example, an initial reachability check, receiving neighbor discovery messages, administrative configuration, and so on 🌈
when the router has a packet for a potential tunnel host that has no neighbor cache entry, it can run an initial reachability check on the packet's destination address, for example as specified in the second paragraph of Section 8.4 of [RFC5214]. (the router can do the same kind of "reverse reachability" check on the packet's source address when it gets a packet from a potential tunnel host with no neighbor cache entry 🫶) this reachability check matches the address resolution specs in Section 7.2 of [RFC4861], meaning the router keeps a small queue of packets waiting for reachability confirmation to finish ⭐ if confirmation works, the router learns that a legit tunnel host answers at that address 🎀 otherwise, the router throws away later packets and sends back ICMP destination unreachable indications as specified in Section 7.2.2 of [RFC4861] 😭
this approach assumes the neighbor cache stays coherent and isn't open to malicious attack, and that has to be checked against the specific deployment scenario 🙈 one way an attacker could mess with the neighbor cache is by sending fake neighbor discovery messages with a spoofed source address 💀
3.1.2. Known IPv4 Address Check 🌸
another way for a router to verify that an end host exists and can be reached through the tunnel is to pre-configure the router with the set of IPv4 addresses and prefixes that are allowed to use the tunnel 🍓 once that's set up, the router can run these simple checks:
- When the router forwards an IPv6 packet into the tunnel interface with a destination address that matches an on-link prefix and embeds the IPv4 address IP1, it discards the packet if IP1 isn't in the configured list of IPv4 addresses 🔥
- When the router receives an IPv6 packet on the tunnel's interface with a source address that matches an on-link prefix and embeds the IPv4 address IP2, it discards the packet if IP2 isn't in the configured list of IPv4 addresses 💅
3.2. Operational Measures 🫶
the network operator can take the following measures 🧚 their goal is to configure the network so these attacks can't happen at all ✨
3.2.1. Avoiding a Shared IPv4 Link 💜
as we said above, the attack depends on an IPv4 network acting as a shared link layer between more than one tunnel 🦋 that leads to the following two mitigations:
3.2.1.1. Filtering IPv4 Protocol-41 Packets 💖
with this measure, a tunnel router can drop all IPv4 protocol-41 packets received or sent over interfaces attached to an untrusted IPv4 network 🌸 that cuts off the IPv4 network as a shared link ✨ the big perk is simplicity 😌 but it might not work where IPv4 connectivity is essential on every interface 💀 most notably, filtering IPv4 protocol-41 packets that belong to a 6to4 tunnel can really hurt unsuspecting users 😭
3.2.1.2. Operational Avoidance of Multiple Tunnels 🎀
this measure stops the attack by only letting a single IPv6 tunnel run inside a bounded IPv4 network 🍓 for instance, the attack can't happen in broadband home networks 🏠 in those setups there's a small home network with one residential gateway acting as the tunnel router 🧚 a tunnel router is only vulnerable if it has at least two interfaces with a path to the Internet: a tunnel interface and a native IPv6 interface (as shown in Figure 1) 💅 but a residential gateway usually has just one Internet interface, so the attack can't happen there 🙌 and if there are only one or a few tunnel routers in the IPv4 network and they all use the same tunnel, there's no way for the loop to keep going 🔁
this approach avoids the attack altogether without needing any explicit mitigations, which is iconic 👑 but it needs careful configuration management, and that might not be doable in large or unbounded IPv4 networks 🥺
3.2.2. A Single Border Router 🏠
okay so the idea here is pretty simple, bestie 🎀 A tunnel router should only accept or forward tunneled packets over its tunnel interface, and only accept or forward IPv6 packets over its IPv6 interface. 💅 If those two interfaces are physically separate, the network operator can shut the attack down by making sure there is no path between them that skips the tunnel router. 🛑
Why does that work? 🤔 Well, an encapsulated packet coming in on the tunnel interface can't sneak through some other tunnel router and pop back out the IPv6 side of the first router. 🙅♀️ The reverse direction is covered too: an IPv6 packet arriving on the IPv6 interface can't wander over to another tunnel router and come back out the tunnel interface. 🔁 Basically, the tunnel router ends up being the only border router between the IPv6 network and the IPv4 network it's attached to, like in that broadband home network scenario we talked about earlier. 🏡✨
3.2.3. A Comprehensive List of Tunnel Routers 📜
if a tunnel router has a complete list of the IPv4 addresses of every other tunnel router in the network, it can use that list as a filter 🧹 and toss out any tunneled packets coming from or heading to those other routers. 🗑️ For example, a tunnel router can use the network's ISATAP Potential Router List (PRL) [RFC5214] as that filter, but only as long as there's operational assurance that every ISATAP router is on the list and that no other kinds of tunnel routers are hanging around the network. 🧐🔒
this is basically the same move that 6rd uses in [RFC5969], where the 6rd Border Relay filters out all the known relay addresses of other tunnels inside the ISP's network. 👯♀️
this one shines for intra-site tunneling mechanisms like ISATAP and 6rd 🌸, since filtering is easy to do on well-defined site borders. 🏰 There's a specific ISATAP operational scenario where this mitigation applies, and it's described in Section 3 of [ISATAP-OPS]. 📖
3.2.4. Avoidance of On-Link Prefixes 🚫
okay this is the one that's giving "root cause" energy 🔥 The looping attack works because a router is allowed to assign non-link-local IPv6 prefixes on its tunnel interfaces. 😬 That can make it send tunneled packets to other routers that never configured an address from that prefix. 🌀 So if the router simply doesn't assign non-link-local IPv6 prefixes on its tunnel interfaces, it has no way to start the loop. 🙌 And if it also makes sure its routing state is consistent for the packets it receives on those tunnel interfaces, it has no way to pass along a loop that some other router started either. 💖
a few limits, though, because not every situation qualifies 🙈:
- this mitigation is only available to ISATAP routers, because the ISATAP stateless address mapping only works on the Interface Identifier part of the IPv6 address, not the prefix. 🧩
- it only applies on ISATAP links where IPv4 source address spoofing is disabled. 🛡️
- it also only applies on ISATAP links where nodes support the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. 📡
the next few sections walk through the operational configurations you need to actually pull this off 💅✨
3.2.4.1. ISATAP Router Interface Types 🎛️
ISATAP gives you a Potential Router List (PRL) to help keep the topology loop-free 🔁🚫. Routers that are on the PRL for the site set their site-facing ISATAP interfaces as advertising router interfaces (see [RFC4861], Section 6.2.2). That means they're allowed to send Router Advertisement (RA) messages with non-zero Router Lifetimes. 📣 Routers that aren't on the PRL for the site set their site-facing ISATAP interfaces as non-advertising router interfaces. 🤫
3.2.4.2. ISATAP Source Address Verification 🕵️♀️
ISATAP nodes use the source address verification checks from Section 7.3 of [RFC5214] as a prerequisite before they decapsulate anything received on an ISATAP interface. 🔐 To turn on the on-link prefix avoidance procedures from this section, ISATAP nodes must employ an additional source address verification check too 🫶. In other words, the node also treats the outer IPv4 source address as correct for the inner IPv6 source address if:
- a forwarding table entry exists that lists the packet's IPv4 source address as the link-layer address corresponding to the inner IPv6 source address via the ISATAP interface.
3.2.4.3. ISATAP Host Behavior 🧑💻
ISATAP hosts send Router Solicitation (RS) messages to get RA messages from an advertising ISATAP router, as specified in [RFC4861] and [RFC5214]. 📨 When stateful address autoconfiguration services are available, the host can grab its IPv6 addresses using DHCPv6 [RFC3315] 🎁.
to get addresses, the host does the standard DHCPv6 exchanges, but it maps the IPv6 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to the IPv4 address of the advertising router 🗺️. The host should also use DHCPv6 Authentication in environments where the DHCPv6 exchanges have to be authenticated 🔑.
once the host has its IPv6 addresses, it assigns them to its ISATAP interface and sends any of its outbound IPv6 packets through the advertising router, which it uses as its default router 🚀. The advertising router then keeps IPv6 forwarding table entries that list the host's IPv4 address as the link-layer address of those delegated IPv6 addresses 📒✨.
3.2.4.4. ISATAP Router Behavior 🤖
in lots of use cases (think enterprise networks, Mobile Ad Hoc Networks (MANETs), and so on), advertising and non-advertising ISATAP routers can run a proactive dynamic IPv6 routing protocol (like OSPFv3 or the Routing Information Protocol Next Generation (RIPng)) over their ISATAP interfaces 🛣️. That fills up the IPv6 routing and forwarding tables, so standard IPv6 forwarding between ISATAP routers can work normally. 🙌 In other setups, like really large enterprise networks, this can be impractical because of scaling issues 📉. When a proactive dynamic routing protocol can't be used, non-advertising ISATAP routers send RS messages to get RA messages from an advertising ISATAP router. In other words, they act like "hosts" on their non-advertising ISATAP interfaces 🧍♀️.
non-advertising ISATAP routers can also acquire IPv6 prefixes, for example through DHCPv6 Prefix Delegation [RFC3633] via an advertising router. That works the same way as the host-based DHCPv6 stateful address autoconfiguration we just covered 🎀. The advertising router keeps IPv6 forwarding table entries that list the IPv4 address of the non-advertising router as the link-layer address of the next hop toward those delegated IPv6 prefixes 🗂️.
once the non-advertising router has its IPv6 prefixes, it can sub-delegate them to routers and links in its attached IPv6 edge networks 🌐. It can then forward any outbound IPv6 packets coming from those edge networks through other ISATAP nodes on the link 🦋✨
3.2.4.5. Reference Operational Scenario 🗺️✨
okay so let's walk through the reference setup 💅 Figure 2 shows a reference ISATAP network topology for operational avoidance of on-link non-link-local IPv6 prefixes. The scenario has two advertising ISATAP routers ('A', 'B'), two non-advertising ISATAP routers ('C', 'E'), an ISATAP host ('G'), and three ordinary IPv6 hosts ('D', 'F', 'H') in a typical deployment configuration:
.-(::::::::) 2001:db8:3::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host H |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | / fe80::*192.0.2.5
: | (ISATAP) | | (ISATAP) | ; 2001:db8:2::1
+ +------------+ +------------+ \ +--------------+
; fe80::*192.0.2.1 fe80::*192.0.2.2 : | (ISATAP) |
| ; | Host G |
: IPv4 Site -+-' +--------------+
`-. (PRL: 192.0.2.1, 192.0.2.2) .)
\ _)
`-----+--------)----+'----'
fe80::*192.0.2.3 fe80::*192.0.2.4 .-.
+--------------+ +--------------+ ,-( _)-.
| (ISATAP) | | (ISATAP) | .-(_ IPv6 )-.
| Router C | | Router E |--(__Edge Network )
+--------------+ +--------------+ `-(______)-'
2001:db8:0::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8:0::1 | IPv6 Host F |
.-(_ IPv6 )-. +-------------+ +-------------+
(__Edge Network )--| IPv6 Host D |
`-(______)-' +-------------+
(* == "5efe:")
Figure 2: Reference ISATAP Network TopologyIn Figure 2, advertising ISATAP routers 'A' and 'B' within the IPv4 site connect to the IPv6 Internet, either directly or via a companion gateway. 'A' configures a provider network IPv4 interface with address 192.0.2.1 and arranges to add the address to the provider network PRL. 'A' next configures an advertising ISATAP router interface with link-local IPv6 address fe80::5efe:192.0.2.1 over the IPv4 interface. In the same fashion, 'B' configures the IPv4 interface address 192.0.2.2, adds the address to the PRL, then configures the IPv6 ISATAP interface link-local address fe80::5efe:192.0.2.2.
Non-advertising ISATAP router 'C' connects to one or more IPv6 edge networks and also connects to the site via an IPv4 interface with address 192.0.2.3, but it does not add the IPv4 address to the site's PRL. 'C' next configures a non-advertising ISATAP router interface with link-local address fe80::5efe:192.0.2.3, then receives the IPv6 prefix 2001:db8:0::/48 through a DHCPv6 prefix delegation exchange via one of 'A' or 'B'. 'C' then engages in an IPv6 routing protocol over its ISATAP interface and announces the delegated IPv6 prefix. 'C' finally sub-delegates the prefix to its attached edge networks, where IPv6 host 'D' autoconfigures the address 2001:db8:0::1.
Non-advertising ISATAP router 'E' connects to the site, configures its ISATAP interface, receives a DHCPv6 prefix delegation, and engages in the IPv6 routing protocol the same as for router 'C'. In particular, 'E' configures the IPv4 address 192.0.2.4, the ISATAP link-local address fe80::5efe:192.0.2.4, and the delegated IPv6 prefix 2001:db8:1::/48. 'E' finally sub-delegates the prefix to its attached edge networks, where IPv6 host 'F' autoconfigures IPv6 address 2001:db8:1::1.
ISATAP host 'G' connects to the site via an IPv4 interface with address 192.0.2.5, and also configures an ISATAP host interface with link-local address fe80::5efe:192.0.2.5 over the IPv4 interface. 'G' next configures a default IPv6 route with next-hop address fe80::5efe:192.0.2.2 via the ISATAP interface, then receives the IPv6 address 2001:db8:2::1 from a DHCPv6 address configuration exchange via 'B'. When 'G' receives the IPv6 address, it assigns the address to the ISATAP interface but does not assign a non-link-local IPv6 prefix to the interface.
Finally, IPv6 host 'H' connects to an IPv6 network outside of the ISATAP domain. 'H' configures its IPv6 interface in a manner specific to its attached IPv6 link, and autoconfigures the IPv6 address 2001:db8:3::1.
Following this autoconfiguration, when host 'D' has an IPv6 packet to send to host 'F', it prepares the packet with source address 2001:db8:0::1 and destination address 2001:db8:1::1, then sends the packet into the edge network where it will eventually be forwarded to router 'C'. 'C' then uses ISATAP encapsulation to forward the packet to router 'E', since it has discovered a route to 2001:db8:1::/48 with next hop 'E' via dynamic routing over the ISATAP interface. Router 'E' finally forwards the packet to host 'F'.
In a second scenario, when 'D' has a packet to send to ISATAP host 'G', it prepares the packet with source address 2001:db8:0::1 and destination address 2001:db8:2::1, then sends the packet into the edge network where it will eventually be forwarded to router 'C' the same as above. 'C' then uses ISATAP encapsulation to forward the packet to router 'A' (i.e., a router that advertises "default"), which in turn forwards the packet to 'G'. Btw this operation entails two hops across the ISATAP link (i.e., one from 'C' to 'A', and a second from 'A' to 'G'). If 'G' also participates in the dynamic IPv6 routing protocol, however, 'C' could instead forward the packet directly to 'G' without involving 'A'.
In a third scenario, when 'D' has a packet to send to host 'H' in the IPv6 Internet, the packet is forwarded to 'C' the same as above. 'C' then forwards the packet to 'A', which forwards the packet into the IPv6 Internet.
In a final scenario, when 'G' has a packet to send to host 'H' in the IPv6 Internet, the packet is forwarded directly to 'B', which forwards the packet into the IPv6 Internet.
3.2.4.6. Scaling Considerations 📈💜
Figure 2 depicts an ISATAP network topology with only two advertising ISATAP routers within the provider network. In order to support larger numbers of non-advertising ISATAP routers and ISATAP hosts, the provider network can deploy more advertising ISATAP routers to support load balancing and generally shortest-path routing.
Such an arrangement requires that the advertising ISATAP routers participate in an IPv6 routing protocol instance so that IPv6 address/prefix delegations can be mapped to the correct router. The routing protocol instance can be configured as either a full mesh topology involving all advertising ISATAP routers, or as a partial mesh topology with each advertising ISATAP router associating with one or more companion gateways. Each such companion gateway would in turn participate in a full mesh between all companion gateways.
3.2.4.7. On-Demand Dynamic Routing 🦋🔥
With respect to the reference operational scenario depicted in Figure 2, there will be many use cases in which a proactive dynamic IPv6 routing protocol cannot be used. For example, in large enterprise network deployments it would be impractical for all routers to engage in a common routing protocol instance, due to scaling considerations.
In those cases, an on-demand routing capability can be enabled in which ISATAP nodes send initial packets via an advertising ISATAP router and receive redirection messages back. For example, when a non-advertising ISATAP router 'B' has a packet to send to a host located behind non-advertising ISATAP router 'D', it can send the initial packets via advertising router 'A', which will return redirection messages to inform 'B' that 'D' is a better first hop. Protocol details for this ISATAP redirection are specified in [AERO].
3.3. Destination and Source Address Checks ✨
okay so tunnel routers can run a source address check 🫶 when they forward an IPv6 packet into a tunnel interface and the IPv6 source address has one of the router's own configured IPv4 addresses embedded in it. same energy on the other side: they can run a destination address check 💅 when they receive an IPv6 packet on a tunnel interface and the IPv6 destination address 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. the vibe is consistency across every format 🌸
for example, if tunnel router R1 (of any tunnel protocol) forwards a packet into a tunnel interface with an IPv6 source address matching the 6to4 prefix 2002:IP1::/48, the router discards the packet if IP1 is one of its own IPv4 addresses. 🙈 in a second example, if tunnel router R2 receives an IPv6 packet on a tunnel interface with an IPv6 destination address that has an off-link prefix but an interface identifier matching the ISATAP address suffix ::0200:5efe:IP2, the router discards the packet if IP2 is one of its own IPv4 addresses.
so a tunnel router can dodge the attack by doing these checks:
- When the router forwards an IPv6 packet into a tunnel interface, it discards the packet if the IPv6 source address has an off-link prefix but embeds one of the router's configured IPv4 addresses.
- When the router receives an IPv6 packet on a tunnel interface, it discards the packet if the IPv6 destination address has an off-link prefix but embeds one of the router's configured IPv4 addresses.
this approach has the advantage that no ancillary state is required 🧚, since the checking is just a static lookup in the lists of IPv4 and IPv6 addresses belonging to the router. no extra bookkeeping, iconic 👑 however, it has some inherent limitations, bestie:
- The checks incur an overhead that is proportional to the number of IPv4 addresses assigned to the router. If a router is assigned many addresses, the additional processing overhead for each packet may be considerable. Note that an unmitigated attack packet would be repetitively processed by the router until the Hop Limit expires, which may require as many as 255 iterations. Hence, an unmitigated attack will consume far more aggregate processing overhead than per-packet address checks even if the router assigns a large number of addresses. 🔥 so yes the checks cost something, but the attack costs way more
- The checks should be performed for the IPv6 address formats of every existing automatic IPv6 tunnel protocol (that uses protocol-41 encapsulation). Hence, the checks must be updated as new protocols are defined. 🌈
- Before the checks can be performed, the format of the address must be recognized. There is no guarantee that this can be generally done. For example, one cannot determine if an IPv6 address is a 6rd one; hence, the router would need to be configured with a list of all applicable 6rd prefixes (which may be prohibitively large) in order to unambiguously apply the checks. 💀
- The checks cannot be performed if the embedded IPv4 address is a private one [RFC1918], since it is ambiguous in scope. Namely, the private address may be legitimately allocated to another node in another routing region. 🙃
the last limitation may be relieved if the router has some information that allows it to unambiguously determine the scope of the address. the check in the following subsection is one example of that. ✨
3.3.1. Known IPv6 Prefix Check
a router may be configured with the full list of IPv6 subnet prefixes assigned to the tunnels attached to its current IPv4 routing region. 🦋 in that case, it can use the list to figure out when static destination and source address checks are possible. by keeping track of the list of IPv6 prefixes assigned to the tunnels in the IPv4 routing region, a router can perform the following checks on an address that embeds a private IPv4 address:
- When the router forwards an IPv6 packet into its tunnel with a source address that embeds a private IPv4 address and matches an IPv6 prefix in the prefix list, it determines whether the packet should be discarded or forwarded by performing the source address check specified in Section 3.3.
- When the router receives an IPv6 packet on its tunnel interface with a destination address that embeds a private IPv4 address and matches an IPv6 prefix in the prefix list, it determines whether the packet should be discarded or forwarded by performing the destination address check specified in Section 3.3.
the disadvantage is that the administrative overhead of maintaining the list of IPv6 subnet prefixes associated with an IPv4 routing region may become unwieldy should that list be long and/or frequently updated. 😭
4. Recommendations
okay, recs time 📝 given all the mitigations we just covered, here they are, in decreasing order of importance:
- When possible, it is recommended that the attacks be operationally eliminated (as per the measures proposed in Section 3.2). 👑 step one is always killing the attack at the source
- For tunnel routers that keep a coherent and trusted neighbor cache that includes all legitimate endpoints of the tunnel, we recommend exercising the neighbor cache check. 💜
- For tunnel routers that can implement the Neighbor Reachability Check, we recommend exercising it. 🫶
- For tunnels having a small and static list of endpoints, we recommend exercising the known IPv4 address check. 🌸
- We generally do not recommend using the destination and source address checks, since they cannot mitigate routing loops with 6rd routers. Therefore, these checks should not be used alone unless there is operational assurance that other measures are exercised to prevent routing loops with 6rd routers. 💀 do NOT run these solo, it's a trap
as noted earlier, tunnels may be deployed in various operational environments. there is a possibility that other mitigation measures may be feasible in specific deployment scenarios. the above recommendations are general and do not attempt to cover such scenarios. 🦋
5. Security Considerations
okay this section is the serious one, so pay attention 🔥 this document aims at presenting possible solutions to the routing loop attack that involves automatic tunnels' routers. it contains various checks that aim to recognize and drop specific packets that have strong potential to cause a routing loop. and these checks do not introduce new security threats ✨💖
6. Acknowledgments
big thank yous 🫶 this work has benefited from discussions on the V6OPS, 6MAN, and SECDIR mailing lists. the document has further benefited from comments received from members of the IESG during their review. shoutout to Dmitry Anipko, Fred Baker, Stewart Bryant, Remi Despres, Adrian Farrell, Fernando Gont, Christian Huitema, Joel Jaeggli, and Dave Thaler for their contributions 💅🎀
7. References
7.1. Normative References
- [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
- [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
- [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
- [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
- [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
- [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
- [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
7.2. Informative References
- [AERO] Templin, F., Ed., "Asymmetric Extended Route Optimization (AERO)", Work in Progress, June 2011.
- [ISATAP-OPS] Templin, F., "Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP", Work in Progress, July 2011.
- [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
- [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
- [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
- [TEREDO-LOOPS] Gont, F., "Mitigating Teredo Rooting Loop Attacks", Work in Progress, September 2010.
- [USENIX09] Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 Tunnels", USENIX WOOT, August 2009.
Authors' Addresses
Gabi Nakibly
National EW Research & Simulation Center
Rafael - Advanced Defense Systems
P.O. Box 2250 (630)
Haifa 31021
Israel
EMail: gnakibly@yahoo.com
Fred L. Templin
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
EMail: fltemplin@acm.org📦 where this page comes from
- ietf: rfc6324 2011-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms