One document matched: draft-nakibly-v6ops-tunnel-loops-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?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 iprnotified='no'?>
<rfc category="info" docName="draft-nakibly-v6ops-tunnel-loops-01.txt"
ipr="trust200811" updates="3056, 5214">
<front>
<title abbrev="ISATAP and 6to4 Routing Loops">Routing Loops using ISATAP
and 6to4: Problem Statement and Proposed Solutions</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." role="editor"
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="1" month="February" year="2010" />
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Recent research <xref target="USENIX09" /> has pointed out the
existence of some security vulnerabilities in the design of the
automatic tunnels ISATAP <xref target="RFC5214" /> and 6to4 <xref
target="RFC3056" />. These vulnerabilities allow a specially crafted
packet to loop back and forth between ISATAP routers or 6to4 relays
thereby overloading them.</t>
<t>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.</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 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.</t>
<t>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.</t>
</section>
<section title="Detailed Descriptions of the Attacks">
<t>For the sake of completeness, this section details the three attacks
from <xref target="USENIX09" /> that exemplify how the security
vulnerability described above may be exploited.</t>
<section title="Attack #1: 6to4 Relay to ISATAP Router">
<t>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 <xref
target="figattack1" />. It is initiated by sending an IPv6 packet
(packet 0 in Figure <xref target="figattack1" />) 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 <xref
target="figattack1" />.) 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 <xref
target="figattack1" />.) 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.</t>
<figure anchor="figattack1"
title="Attack #1: 6to4 Relay to ISATAP Router">
<artwork><![CDATA[
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:*
]]></artwork>
<postamble>Legend: ====> - tunneled IPv6, ---> - native
IPv6</postamble>
</figure>
</section>
<section title="Attack #2: ISATAP Router to 6to4 Relay">
<t>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 <xref target="figattack2" />.
This attack is initiated by sending an IPv6 packet (packet 0 in Figure
<xref target="figattack2" />) 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 <xref target="figattack2" />) 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 <xref
target="figattack2" />) is identical to the original attack packet.
Hence, it will be routed back to the ISATAP router, in which the loop
will start again.</t>
<figure anchor="figattack2"
title="Attack #2: ISATAP Router to 6to4 Relay">
<artwork><![CDATA[
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
]]></artwork>
<postamble>Legend: ====> - tunneled IPv6, ---> - native
IPv6</postamble>
</figure>
</section>
<section title="Attack #3: ISATAP Router to ISATAP Router">
<t>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 <xref target="figattack3" />.
It is initiated by sending an IPv6 packet (packet 0 in Figure <xref
target="figattack3" />) 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
<xref target="figattack3" />) 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 <xref target="figattack3" />) is
identical to the original attack packet. Hence, it will be routed back
to router A, in which the loop will start again.</t>
<t>The attack can also be launched on two ISATAP routers having
private IPv4 addresses in th same IPv4 routing region.</t>
<figure anchor="figattack3"
title="Attack #3: ISATAP Router to ISATAP Router">
<artwork><![CDATA[
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
]]></artwork>
<postamble>Legend: ====> - tunneled IPv6, ---> - native
IPv6</postamble>
</figure>
</section>
</section>
<section title="Recommended Solutions">
<t>This section describes the recommended solutions that mitigate the
attacks above. For each solution we shall discuss its advantages and
disadvantages.</t>
<section anchor="address-check"
title="Destination and Source Address Check">
<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 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 <xref
target="RFC1918" /> 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.</t>
<t>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:</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 is
not one of the router's configured IPv6 addresses 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 is not one
of the router's configured IPv6 addresses but embeds one of the
router's configured IPv4 addresses.</t>
</list>
</t>
<t>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.</t>
<t>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.</t>
<section anchor="known-ipv6-check" title="Known IPv6 Prefix Check">
<t>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.</t>
<t>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.</t>
<t>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:</t>
<t><list style="symbols">
<t>When the ISATAP router forwards an IPv6 packet into an ISATAP
interface with a source address that matches an IPv6 prefix in
the on-link prefix list, it determines whether the packet should
be discarded or forwarded by performing the source address check
specified in <xref target="address-check" />. Otherwise, the
router forwards the packet.</t>
<t>When the ISATAP router receives an IPv6 packet on an ISATAP
interface with a destination address that matches an IPv6 prefix
in the on-link prefix list, it determines whether the packet
should be discarded or accepted by performing the destination
address check specified in <xref target="address-check" />.
Otherwise, the router accepts the packet.</t>
</list>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.</t>
</section>
</section>
<section anchor="neighbor-check" title="Neighbor Cache Check">
<t>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.</t>
<t>By keeping track of the hosts that have recently sent RS messages,
an ISATAP router can perform the following simple checks:</t>
<t>
<list style="symbols">
<t>When the ISATAP router forwards a packet into an ISATAP
interface with an IPv6 destination address that matches a
non-link-local prefix assigned to the interface and that embeds
the IPv4 address IPa, it discards the packet if there is no
corresponding neighbor cache entry for the interface keyed on an
IPv6 unicast link-local address that embeds the IPv4 address
IPa.</t>
<t>When the ISATAP router receives a packet on an ISATAP interface
with an IPv6 source address that matches a non-link-local prefix
assigned to the interface and embeds the IPv4 address IPb, it
discards the packet if there is no corresponding neighbor cache
entry for the interface keyed on an IPv6 unicast link-local
address that embeds the IPv4 address IPb.</t>
</list>
</t>
<t>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
<xref target="RFC5214" />.</t>
<t>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 <xref
target="RFC5214" />, 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.</t>
</section>
<section anchor="known-ipv4-check" title="Known IPv4 Address Check">
<t>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:</t>
<t><list style="symbols">
<t>When the ISATAP router forwards an IPv6 packet into an ISATAP
interface with a destination address that matches a non-link-local
prefix assigned to the interface and that embeds the IPv4 address
IPa, it discards the packet if IPa does not belong to the list of
IPv4 addresses over which the ISATAP on-link IPv6 subnet is
configured.</t>
<t>When the ISATAP router receives an IPv6 packet on an ISATAP
interface with a source address that matches a non-link-local
prefix assigned to the interface and that embeds the IPv4 address
IPb, it discards the packet if IPb does not belong to the list of
IPv4 addresses over which the ISATAP on-link IPv6 subnet is
configured.</t>
</list>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.</t>
<t>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.</t>
</section>
</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 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.</t>
</section>
<section anchor="acknowledge" title="Acknowledgments">
<t>This work has benefited from discussions on the V6OPS, 6MAN and
SECDIR mailing lists. Remi Despres and Christian Huitema
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.1918"?>
</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 />
</author>
<author fullname="Michael Arov" initials="M." surname="Arov">
<organization />
</author>
<date month="USENIX WOOT, August" year="2009" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:11:04 |