One document matched: draft-ietf-v6ops-tunnel-loops-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<rfc category="info" docName="draft-ietf-v6ops-tunnel-loops-00.txt"
ipr="trust200902">
<front>
<title abbrev="Routing Loop Attack">Routing Loop Attack using IPv6
Automatic Tunnels: Problem Statement and Proposed Mitigations</title>
<author fullname="Gabi Nakibly" initials="G." surname="Nakibly">
<organization
abbrev="National EW Research & Simulation Center">National EW
Research & Simulation Center</organization>
<address>
<postal>
<street>P.O. Box 2250 (630)</street>
<city>Haifa</city>
<code>31021</code>
<country>Israel</country>
</postal>
<email>gnakibly@yahoo.com</email>
</address>
</author>
<author fullname="Fred L. Templin" initials="F." surname="Templin">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>fltemplin@acm.org</email>
</address>
</author>
<date day="12" month="September" year="2010" />
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document is concerned with security vulnerabilities in
IPv6-in-IPv4 automatic tunnels. These vulnerabilities allow an attacker
to take advantage of inconsistencies between the IPv4 routing state and
the IPv6 routing state. The attack forms a routing loop which can be
abused as a vehicle for traffic amplification to facilitate DoS attacks.
The first aim of this document is to inform on this attack and its root
causes. The second aim is to present some possible mitigation
measures.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IPv6-in-IPv4 tunnels are an essential part of many migration plans
for IPv6. They allow two IPv6 nodes to communicate over an IPv4-only
network. Automatic tunnels form a category of tunnels in which a
packet's egress node's IPv4 address is embedded within the destination
IPv6 address of the packet. A tunnel's router is a router that
encapsulates and decapsulates the IPv6 packets into and out of the
tunnel, respectively. Ref. <xref target="USENIX09"></xref> pointed out
the existence of a vulnerability in the design of IPv6 automatic
tunnels. Tunnel routers operate on the implicit assumption that the
destination address of an incoming IPv6 packet is always an address of a
valid node that can be reached via the tunnel. This assumption poses a
security vulnerability since it may result in an inconsistency between
the IPv4 routing state and the IPv6 routing state there by allowing a
routing loop to be formed.</t>
<t>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 the native
IPv6 network. There the packet is routed back to the ingress point that
forwards it back into the tunnel. Consequently, the packet loops in and
out of the tunnel. The loop terminates only when the Hop Limit field in
the IPv6 header of the packet is decremented to zero.</t>
<t>Unless proper security measures are in place all IPv6 automatic
tunnels that are based on protocol-41 encapsulation are vulnerable to
such an attack, in particular, ISATAP <xref target="RFC5214"></xref>,
6to4 <xref target="RFC3056"></xref> and 6rd <xref
target="RFC5569"></xref>. The aim of this document is to shed light on
the routing loop attack and present some possible mitigation measures
that should be considered by operators of current IPv6 automatic tunnels
and by designers of future ones. We note that tunnels may be deployed in
various operational environments, e.g. service provider network,
enterprise network, etc. Specific issues related to the attack which are
derived from the operational environment are not considered in this
document.</t>
</section>
<section title="A Detailed Description of the Attack">
<t>In this section we shall denote an IPv6 address of a node reached via
a given tunnel by the prefix of the tunnel and an IPv4 address of the
tunnel end point, i.e., Addr(Prefix, IPv4). Note that the IPv4 address
may or may not be part of the prefix (depending on the specification of
the tunnel's protocol). The IPv6 address may be dependent on additional
bits in the interface ID, however for our discussion their exact value
is not important.</t>
<t>The two victims of this attack are routers - R1 and R2 - of two
different tunnels - T1 and T2. Both routers have the capability to
forward IPv6 packets in and out of their respective tunnels. The two
tunnels need not be based on the same tunnel protocol. The only
condition is that the two tunnel protocols be based on protocol-41
encapsulation. The IPv4 address of R1 is IP1, while the prefix of its
tunnel is Prf1. IP2 and Prf2 are the respective values for R2. We assume
that IP1 and IP2 belong to the same address realm, i.e., they are either
both public, or both private and belong to the same internal network.
The following network diagram depicts the locations of the two
routers.</t>
<figure anchor="network" title="The network setting of the attack">
<artwork><![CDATA[
#######
# R1 #
#######
// \
T1 // \
interface // \
_______________//_ __\________________
| | | |
| IPv4 Network | | IPv6 Network |
|__________________| |___________________|
\\ /
\\ /
T2 \\ /
interface \\ /
#######
# R2 #
#######
]]></artwork>
</figure>
<t>The attack is depicted in <xref target="figattack"></xref>. It is
initiated by sending an IPv6 packet (packet 0 in <xref
target="figattack"></xref>) destined to a fictitious end point that
appears to be reached via T2 and has IP1 as its IPv4 address, i.e.,
Addr(Prf2, IP1). The source address of the packet is a T1 address with
Prf1 as the prefix and IP2 as the embedded IPv4 address, i.e.,
Addr(Prf1, IP2). As the prefix of the destination address is Prf2, the
packet will be routed over the IPv6 network to T2.</t>
<t>We assume that R2 is the packet's entry point to T2. R2 receives the
packet through its IPv6 interface and forwards it over its T2 interface
encapsulated with an IPv4 header having a destination address derived
from the IPv6 destination, i.e., IP1. The source address is the address
of R2, i.e., IP2. The packet (packet 1 in <xref
target="figattack"></xref>.) is routed over the IPv4 network to R1,
which receives the packet on its IPv4 interface. It processes the packet
as a packet that originates from one of the end nodes of T1.</t>
<t>Since the IPv4 source address corresponds to the IPv6 source address,
R1 will decapsulate the packet. Since the packet's IPv6 destination is
outside of T1, R1 will forward the packet onto a native IPv6 interface.
The forwarded packet (packet 2 in <xref target="figattack"></xref>) is
identical to the original attack packet. Hence, it is routed back to R2,
in which the loop starts again. Note that the packet may not necessarily
be transported from R1 over native IPv6 network. R1 may be connected to
the IPv6 network through another tunnel.</t>
<figure anchor="figattack"
title="Routing loop attack between two tunnels' routers">
<artwork><![CDATA[
R1 R2
| | 0
| 1 |<------
|<===============|
| 2 |
|--------------->|
| . |
| . |
1 - IPv4: IP2 --> IP1
IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1)
0,2- IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1)
Legend: ====> - tunneled IPv6, ---> - native IPv6
]]></artwork>
</figure>
<t>The crux of the attack is as follows. The attacker exploits the fact
that R2 does not know that R1 does not take part of T2 and that R1 does
not know that R2 does not take part of T1. The IPv4 network acts as a
shared link layer for the two tunnels. Hence, the packet is repeatedly
forwarded by both routers. It is noted that the attack will fail when
the IPv4 network can not transport packets between the tunnels. For
example, when the two routers belong to different IPv4 address realms or
when ingress/egress filtering is exercised between the routes.</t>
<t>The loop will stop when the Hop Limit field of the packet reaches
zero. After a single loop the Hop Limit field is decreased by the number
of IPv6 routers on path from R1 and R2. Therefore, the number of loops
is inversely proportional to the number of IPv6 hops between R1 and
R2.</t>
<t>The tunnel pair T1 and T2 may be any combination of automatic tunnel
types, e.g., ISATAP, 6to4 and 6rd. This has the exception that both
tunnels can not be of type 6to4, since two 6to4 routers can not belong
to different tunnels (there is only one 6to4 tunnel in the Internet).
For example, if the attack were to be launched on an ISATAP router (R1)
and 6to4 relay (R2), then the destination and source addresses of the
attack packet would be 2002:IP1:* and Prf1::0200:5EFE:IP2,
respectively.</t>
</section>
<section title="Proposed Mitigation Measures">
<t>This section presents some possible mitigation measures for the
attack described above. For each measure we shall discuss its advantages
and disadvantages.</t>
<t>The proposed measures fall under the following two categories:</t>
<t><list style="symbols">
<t>Destination and source addresses checks</t>
<t>Verification of end point existence</t>
<t>Operational measures</t>
</list></t>
<section anchor="address-check"
title="Destination and Source Address Checks">
<t>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.</t>
<t>For example, if tunnel router R1 (of any tunnel protocol) forwards
a packet into a tunnel interface with an IPv6 source address that
matches 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 with an off-link prefix but with an interface
identifier that matches the ISATAP address suffix ::0200:5EFE:IP2, the
router discards the packet if IP2 is one of its own IPv4
addresses.</t>
<t>Hence a tunnel router can avoid the attack by performing the
following checks:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
<t>This approach has the advantage that that no ancillary state is
required, since checking is through static lookup in the lists of IPv4
and IPv6 addresses belonging to the router. However, this approach has
some inherit limitations:</t>
<t><list style="symbols">
<t>The checks incur an overhead which 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.</t>
<t>The checks should be performed for the IPv6 address formats of
every existing automatic IPv6 tunnel protocol (which uses
protocol-41 encapsulation). Hence, the checks must be updated as
new protocols are defined.</t>
<t>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 can not determine if an IPv6
address is a 6rd one, hence a configuration is needed at the
router.</t>
<t>The checks cannot be performed if the embedded IPv4 address is
a private one <xref target="RFC1918"></xref> since it is ambiguous
in scope. Namely, the private address may be legitimately
allocated to another node in another routing region.</t>
</list></t>
<t>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 for
this.</t>
<section anchor="known-ipv6-check" title="Known IPv6 Prefix Check">
<t>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 such a case it can use the list to determine 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 which embeds a private IPv4 address:</t>
<t><list style="symbols">
<t>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 <xref target="address-check"></xref>.
Otherwise, the router forwards the packet.</t>
<t>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 <xref
target="address-check"></xref>. Otherwise, the router forwards
the packet.</t>
</list> The disadvantage of this approach is the administrative
overhead for 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.</t>
</section>
</section>
<section title="Verification of end point existence">
<t>The routing loop attack relies on the fact that a router does not
know whether there is an end point that can reached via its tunnel
that has the source or destination address of the packet. This
category includes mitigation measures which aim to verify that there
is a node which participate in the tunnel and its address corresponds
to the packet's destination or source addresses, as appropriate.</t>
<section anchor="neighbor-check" title="Neighbor Cache Check">
<t>One way to verify that an end point exists in a tunnel is by
checking whether a valid entry exists for it in the Neighbor Cache
of the corresponding tunnel interface. A valid entry may exist in
the Neighbor Cache for legitimate end hosts if they generate traffic
towards the router upon startup. For example, an initial RS/RA
exchange to facilitate Stateless Address Auto configuration (as in
the ISATAP case). This allows the router to keep valid Neighbor
Cache entry for each legitimate end host in the tunnel.</t>
<t>By keeping track of the legitimate hosts in the tunnel via the
Neighbor Cache, a router can perform the following simple
checks:</t>
<t><list style="symbols">
<t>When the router forwards a packet into the tunnel with an
IPv6 destination address that matches an on-link prefix and that
embeds the IPv4 address IP1, it discards the packet if there is
no corresponding neighbor cache entry.</t>
<t>When the router receives a packet on the tunnel's interface
with an IPv6 source address that matches an on-link prefix and
that embeds the IPv4 address IP2, it discards the packet if
there is no corresponding neighbor cache entry.</t>
</list></t>
<t>This approach is easy to implement, and naturally leverages the
fact that an end host must successively send RSs in order to refresh
configuration information as on-link prefix information. However,
this requires the router to retain entries for a duration that is at
least as long as the router's advertised prefix lifetimes. This may
require an implementation to adjust its garbage-collection interval
for stale neighbor cache entries.</t>
<t>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.</t>
</section>
<section anchor="known-ipv4-check" title="Known IPv4 Address Check">
<t>Another approach that enables a router to verify that an end host
exists and can be reached via the tunnel is simply by
pre-configuring the router with the set of IPv4 addresses that are
authorized to use the tunnel. Upon this configuration the router can
perform the following simple checks:</t>
<t><list style="symbols">
<t>When the router forwards an IPv6 packet into the tunnel
interface with a destination address that matches an on-link
prefix and that embeds the IPv4 address IP1, it discards the
packet if IP1 does not belong to the configured list of IPv4
addresses.</t>
<t>When the router receives an IPv6 packet on the tunnel's
interface with a source address that matches a on-link prefix
and that embeds the IPv4 address IP2, it discards the packet if
IP2 does not belong to the configured list of IPv4
addresses.</t>
</list></t>
</section>
<section anchor="address-resolution"
title="Neighbor Reachability Check">
<t>Yet another approach that allows a router to verify that an end
host exists and can be reached via the tunnel is by performing an
initial reachability confirmation, e.g., as specified in the second
paragraph of Section 8.4 of <xref target="RFC5214"></xref>. This
procedure parallels the address resolution specifications in Section
7.2 of <xref target="RFC4861"></xref>, i.e., the router maintains a
small queue of packets waiting for reachability confirmation to
complete. If confirmation succeeds, the router discovers that a
legitimate neighbor responds to the address and packets may be
forwarded to it. Otherwise, the router returns ICMP destination
unreachable indications as specified in Section 7.2.2 of <xref
target="RFC4861"></xref>.</t>
</section>
</section>
<section anchor="operational" title="Operational Measures">
<t>The following measures can be taken by the network operator. Their
aim is to configure the network in such a way that the attacks can not
take place.</t>
<section anchor="Avoiding-shared-IPv4-link"
title="Avoiding a Shared IPv4 Link">
<t>As noted above, the attack relies on having an IPv4 network as a
shared link-layer between more than one tunnel. From this the
following two mitigation measures arise:</t>
<section anchor="filtering"
title="Filtering IPv4 Protocol-41 Packets">
<t>In this measure a tunnel router may drop all IPv4 protocol-41
packets received or sent over interfaces that are attached to an
untrusted IPv4 network. This will cut-off any IPv4 network as a
shared link. This measure has the advantage of simplicity.
However, such a measure may not always be suitable for scenarios
where IPv4 connectivity is essential on all interfaces.</t>
</section>
<section anchor="single-tunnel"
title="Operational Avoidance of Multiple Tunnels">
<t>This measure mitigates the attack by simply allowing for a
single IPv6 tunnel to operate in a bounded IPv4 network (e.g., a
small home IPv4 network behind a residential gateway serving as a
tunnel router). In particular, if there are only one or a few
tunnel routers in the IPv4 network and all participate in the same
tunnel then there is no opportunity for perpetuating the loop.</t>
<t>This approach has the advantage that it avoids the attack
profile altogether without need for explicit mitigations. However,
it requires careful configuration management which may not be
tenable in large and/or unbounded IPv4 networks.</t>
</section>
</section>
<section anchor="single-border-router" title="A Single Border Router">
<t>It is reasonable to assume that a tunnel router shall accept or
forward tunneled packets only over its tunnel interface. It is also
reasonable to assume that a tunnel router shall accept or forward
IPv6 packets only over its IPv6 interface. If these two interfaces
are physically different then the network operator can mitigate the
attack by ensuring that the following condition holds: there is no
path between these two interfaces that does not go through the
tunnel router.</t>
<t>The above condition ensures that an encapsulated packet which is
transmitted over the tunnel interface will not get to another tunnel
router and from there to the IPv6 interface of the first router. The
condition also ensures the reverse direction, i.e., an IPv6 packet
which is transmitted over the IPv6 interface will not get to another
tunnel router and from there to the tunnel interface of the first
router. This condition is essentially translated to a scenario in
which the tunnel router is the only border router between the IPv6
network and the IPv4 network to which it is attached.</t>
</section>
</section>
</section>
<section anchor="recommendations" title="Recommendations">
<t>In light of the mitigation measures proposed above we make the
following recommendations in decreasing order:</t>
<t><list style="numbers">
<t>When possible, it is recommended that the attacks are
operationally eliminated (as per one of the measures proposed in
<xref target="operational"></xref>).</t>
<t>For tunnel routers that keep a coherent and trusted neighbor
cache which includes all legitimate end-points of the tunnel, we
recommend exercising the Neighbor Cache Check.</t>
<t>For tunnel routers that can implement the Neighbor Reachability
Check, we recommend exercising it.</t>
<t>For tunnels having small and static list of end-points we
recommend exercising Known IPv4 Address Check.</t>
<t>For all other cases we recommend the Destination and Source
Address Checks.</t>
</list></t>
<t>As noted earlier, tunnels may be deployed in various operational
environments. There is a possibility that other mitigation measures may
be allowed is specific deployment scenarios. The above recommendations
are general and do not attempt to cover such scenarios.</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA considerations.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>This document aims at presenting possible solutions to the routing
loop attack which 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. These checks do not introduce
new security threats.</t>
</section>
<section anchor="acknowledge" title="Acknowledgments">
<t>This work has benefited from discussions on the V6OPS, 6MAN and
SECDIR mailing lists. Remi Despres, Christian Huitema, Dmitry Anipko,
Dave Thaler and Fernando Gont are acknowledged for their
contributions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.3056"?>
<?rfc include="reference.RFC.5214"?>
<?rfc include="reference.RFC.5569"?>
<?rfc include="reference.RFC.1918"?>
<?rfc include="reference.RFC.4861"?>
</references>
<references title="Informative References">
<reference anchor="USENIX09">
<front>
<title>Routing Loop Attacks using IPv6 Tunnels</title>
<author fullname="Gabi Nakibly" initials="G." surname="Nakibly">
<organization></organization>
</author>
<author fullname="Michael Arov" initials="M." surname="Arov">
<organization></organization>
</author>
<date month="USENIX WOOT, August" year="2009" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:26:30 |