prefix(es).
3.2. 6to4 Relay Routers
The 6to4 relay router acts as a relay between all 6to4 domains and
native IPv6 networks; more specifically, it
o advertises the reachability of the 2002::/16 prefix to native IPv6
routing, thus receiving traffic to all 6to4 addresses from the
closest native IPv6 nodes,
o advertises (if RFC 3068 [3] is implemented) the reachability of
IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing,
thus receiving some tunneled traffic to native IPv6 nodes from
6to4 routers.
o decapsulates and forwards packets received from 6to4 addresses
through tunneling, by using normal IPv6 routing, and
o tunnels packets received through normal IPv6 routing from native
addresses that are destined for 2002::/16 to the corresponding
6to4 router.
The 6to4 relay should also perform security checks on traffic that it
receives from 6to4 routers, or from native IPv6 nodes. These checks
are as follows:
o Disallow traffic that has private, broadcast, or certain specific
reserved IPv4 addresses in tunnels, or in the matching 6to4
prefixes.
o Disallow traffic from 6to4 routers in which the IPv4 tunnel source
address does not match the 6to4 prefix. (Note that the
pseudo-interface must pick the IPv4 address corresponding to the
prefix when encapsulating, or problems may ensue, e.g., on
multi-interface routers.)
o Disallow traffic in which the destination IPv6 address is not a
global address; in particular, link-local addresses, mapped
addresses, and such should not be used.
o Discard traffic received from 6to4 routers with the destination as
a 6to4 prefix.
4. Threat Analysis
This section discusses attacks against the 6to4 network or attacks
caused by the 6to4 network. The threats are discussed in light of
the 6to4 deployment models defined in Section 2.
There are three general types of threats:
1. Denial-of-Service (DoS) attacks, in which a malicious node
prevents communication between the node under attack and other
nodes.
2. Reflection Denial-of-Service (DoS) attacks, in which a malicious
node reflects the traffic off unsuspecting nodes to a particular
node (node under attack) in order to prevent communication
between the node under attack and other nodes.
3. Service theft, in which a malicious node/site/operator may make
unauthorized use of service.
6to4 also provides a means for a "meta-threat", traffic laundering,
in which some other attack is channeled through the third parties to
make tracing the real origin of the attack more difficult. This is
used in conjunction with other threats, whether specific to 6to4 or
not.
At this point it is important to reiterate that the attacks are
possible because
1. 6to4 routers have to consider all 6to4 relays, and other 6to4
routers, as "on-link",
2. 6to4 relays have to consider all 6to4 routers as "on-link", and
3. it has been discovered that at least a couple of major 6to4
implementations do not implement all the security checks.
The attacks’ descriptions are classified based on the target of the
attack:
1. Attacks on 6to4 networks.
2. Attacks on IPv6 networks.
3. Attacks on IPv4 networks.
Note that one of the mitigation methods listed for various attacks is
based on the premise that 6to4 relays could have a feature limiting
traffic to/from specific 6to4 sites. At the time of this writing,
this feature is speculative, and more work needs to be done to
determine the logistics.
4.1. Attacks on 6to4 Networks
This section describes attacks against 6to4 networks. Attacks that
leverage 6to4 networks, but for which the ultimate victim is
elsewhere (e.g., a native IPv6 user, an IPv4 user), are described
later in the memo.
6to4 relays and routers are IPv4 nodes, and there is no way for any
6to4 router to confirm the identity of the IPv4 node from which it
receives traffic -- whether from a legitimate 6to4 relay or some
other node. A 6to4 router has to process traffic from all IPv4
nodes. Malicious IPv4 nodes can exploit this property and attack
nodes within the 6to4 network.
It is possible to conduct a variety of attacks on the 6to4 nodes.
These attacks are as follows:
1. Attacks with Neighbor Discovery (ND) Messages
2. Spoofing traffic to 6to4 nodes
3. Reflecting traffic from 6to4 nodes
4. Local IPv4 broadcast attack
4.1.1. Attacks with ND Messages
ATTACK DESCRIPTION
Since the 6to4 router assumes that all the other 6to4 routers and
6to4 relays are "on-link", it is possible to attack the 6to4 router
by using ND messages from any node in the IPv4 network, unless a
prior trust relationship has been established.
The attacks target the 6to4 pseudo-interface. As long as the 6to4
addresses are not used in the source or destination address, the
security checks specified by 6to4 take no stance on these packets.
Typically they use link-local addresses.
For example, an attack could be a Route Advertisement or Neighbor
Advertisement message crafted specifically to cause havoc; the
addresses in such a packet could resemble to the following:
src_v6 = fe80::2 (forged address)
dst_v6 = fe80::1 (valid or invalid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
These attacks are exacerbated if the implementation supports more
tunneling mechanisms than 6to4 (or configured tunneling) because it
is impossible to disambiguate such mechanisms, making it difficult to
enable strict security checks (see Section 6.1).
The Neighbor Discovery threats (Redirect DoS, or DoS) are described
in [8]. Note that all attacks may not be applicable, as the 6to4
pseudo-interface is assumed not to have a link-layer address (Section
3.8 RFC 2893 [4]). However, note that the 6to4 router can be either
a router or host from the Neighbor Discovery perspective.
THREAT ANALYSIS AND MITIGATION METHODS
The attacks can be mitigated by using any of the following methods:
o The usage of ND messages could be prohibited. This implies that
all packets using addresses of scope link-local will be silently
discarded. Section 3.1 of RFC 3056 [1] leaves scope for future
uses of link-local address. This method has its pitfalls: It
would prohibit any sort of ND message and thus close the doors on
development and use of other ND options. Whether this is a
significant problem is another thing.
o The 6to4 pseudo-interface could be insulated from the other
interfaces, particularly the other tunnel interfaces (if any), for
example by using a separate neighbor cache.
o If ND messages are needed, either IPsec [4] or an extension of
SEND could be used [9] to secure packet exchange using the
link-local address; vanilla SEND would not work, as the link-layer
does not have an address -- and IPsec would be rather complex.
COMPARISON TO SITUATION WITHOUT 6to4
Even though rather simply fixed, this attack is not new as such; the
same is possible by using automatic tunneling [4] or configured
tunneling (if one is able to spoof source IPv4 address to that of the
tunnel end-point).
However, as 6to4 provides open decapsulation, and automatic tunneling
is being deprecated [10], 6to4 provides an easy means, which would
not exist without it.
4.1.2. Spoofing Traffic to 6to4 Nodes
ATTACK DESCRIPTION
The attacker - a malicious IPv4 or IPv6 node - can send packets that
are difficult to trace (e.g., due to spoofing or going through a
relay) to a 6to4 node. This can be used e.g., to accomplish a DoS
attack.
The IPv6 and IPv4 addresses of the packets will be similar to the
following:
src_v6 = 2001:db8::1 (forged address)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
For attacks launched from a native IPv6 node, the src_v4 will be the
address of the relay through which the traffic will reach the 6to4
node. From IPv4 nodes, src_v4 can be either a spoofed source address
or the real one.
The 6to4 router receives these packets from 8.0.0.1, decapsulates
them, discards the IPv4 header containing the source address 8.0.0.1,
and processes them as normal (the attacker has guessed or obtained
"dst_v6" by using one of a number of techniques).
This is a DoS attack on 6to4 nodes.
This attack is similar to those shown in [11].
EXTENSIONS
Replies to the traffic will be directed to the src_v6 address,
resulting in 6to4 nodes participating in a reflection DoS. This
attack is described in more detail in Section 4.2.3. The replies
(e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to UDP
echo service, ICMPv6 Destination Unreachable) are sent to the victim
(src_v6), above. All the traces from the original attacker (src_v4)
have been discarded. These return packets will go through a relay.
Certain 6to4 networks may have a trivial ACL (Access Control List)
based firewall that allows traffic to pass through if it comes from
particular source(s). Such a firewalling mechanism can be bypassed
by address spoofing. This attack can therefore be used for trivial
ACL avoidance as well. These attacks might be hampered because the
replies from the 6to4 node to the spoofed address will be lost.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The Denial-of-Service attack based on traffic spoofing is not new;
the only twists come from the fact that traces of an attack are more
easily lost, and that spoofing the IPv6 address is possible even to
those who are unable to do so in their current networks. The 6to4
router typically does not log IPv4 addresses (as they would be
treated as L2 addresses), and thus the source of the attack (if
launched from an IPv4 node) is lost. Because traces to the src_v4
address are easily lost, these attacks can also be launched from IPv4
nodes whose connections are ingress-filtered.
However, often this is not a real factor, as usually the attackers
are just zombies and real attackers may not even care whether the
unspoofed source address is discovered.
Malicious native IPv6 nodes could be caught easily if ingress
filtering was enabled everywhere in the IPv6 Internet.
These attacks are easy to perform, but the extent of harm is limited:
o For every packet sent, at most one reply packet is generated:
there is no amplification factor.
o Attack packets, if initiated from an IPv6 node, will pass through
choke point(s), namely a 6to4 relay; in addition to physical
limitations, these could implement some form of 6to4-site-specific
traffic limiting.
On the other hand, a variety of factors can make the attacks serious:
o The attacker may have the ability to choose the relay, and he
might employ the ones best suited for the attacks. Also, many
relays use 192.88.99.1 [3] as the source address, making tracing
even more difficult (also see Section 4.2.6).
o The relay’s IPv4 address may be used as a source address for these
attacks, potentially causing a lot of complaints or other actions,
as the relay might seem to be the source of the attack (see
Section 4.2.6 for more).
Some of the mitigation methods for such attacks are as follows:
1. Ingress filtering in the native IPv6 networks to prevent packets
with spoofed IPv6 sources from being transmitted. This would,
thus, make it easy to identify the source of the attack.
Unfortunately, it would depend on significant (or even complete)
ingress filtering everywhere in other networks; while this is
highly desirable, it may not be feasible.
2. Security checks in the 6to4 relay. The 6to4 relay must drop
traffic (from the IPv6 Internet) that has 6to4 addresses as
source address; see Section 5 for more detail. This has very
little cost.
However, these mitigation methods do not address the case of an IPv4
node sending encapsulated IPv6 packets.
No simple way to prevent such attacks exists, and longer-term
solutions, such as ingress filtering [12] or itrace [13], would have
to be deployed in both IPv6 and IPv4 networks to help identify the
source of the attacks. A total penetration is likely impossible.
(Note that itrace work has been discontinued, as of this writing in
July 2004.)
COMPARISON TO SITUATION WITHOUT 6to4
Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just
makes it easier: Anyone can, regardless of ingress filtering, spoof a
native IPv6 address to a 6to4 node, even if "maximal security" would
be implemented and deployed. Losing trails is also easier.
Therefore, depending on how much one assumes ingress filtering is
deployed for IPv4 and IPv6, this could be considered either a very
serious issue or close to irrelevant compared to the IP spoofing
capabilities without 6to4.
4.1.3. Reflecting Traffic to 6to4 Nodes
ATTACK DESCRIPTION
Spoofed traffic (as described in Section 4.2.2) may be sent to native
IPv6 nodes to perform a reflection attack against 6to4 nodes.
The spoofed traffic is sent to a native IPv6 node, either from an
IPv4 node (through a 6to4 relay) or from a native IPv6 node (unless
ingress filtering has been deployed). With the former, the sent
packets would resemble the following:
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or invalid address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
Note that an attack through the relay is prevented if the relay
implements proper decapsulation security checks (see Section 5 for
details) unless the IPv4 node can spoof the source address to match
src_v6. Similarly, the attack from native IPv6 nodes could be
prevented by global ingress filtering deployment.
These attacks can be initiated by native IPv6, IPv4, or 6to4 nodes.
EXTENSIONS
A distributed Reflection DoS can be performed if a large number of
nodes are involved in sending spoofed traffic with the same src_v6.
Malicious 6to4 nodes can also (try to) initiate this attack by
bouncing traffic off 6to4 nodes in other 6to4 sites. However, this
attack may not be possible, as the 6to4 router (in the site from
which the attack is launched) will filter packets with forged source
addresses (with security checks mentioned in Section 5).
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
In this case, the reverse traffic comprises replies to the messages
received by the 6to4 nodes. The attacker has less control on the
packet type, and this would inhibit certain types of attacks. For
example, flooding a 6to4 node with TCP SYN packets will not be
possible (but e.g., a SYN-ACK or RST would be).
These attacks may be mitigated in various ways:
o Implementation of ingress filtering by the IPv4 service providers.
This would prevent forging of the src_v4 address and help in
closing down on the culprit IPv4 nodes. Note that it will be
difficult to shut down the attack if a large number of IPv4 nodes
are involved.
These attacks may be also be stopped at the 6to4 sites if the
culprit src_v4 address is identified, and if it is constant, by
filtering traffic from this address. Note that it would be
difficult to implement this method if appropriate logging were not
done by the 6to4 router or if a large number of 6to4 nodes, and/or
a large number of IPv4 nodes were participating in the attack.
Unfortunately, because many IPv4 service providers don’t implement
ingress filtering, for whatever reasons, this may not be a
satisfactory solution.
o Implementation of ingress filtering by all IPv6 service providers
would eliminate this attack, because src_v6 could not be spoofed
as a 6to4 address. However, expecting this to happen may not be
practical.
o Proper implementation of security checks (see Section 5) both at
the 6to4 relays and routers would eliminate an attack launched
from an IPv4 node, except when the IPv4 source address was also
spoofed -- but then the attacker would have been able to attack
the ultimate destination directly.
o Rate limiting traffic at the 6to4 relays. In a scenario where
most of the traffic is passing through few 6to4 relays, these
relays can implement traffic rate-limiting features and rate-limit
the traffic from 6to4 sites.
COMPARISON TO SITUATION WITHOUT 6to4
This particular attack can be mitigated by proper implementation of
security checks (which is quite straightforward) and ingress
filtering; when ingress filtering is not implemented, it is typically
easier to attack directly than through reflection -- unless "traffic
laundering" is an explicit goal of the attack. Therefore, this
attack does not seem very serious.
4.1.4. Local IPv4 Broadcast Attack
ATTACK DESCRIPTION
This threat is applicable if the 6to4 router does not check whether
the IPv4 address to which it tries to send encapsulated IPv6 packets
is a local broadcast address or a multicast address.
This threat is described in the specification [1], and implementing
the checks eliminates this threat. However, as checks have not been
widely implemented, the threat is included here for completeness.
There practically two kinds of attacks: when a local 6to4 user tries
to send packets to the address corresponding to the broadcast
address, and when someone is able to do so remotely.
In the first option, assume that 9.0.0.255 is the 6to4 router’s
broadcast address. After receiving the packet with a destination
address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the
router doesn’t check the destination address for subnet broadcast, it
would send the encapsulated protocol-41 packet to 9.0.0.255. This
would be received by all nodes in the subnet, and the responses would
be directed to the 6to4 router.
Malicious sites may also embed forged 6to4 addresses in the DNS, use
of which by a 6to4 node would result in a local broadcast by the 6to4
router. One way to perform this attack would be to send an HTML mail
containing a link to an invalid URL (for example,
http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4
technology based network. Opening of the mail simultaneously would
result in a broadcast storm.
The second kind of attack is more complex: The attack can be
initiated by IPv4 nodes not belonging to the local network as long as
they can send traffic with invalid (for example 2002:0900:00ff::bbbb)
source address. The 6to4 router has to respond to the traffic by
sending ICMPv6 packets back to the source, (e.g., Hop Limit Exceeded
or Destination Unreachable). The packet would be as follows:
src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router)
dst_v6 = 2002:0800:0001::0001 (valid non-existent address)
This is a DoS attack.
EXTENSIONS
The attacks could also be directed at non-local broadcast addresses,
but these would be so-called "IPv4 directed broadcasts", which have
(luckily enough) already been extensively blocked in the Internet.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The attack is based on the premise that the 6to4 router has to send a
packet that embeds an invalid IPv4 address to an IPv6 address. Such
an attack is easily thwarted by ensuring that the 6to4 router does
not transmit packets to invalid IPv4 addresses. Specifically,
traffic should not be sent to broadcast or multicast IPv4 addresses.
COMPARISON TO SITUATION WITHOUT 6to4
The first threat is similar to what is already possible with IPv4,
but IPv6 does not have broadcast addresses.
The second, a more complex threat, is, similarly, also available in
IPv4.
In consequence, the security does not seem to be significantly worse
than with IPv4, and even that is restricted to the site(s) with 6to4
implementations that haven’t been secured as described in Section 5.
4.2. Attacks on Native IPv6 Internet
This section describes attacks against native IPv6 Internet that
somehow leverage 6to4 architecture. Attacks against 6to4 nodes were
described in the previous section.
6to4 and IPv4 nodes can access native IPv6 nodes through the 6to4
relay routers. Thus, the 6to4 relays play a crucial role in any
attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes.
6to4 relays have only one significant security check they must
perform for general safety: When decapsulating IPv4 packets, they
check that 2002:V4ADDR::/48 and V4ADDR match in the source address.
If this is not done, several threats become more serious; in the
following analysis, it is assumed that such checks are implemented.
6to4 relay should not relay packets between 6to4 addresses. In
particular, packets decapsulated from 6to4 routers should not be
encapsulated toward 6to4 routers, as described in Section 5.
Similarly, packets with 6to4 source and destination addresses sent
from IPv6 nodes should not be relayed. It is not clear whether this
kind of check is typically implemented. The attacks described below
assume that such checks are not implemented.
4.2.1. Attacks with ND Messages
These attacks are the same as those employed against 6to4 routers, as
described in Section 4.1.1.
4.2.2. Spoofing Traffic to Native IPv6 Node
ATTACK DESCRIPTION
The attacker - a malicious IPv4 or 6to4 node - can send packets with
a spoofed (or not spoofed) 6to4 source address to a native IPv6 node
to accomplish a DoS attack.
The threat is similar to that involving 6to4 routers, as described in
Section 4.1.2.
The difference here is that the attack is initiated by IPv4 or 6to4
nodes. The source IPv6 address may or may not be spoofed. Note
that, as mentioned above, the relay is assumed to correlate the
source IPv4 address with the address embedded in the source IPv6
address during decapsulation. A side effect is that all spoofed
traffic will have a 6to4 source address.
EXTENSIONS
Spoofed traffic may also be sent to native IPv6 nodes either by other
native IPv6 nodes, by 6to4 nodes, or by malicious IPv4 nodes to
conduct Reflection DoS on either native IPv6 nodes or 6to4 nodes.
Certain native IPv6 networks may have a trivial ACL (Access Control
List) based firewall that allows traffic to pass through if it comes
from particular source(s). Such a firewalling mechanism can be
bypassed by address spoofing. This attack can therefore be used for
trivial ACL avoidance as well. These attacks might be hampered by
lost replies from the 6to4 node to the spoofed address.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The Denial-of-Service attack based on traffic spoofing is not new;
the only twist is that traces of an attack are more easily lost. The
6to4 relay typically does not log IPv4 addresses (as they would be
treated as L2 addresses), and thus the source of the attack (if
launched from an IPv4 node) is lost. Because traces to the src_v4
address are easily lost, these attacks can also be launched from IPv4
nodes whose connections are ingress-filtered.
These attacks might not be easy to perform and might be hampered
because of the following:
o It might be difficult to launch such attacks from 6to4 nodes
because even if the 6to4 routers allow spoofing of the source IPv6
address, the 6to4 relay would check whether the source V4ADDR is