draft-ietf-v6ops-6to4-security-00.txt   draft-ietf-v6ops-6to4-security-01.txt 
v6ops Working Group P. Savola v6ops Working Group P. Savola
Internet Draft CSC/FUNET Internet-Draft CSC/FUNET
Expiration Date: April 2004 Expires: August 10, 2004 C. Patel
October 2003 All Play, No Work
Feb 10, 2004
Security Considerations for 6to4 Security Considerations for 6to4
draft-ietf-v6ops-6to4-security-01.txt
draft-ietf-v6ops-6to4-security-00.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is in full conformance with
of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 10, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- The IPv6 interim mechanism 6to4 (RFC3056) uses automatic
IPv4 tunneling to interconnect IPv6 networks. The architecture IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The
includes 6to4 Routers and Relay Routers, which accept and decapsulate architecture includes 6to4 routers and 6to4 relay routers, which
IPv4 protocol-41 ("IPv6-in-IPv4") traffic from anywhere. There accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from
aren't many constraints on the embedded IPv6 packets, or where IPv4 any node in the IPv4 internet. This characteristic enable ones to go
traffic will be automatically tunneled to. These could enable one to around access controls and perform Denial of Service attacks using
go around access controls, and more likely, being able to perform 6to4 relays or 6to4 routers. It also makes it easier for nodes to
proxy Denial of Service attacks using 6to4 relays or routers as spoof IPv6 addresses. This document discusses these issues in more
reflectors. Anyone is also capable of spoofing traffic from non-6to4 detail and suggests enhancements to alleviate the problems.
addresses, as if it was coming from a relay, to a 6to4 node. This
document discusses these issues in more detail and tries to suggest
enhancements to alleviate the problems.
Table of Contents Table of Contents
1. Introduction ............................................... 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Different 6to4 Forwarding Scenarios ........................ 4 2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . 5
2.1. From 6to4 to 6to4 ...................................... 4 2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . . 5
2.2. From Native to 6to4 .................................... 5 2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . . 5
2.3. From 6to4 to Native .................................... 6 2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . . 6
2.4. Other Models ........................................... 6 2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. BGP Between 6to4 Routers and Relays ................ 6 2.4.1 BGP Between 6to4 Routers and Relays . . . . . . . . . . . . 7
2.4.2. 6to4 as an Optimization Method ..................... 7 2.4.2 6to4 as an Optimization Method . . . . . . . . . . . . . . . 7
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism ...... 7 2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . . . . . . . 7
3. Some Functionalities of 6to4 ............................... 7 3. Functionalities of 6to4 Network Components . . . . . . . . . 9
3.1. Functions of Different 6to4 Network Components ......... 7 3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Non-functions of Different 6to4 Network Components ..... 9 3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . . 10
4. Special Processing of 6to4 Packets ......................... 9 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Encapsulating IPv6 Packets into IPv4 ................... 9 4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . . 12
4.2. Decapsulating IPv4 Packets into IPv6 ................... 10 4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . . . . 13
5. Threat Analysis ............................................ 10 4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . . . . 14
5.1. Threats Related to Any 6to4 Node ....................... 10 4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . . . . 16
5.2. Threats Related to 6to4 Routers ........................ 10 4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . . . . 18
5.2.1. Attacks Against the 6to4 Pseudo-Interface .......... 11 4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . . 19
5.2.1.1. Comparison to Situation without 6to4 ........... 11 4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . . . . 20
5.2.2. Relay Spoofing, DoS against IPv6 Nodes ............. 11 4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . . . . 20
5.2.2.1. Comparison to Situation without 6to4 ........... 12 4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . . . . 22
5.3. Threats Related to 6to4 Relays ......................... 13 4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . . . . 23
5.3.1. Attacks Against the 6to4 Pseudo-Interface .......... 14 4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . . . . 24
5.3.2. Spoofing, DoS against IPv6 Nodes ................... 14 4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . . . . 25
5.3.3. Participating in DoS attacks against IPv4 .......... 14 4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . . 26
5.3.3.1. Comparison to Situation without 6to4 ........... 14 4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . . 27
5.3.4. Using Any IPv6 Node for Reflection ................. 15 5. Implementing Proper Security Checks in 6to4 . . . . . . . . 29
5.3.4.1. Comparison to Situation without 6to4 ........... 15 5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . . 29
5.3.5. IPv4 Local Directed Broadcast Attacks .............. 16 5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . . 30
5.3.5.1. Comparison to Situation without 6to4 ........... 16 5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . . 30
5.3.6. Theft of Service ................................... 16 5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.7. Relay Operators Seen as Source of Abuse ............ 17 5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. Possible Threat Mitigation Methods ..................... 18 5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . . . . 32
5.4.1. 6to4 Decapsulation Cache ........................... 18 5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . . . . 32
5.4.2. Rate-limiting at 6to4 Routers/Relays ............... 18 6. Issues in 6to4 Implementation and Use . . . . . . . . . . . 32
5.4.3. An Application of iTrace Model ..................... 18 6.1 Implementation Considerations with Automatic Tunnels . . . . 32
5.5. Summary ................................................ 19 6.2 Anyone Pretending to Be a 6to4 Relay . . . . . . . . . . . . 33
5.5.1. Summary of the Threats ............................. 19 6.2.1 Limited Distribution of More Specific Routes . . . . . . . . 34
5.5.2. Generic Notes about Threats ........................ 20 6.2.2 A Different Model for 6to4 Deployment . . . . . . . . . . . 35
6. Implementing Proper Security Checks in 6to4 ................ 21 7. Security Considerations . . . . . . . . . . . . . . . . . . 35
6.1. Generic Approach ....................................... 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36
6.1.1. Encapsulating IPv6 into IPv4 ....................... 21 Normative References . . . . . . . . . . . . . . . . . . . . 36
6.1.2. Decapsulating IPv4 into IPv6 ....................... 22 Informative References . . . . . . . . . . . . . . . . . . . 37
6.1.3. IPv4 and IPv6 Sanity Checks ........................ 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
6.1.3.1. IPv4 ........................................... 22 A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . 38
6.1.3.2. IPv6 ........................................... 23 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.3.3. Optional Ingress Filtering ..................... 23 Intellectual Property and Copyright Statements . . . . . . . 40
6.1.3.4. Notes About the Checks ......................... 23
6.2. Simplified Approach .................................... 24
6.2.1. Encapsulating IPv6 into IPv4 ....................... 24
6.2.2. Decapsulating IPv4 into IPv6 ....................... 24
7. Issues ..................................................... 25
7.1. Implementation Considerations with Automatic Tunnels ... 25
7.2. Reduced Flexibility .................................... 26
7.3. Anyone Pretending to Be a Relay Router ................. 26
7.3.1. Limited Distribution of More Specific Routes ....... 27
7.3.2. A Different Model for 6to4 Deployment .............. 28
8. Security Considerations .................................... 28
9. Acknowledgements ........................................... 29
10. References ................................................ 30
10.1. Normative References .................................. 30
10.2. Informative References ................................ 30
Author's Address ............................................... 31
A. Some Trivial Attack Scenarios Outlined ..................... 31
1. Introduction 1. Introduction
The IPv6 interim mechanism "6to4" [6TO4] specifies automatic The IPv6 interim mechanism "6to4" [1] specifies automatic
IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds without IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by
explicit tunnels by embedding the tunnel IPv4 address in the IPv6 embedding the tunnel IPv4 address in the IPv6 6to4 prefix.
6to4 prefix.
One challenge with this mechanism is that all 6to4 routers must Two characteristics of the 6to4 mechanism introduce most of the
accept and decapsulate IPv4 packets from every other 6to4 router; security considerations:
there are no strict constraints on what the IPv6 packet may contain,
which implies a trust relationship.
Another, bigger challenge is that to interconnect native IPv6 1. All 6to4 routers must accept and decapsulate IPv4 packets from
networks and 6to4 clouds, relay routers are used as bridges between every other 6to4 router, and 6to4 relays.
these two clouds. Relay routers can be tricked by malicious parties
to send IPv4 or IPv6 traffic anywhere the attacker wants. With
source address spoofing, this could be called traffic "laundering" or
a "proxy" denial-of-service attack. To some extent, these reflected
attacks can also be launched off from any node at all.
Even worse, anyone can send tunneled traffic, spoofed to come from 2. 6to4 relay routers must accept traffic from any native IPv6 node.
non-6to4 addresses to any 6to4 router, and the node does not have any
means to ensure its correctness, but to assume it came from a Since the 6to4 router must accept from traffic from any other 6to4
legitimate Relay. router or relay, it implies a certain level of trust, and there are
no strict constraints on what the IPv6 packet may contain. Thus,
addresses within the IPv4, and IPv6 header may be spoofed, and this
property leads to various types of threats including DoS, and
reflection DoS.
The 6to4 specification outlined quite a few security considerations, The 6to4 specification outlined quite a few security considerations,
but it has been shown that in practice some of these have been but it has been shown that in practice some of them have been
difficult to get implemented due to their abstract nature. difficult to get implemented due to their abstract nature.
This draft analyses the 6to4 security issues in more detail and This draft analyzes the 6to4 security issues in more detail and
outlines some enhancements and caveats. outlines some enhancements and caveats.
Sections 2-4 are more or less introductory in nature, rehashing how Section 2, and Section 3 are more or less introductory in nature,
6to4 should be used today based on the 6to4 specification, so that it rehashing how 6to4 is used today based on the 6to4 specification, so
is easier to understand how security could be affected. Section 5 that it is easier to understand how security could be affected.
provides a threat analysis for implementations that already implement Section 4 provides a threat analysis for implementations that already
most of the security checks. Section 6 introduces some filtering implement most of the security checks. Section 5 introduces some
rules for 6to4 implementations, and section 7 discusses some filtering rules for 6to4 implementations, and Section 6 provides
additional problems which still need some consideration. Appendix A further discussion on a few issues which have proven to be difficult.
outlines a few possible trivial attack scenarios in the case that Appendix A outlines a few possible trivial attack scenarios in the
very little or no security has been implemented. case that very little or no security has been implemented.
For the sake of simplicity, in this document, native IPv6 Internet is
assumed to encompass IPv6 networks formed using other transition
mechanisms (e.g. RFC 2893 [4]), as these mechanisms cannot talk
directly 6to4 network.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in RFC 2119 [2].
2. Different 6to4 Forwarding Scenarios 2. Different 6to4 Forwarding Scenarios
It should be noted that when communicating between 6to4 and native It should be noted that when communicating between 6to4 and native
domains, the relays that will be used in the two directions are very domains, the 6to4 relays that will be used in the two directions are
likely different; routing is highly asymmetric. Because of this, it very likely different; routing is highly asymmetric. Because of
is not feasible to limit relays you accept traffic from with e.g. this, it is not feasible to limit relays from which 6to4 routers may
access lists. accept traffic.
The first three subsections introduce the most common forms of 6to4 The first three subsections introduce the most common forms of 6to4
operation. Other models are presented in the fourth subsection. operation. Other models are presented in the fourth subsection.
2.1. From 6to4 to 6to4 2.1 From 6to4 to 6to4
6to4 domains always exchange 6to4 traffic directly via IPv4 6to4 domains always exchange 6to4 traffic directly via IPv4
tunneling; the endpoint address V4ADDR is derived from 6to4 prefix tunneling; the endpoint address V4ADDR is derived from 6to4 prefix
2002:V4ADDR. 2002:V4ADDR::/48 of the destination.
.--------. _----_ .--------. .--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 | | 6to4 | _( IPv4 )_ | 6to4 |
| Router | <====> ( Internet ) <===> | Router | | router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------' '--------' (_ _) '--------'
^ '----' ^ ^ '----' ^
| Direct tunneling over IPv4 | | Direct tunneling over IPv4 |
V V V V
.--------. .-------. .--------. .-------.
| 6to4 | | 6to4 | | 6to4 | | 6to4 |
| Client | | Client | | host | | host |
'--------' '--------' '--------' '--------'
Figure 1
It is required that every 6to4 router considers every other 6to4 It is required that every 6to4 router considers every other 6to4
router it wants to talk to to be "on-link" (with IPv4 as the link- router it wants to talk to to be "on-link" (with IPv4 as the
layer). If this is restricted by increasing the prefix length from link-layer).
2002::/16, some traffic will be sent to the 6to4 Relay Router, which
would forward it to other 6to4 Routers. However, if the original
destination does not have equally long prefix, the traffic it tries
to send back will be tunneled directly, and will be dropped.
Therefore, the restricted scenario with a longer prefix-length is not 2.2 From Native to 6to4
globally workable and will not be considered here.
2.2. From Native to 6to4 When native domains send traffic to 6to4 prefix 2002:V4ADDR::/48, it
will be routed to the topologically nearest, advertising (advertising
route to 2002::/16) 6to4 relay. The 6to4 relay will tunnel the
traffic over IPv4 to the corresponding IPv4 address V4ADDR.
When native domains send traffic to 6to4 address 2002:V4ADDR, it will Note that IPv4 address 9.0.0.1 here is just an example of a global
be routed to the topologically nearest, advertising 6to4 Relay IPv4 address, and it is assigned to the 6to4 router's
Router. Relay router will tunnel the traffic over IPv4 to the pseudo-interface.
corresponding IPv4 address V4ADDR. (Note that IPv4 address 9.0.0.1
here is just an example of a global IPv4 address.)
2002::/16 Closest to 'Native Client' Closest to
"Native IPv6 node"
.--------. _----_ .------------. .--------. .--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 Relay | Tunneled | 6to4 | | Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| Client | -> ( Internet ) --> | Router | =========> | Router | | IPv6 | -> ( Internet ) --> | router | =========> | router |
'--------' (_ _) '------------' 9.0.0.1 '--------' | node | (_ _) '------------' 9.0.0.1 '--------'
'----' dst=2002:0900:0001::1 | '--------' '----' dst_v6=2002:0900:0001::1 |
V V
.-------. .-------.
| 6to4 | | 6to4 |
| Client | | host |
'--------' '--------'
2.3. From 6to4 to Native Figure 2
2.3 From 6to4 to Native
6to4 domains send traffic to native domains by tunneling it over IPv4 6to4 domains send traffic to native domains by tunneling it over IPv4
to their configured 6to4 Relay Router, or the closest found using to their configured 6to4 relay router, or the closest one found using
6to4 IPv4 Anycast [6TO4ANY]. The relay will decapsulate the packet 6to4 IPv4 Anycast [3]. The relay will decapsulate the packet and
and forward it to native IPv6 Internet, the same way as any other forward it to native IPv6 Internet, the same way as any other IPv6
IPv6 packet. packet.
Configured/found by IPv4 Anycast Note that destination IPv6 address in the packet is a non-6to4
address, and is assumed to be 2001:db8::1 in the example.
Configured
-or-
found by IPv4 Anycast
.--------. _----_ .------------. .--------. .--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 Relay | Tunneled | 6to4 | | Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| Client | <- ( Internet ) <-- | Router | <========= | Router | | Client | <- ( Internet ) <-- | router | <========= | router |
'--------' (_ _) '------------' 192.88.99.1'--------' '--------' (_ _) '------------' 192.88.99.1'--------'
'----' (or configured) ^ 2001:db8::1 '----' (or configured) ^
dst=3ffe:ffff::1 | |
.-------. .-------.
| 6to4 | | 6to4 |
| Client | | client |
'--------' '--------'
2.4. Other Models Figure 3
These are more or less special cases of 6to4 operation; in later 2.4 Other Models
These are more or less special cases of 6to4 operations. In later
chapters, unless otherwise stated, only the most generally-used chapters, unless otherwise stated, only the most generally-used
models (above) will be considered. models (above) will be considered.
2.4.1. BGP Between 6to4 Routers and Relays 2.4.1 BGP Between 6to4 Routers and Relays
[6TO4, 5.2.2.2] presents a model where, instead of static Section 5.2.2.2 in [1] presents a model where, instead of static
configuration, BGP4+ is used between 6to4 Relay Routers and 6to4 configuration, BGP [5] is used between 6to4 relay routers and 6to4
Routers. routers.
If the 6to4 router established a BGP session between all the possible If the 6to4 router established a BGP session between all the possible
6to4 relays, the traffic from non-6to4 sites would always go through 6to4 relays, and advertised its /48 prefix to them, the traffic from
"home relay", and configuring "trusted relay" would not be a problem; non-6to4 sites would always come from a "known" relay.
an alternative would be to advertise the more specific 6to4 routes Alternatively, the 6to4 relays might advertise the more specific 6to4
between 6to4 Relays, as described later in this memo. routes between 6to4 relays, as described in Section 6.2.1 in this
memo.
This model is not known to be used at the time of writing; this is Neither of these models are known to be used at the time of writing;
probably caused by the fact that parties that need 6to4 are those this is probably caused by the fact that parties that need 6to4 are
that are not able to run BGP, and because setting up these sessions those that are not able to run BGP, and because setting up these
would be much more work for relay operators. sessions would be much more work for relay operators.
2.4.2. 6to4 as an Optimization Method 2.4.2 6to4 as an Optimization Method
Some seem to use 6to4 as an IPv6 connectivity "optimization method"; Some sites seem to use 6to4 as an IPv6 connectivity "optimization
that is, they have also non-6to4 addresses on their nodes and border method"; that is, they have also non-6to4 addresses on their nodes
routers, but also employ 6to4 to reach 6to4 sites. and border routers, but also employ 6to4 to reach 6to4 sites.
This is typically done to be able to reach 6to4 destinations by This is typically done to be able to reach 6to4 destinations by
direct tunneling and not having to use relays at all. direct tunneling and not having to use relays at all.
Some also publish both 6to4 and non-6to4 addresses in DNS to affect These sites also publish both 6to4 and non-6to4 addresses in DNS to
inbound connections; if the source host's default address selection affect inbound connections; if the source host's default address
[ADDRSEL] works properly, 6to4 sources will use 6to4 addresses to selection [6] works properly, 6to4 sources will use 6to4 addresses to
reach the site and non-6to4 nodes use non-6to4 addresses. If this reach the site and non-6to4 nodes use non-6to4 addresses. If this
behaviour of foreign nodes can be assumed, the security threats to behavior of foreign nodes can be assumed, the security threats to
such sites can be significantly simplified. such sites can be significantly simplified.
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism 2.4.3 6to4 as Tunnel End-Point Addressing Mechanism
6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel 6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel
endpoint addressing and routing mechanism. endpoint addressing and routing mechanism.
An example of this is interconnecting 10 branch offices where nodes An example of this is interconnecting 10 branch offices where nodes
use non-6to4 addresses. Only the offices' border routers need to be use non-6to4 addresses. Only the offices' border routers need to be
aware of 6to4, and use 6to4 addresses solely for addressing the aware of 6to4, and use 6to4 addresses solely for addressing the
tunnels between different branch offices. This assumes that all tunnels between different branch offices. An example is provided in
outgoing traffic from the main organization (but not between branch the figure below.
offices) uses one or more non-6to4 connections.
This is similar to the optimization model above, and can be used to 2001:db8:0:10::/60 2001:db8:0:20::/60
make the addressing and routing easier. .--------. .--------.
( Branch 1 ) ( Branch 2 )
'--------' '--------'
| |
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
9.0.0.1 '----' 8.0.0.2
^^
||
vv
.--------.
| 6to4 | 7.0.0.3
| router |
'--------'
| 2001:db8::/48
.-----------.
( Main Office )
'-----------'
^
|
v
_----_
_( IPv6 )_
( Internet )
(_ _)
'----'
3. Some Functionalities of 6to4 Figure 4
In this section, some, relatively obvious features of different 6to4 In the figure, the main office sets up two routes:
components are listed to better undestand what's the required
behaviour.
3.1. Functions of Different 6to4 Network Components 2001:db8:0:10::/60 -> 2002:0900:0001::1
o Non-6to4 (Native) Node 2001:db8:0:20::/60 -> 2002:0800:0002::1
If native IPv6 nodes want to communicate with 6to4 nodes, And a branch office sets up two routes as well:
they send the traffic along normally. The traffic will
reach the topologically closest, advertising 6to4 Relay
Router, and will be tunneled to the destination 6to4 Router,
which will pass it to the 6to4 node via normal forwarding
process.
o 6to4 Host 2001:db8:0:20::/60 -> 2002:0800:0002::1
A host, usually autoconfigured, that has an address from a default -> 2002:0700:0003::1
6to4 prefix, but doesn't have a 6to4 pseudo-interface. It
doesn't need to know anything about 6to4, and it acts like a
normal IPv6 Host in every manner. Note that 6to4 Hosts can
also be 6to4 Routers in some scenarios, but then 6to4 Router
functionalities, below, apply.
o 6to4 Router Thus, the IPv4 Internet is treated as NBMA link-layer for
interconnecting 6to4-enabled sites; with explicit routes, 6to4
addressing need not be used in other than the 6to4 edge routers.
However, note that if a branch office sends a packet to any 6to4
destination, it will not go through the main office as the 6to4
2002::/16 route overrides the default route.
Acts at the border of a 6to4 domain. It does not have a This approach may make addressing and routing slightly easier in some
native, global IPv6 address. More specifically: circumstances.
- provide "native-like" IPv6 connectivity to local clients 3. Functionalities of 6to4 Network Components
and routers
- if packets are sent to foreign 6to4 addresses, tunnel
them to the destination 6to4 router using IPv4
- if packets are sent to locally configured 6to4
addresses, forward them normally
- if packets are sent to non-6to4 addresses, tunnel them
to the configured/closest-by-anycast 6to4 Relay Router,
which will pass them on
- if packets are received from 6to4 addresses, decapsulate
the IPv4 packets received from 6to4 routers
- if packets are received from non-6to4 addresses,
decapsulate the IPv4 packets received from 6to4 Relay
Router closest to the source (note: it is not easily
distinguishable that the packet was really received from
a Relay router, not from a spoofing third party.)
o 6to4 Relay Router This section summarizes the main functionalities of the 6to4 network
components (6to4 routers, and 6to4 relays), and the security checks
that must be done by them. The pseudo-code for the security checks is
provided in Section 5.
Acts as a relay between all 6to4 domains and native IPv6; This section summarizes the main functions of the various components
more specifically: that are part of a 6to4 network - 6to4 relay routers, and 6to4
routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4 related
definitions.
- advertises the reachability of the 2002::/16 prefix to 3.1 6to4 Routers
native IPv6 routing, thus receiving traffic to all 6to4
addresses from closest native IPv6 nodes
- (if implements RFC3068) advertise 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
- if packets are received from 6to4 addresses through
tunneling, decapsulate them and forwards them on using
normal IPv6 routing
- if packets are received through normal IPv6 routing from
native addresses, and are destined for 2002::/16, tunnel
them to the corresponding 6to4 Router
3.2. Non-functions of Different 6to4 Network Components The 6to4 routers acts as the border router of a 6to4 domain. It does
not have a native, global IPv6 address. The main functions of the
6to4 router are:
What should not happen; this forms a basis for the security checks. o Provide IPv6 connectivity to local clients and routers.
The lists are not exhaustive.
o 6to4 Router or Relay o Tunnel packets sent to foreign 6to4 addresses to the destination
- use private, broadcast or reserved IPv4 addresses in tunnels, 6to4 router using IPv4.
or the matching 6to4 prefixes
- receive traffic from 6to4 Routers where the IPv4 tunnel
source address does not match the 6to4 prefix
- receive traffic where the destination IPv6 address is not a
global address; in particular, e.g. link-local addresses,
mapped addresses and such should not be used
o 6to4 Router
- send traffic to other 6to4 domains through 6to4 Relay Router
or via some third party 6to4 Router
- receive traffic from other 6to4 domains via a 6to4 Relay
Router
- receive traffic to other than to your own 6to4 prefix(es)
o 6to4 Relay Router
- receive traffic from 6to4 to 6to4
4. Special Processing of 6to4 Packets o Forward packets sent to locally configured 6to4 addresses to the
6to4 network.
One could summarize the special processing of 6to4 as follows: o Tunnel packets sent to non-6to4 addresses, to the configured/
closest-by-anycast 6to4 relay router.
o Relay Router o Decapsulate directly received IPv4 packets from foreign 6to4
1. incoming from native, tunneled to 6to4 addresses.
2. tunneled from 6to4, going to native
o Router o Decapsulate IPv4 packets received via the relay closest to the
1. tunneled from relay, source is native native IPv6 sources. Note, it is not easily distinguishable that
2. tunneled to relay, destination is native the packet was really received from a 6to4 relay router, not from
3. tunneled directly, destination is 6to4 a spoofing third party.)
4.1. Encapsulating IPv6 Packets into IPv4 The 6to4 router will also perform security checks on traffic that it
will receive from other 6to4 relays, or 6to4 routers, or from within
the 6to4 site. These checks include:
IPv6 packets are encapsulated into IPv4 in three scenarios: o Disallow traffic that has private, broadcast or reserved IPv4
addresses in tunnels, or the matching 6to4 prefixes.
1. 6to4 Router sends packets to other 6to4 Routers (2002::/16 o Disallow traffic from 6to4 routers where the IPv4 tunnel source
destination) address does not match the 6to4 prefix.
2. 6to4 Router sends packets to its configured/nearest-by-anycast
6to4 Relay Router (non-2002::/16 destination)
3. 6to4 Relay Router sends packets from native IPv6 sources to
6to4 Routers (2002::/16 destination)
4.2. Decapsulating IPv4 Packets into IPv6 o Disallow traffic where the destination IPv6 address is not a
global address; in particular, e.g. link-local addresses, mapped
addresses and such should not be used.
IPv6 packets are decapsulated from IPv4 in three scenarios: o Disallow traffic transmission to other 6to4 domains through 6to4
relay router or via some third party 6to4 router.
1. 6to4 Router receives packets from other 6to4 Routers (2002::/16 o Discard traffic received from other 6to4 domains via a 6to4 relay
source) router.
2. 6to4 Router receives packets from a node, supposedly 6to4 Relay
Router closest to the source (non-2002::/16 source)
3. 6to4 Relay Router receives packets from 6to4 Routers, to be
sent to native IPv6 destinations (2002::/16 source)
5. Threat Analysis o Discard traffic received for prefixes other than self 6to4
prefix(es).
The 6to4 threat analysis presented here focuses on 6to4 3.2 6to4 Relay Routers
implementations which have implemented most if not all security
checks listed in [6TO4]; in particular, checks that always match
2002:V4ADDR and V4ADDR must be implemented. Many implementations are
known to be problematic at least in some cases.
The appendix lists some additional trivial threats which are The 6to4 relay router acts as a relay between all 6to4 domains and
applicable if no or only little security is implemented. native IPv6 networks; more specifically:
The IPv4 address blocks 8.0.0.0/24 and 9.0.0.0/24 are only used for o It advertises the reachability of the 2002::/16 prefix to native
demonstrative purposes, representing global IPv4 addresses. IPv6 routing, thus receiving traffic to all 6to4 addresses from
closest native IPv6 nodes.
5.1. Threats Related to Any 6to4 Node o Advertise (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.
Any 6to4 node can be made to participate in a DoS attack listed in o Decapsulate, and forward packets received from 6to4 addresses
5.2.2 below, being used as "dst". The threat will be discussed through tunneling, using normal IPv6 routing.
there.
5.2. Threats Related to 6to4 Routers o Tunnels packets received through normal IPv6 routing from native
addresses, and are destined for 2002::/16, to the corresponding
6to4 router.
Note that in this memo, a loose interpretation of "6to4 router" is The 6to4 relay will also perform security checks on traffic that it
used; it is used to refer to those all nodes which have the 6to4 will receive from 6to4 routers, or from native IPv6 nodes. These
pseudo-interface. checks are:
There are two main classes of threats; attacks against the 6to4 o Disallow traffic that has private, broadcast or reserved IPv4
pseudo-interface and attacks relying on being able to abuse the fact addresses in tunnels, or the matching 6to4 prefixes.
that it is difficult for 6to4 routers to tell whether packets from
non-6to4 nodes come from legitimate relays.
5.2.1. Attacks Against the 6to4 Pseudo-Interface o Disallow traffic from 6to4 routers where the IPv4 tunnel source
address does not match the 6to4 prefix.
Unless the 6to4 pseudo-interface has been sufficiently protected, o Disallow traffic where the destination IPv6 address is not a
it's possible to remotely attack the pseudo-interface with tunneled global address; in particular, e.g. link-local addresses, mapped
link-local packets, just as if it were in a local network. Threats addresses and such should not be used. Note, this check might be
to Neighbor Discovery are listed in [SEND]. incorrect if 6to4 were to be used.
The potential effects of an attack can be mitigated if the interface o Discard traffic received from 6to4 routers with the destination as
is insulated from the other interfaces (e.g. a separate neighbor a 6to4 prefix.
cache). In practise, this is not the case.
The attack can be eliminated by restricting the use of 6to4 pseudo- 4. Threat Analysis
interface: if any packet with scope smaller than global is received,
it must be silently discarded. ("Local addresses", if specified,
might be allowed in some restricted scenarios.) This may conflict
with future uses of [6TO4, 3.1].
5.2.1.1. Comparison to Situation without 6to4 This section discusses attacks against the 6to4 network or attacks
that are caused by the 6to4 network. The threats are discussed in
light of the 6to4 deployment models defined in the Section 2.
Even though rather simply fixable, this attack is not new as such; There are three general types of threats:
the same is possible using automatic tunneling [MECH] or configured
tunneling (if one is able to spoof source IPv4 address to that of the
tunnel end-point).
However, as automatic tunneling is being deprecated, the worst 1. Denial-of-Service (DoS) attacks, in which a malicious node
problem comes from 6to4; any open decapsulation is bad. prevents communication between the node under attack and other
nodes.
5.2.2. Relay Spoofing, DoS against IPv6 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) with the intent of preventing
communication between the node under attack and other nodes.
6to4 Routers receive packets from non-6to4 source addresses through 3. Service theft, in which a malicious node/site/operator may make
Relay Routers, as described in section 2.2 and 4.2 point 2. unauthorized use of service.
In the general case, the 6to4 router cannot distinguish Relay routers 6to4 also provides a means for a "meta-threat", traffic laundering,
from malicious nodes sending IPv4-encapsulated IPv6 traffic directly in which some other attack is channeled through the third parties to
to the 6to4 router. make it more difficult to trace the real origin of the attack. This
is used in conjunction with other threats, whether specific to 6to4
or not.
This makes two kinds of attacks possible: At this point it is important to reiterate that the attacks are
possible because:
o unidirectional source address spoofing, and 1. 6to4 routers have to consider all 6to4 relays, and other 6to4
o Denial-of-Service attack reflection against native IPv6 nodes. routers as "on-link".
In both scenarios, the attacker sends IPv4-encapsulated IPv6 packets 2. 6to4 relays have to consider all 6to4 routers as "on-link".
to the 6to4 router with contents like:
src = 3ffe:1122:3344::1 (forged) 3. Partial implementation of the security checks in the 6to4
dst = 2002:0900:0002::1 implementation. It has been discovered that at least a couple of
src_v4 = 8.0.0.1 major implementations do not implement all the checks.
dst_v4 = 9.0.0.2 (matching dst)
Now the 6to4 router receives these packets from 8.0.0.1, decapsulates The attacks descriptions are classified based on the target of the
them, discarding the IPv4 header containing the source address attack:
8.0.0.1 and processes them as normal ("dst" has been guessed or
obtained using one of a number of techniques).
In the first scenario, it is assumed that "src" is somehow specially 1. Attacks on 6to4 networks.
trusted (at least to some extent) more than some other packets. This
kind of weak trust based on IP addresses is commonplace. This
enables unidirectional (as the replies will be lost) source address
spoofing, but may be enough for e.g. exploiting some remote
vulnerabilities in connectionless protocol server applications.
In the second scenario, if "dst" exists, the replies (e.g. TCP SYN 2. Attacks on IPv6 networks.
ACK, TCP RST, ICMP Echo Reply, input sent to UDP echo service, etc.)
are sent to the victim "src", above. All the traces from the
original attacker src_v4 have been discarded. These return packets
will go through a relay.
These attacks are similar to ones shown in [RHHASEC]. 3. Attacks on IPv4 networks.
5.2.2.1. Comparison to Situation without 6to4 Note, the IPv4 address blocks 8.0.0.0/24 and 9.0.0.0/24 are only used
for demonstrative purposes, and represent global IPv4 addresses.
The unidirectional spoofing attack exists without 6to4 too, but it Note, one of the mitigation methods listed for various attacks is
requires the attacker is able to spoof IPv6 source addresses. With based on the premise that 6to4 relays will a have a feature that may
6to4, one is able to launch this attack without any spoofing at all. be able to limit traffic to/from specific 6to4 sites. At the time of
A restriction is that the source address cannot be spoofed to belong writing this document, such a feature is speculation, and more work
to the destination site as only non-6to4 addresses can be spoofed needs to be done to determine the logistics of such a feature.
(assuming correct implementations). Blindly trusting source address
of packets coming from the Internet without other precautions is very
bad practise, though -- and this attack would typically be useful
only for spoofing destination site -- which is not possible, and can
be protected against with egress filtering.
The Denial-of-Service attack is also not really new; the only twists 4.1 Attacks on 6to4 Networks
come from the fact that traces of an attack are more easily lost and
that attacker does not really have to even spoof his IPv4 address to
be able to reasonably discreetly launch the attack.
However, it can be argued that this DoS attack is not critical This section describes attacks against 6to4 networks. Attacks which
because: legerate 6to4 networks, but where the ultimate victim is elsewhere
(e.g., a native IPv6 user, an IPv4 user) are described later in the
memo.
o 6to4 as an enabling mechanism does not provide any possibility 6to4 relays and routers are IPv4 nodes, and there is no way for any
for packet multiplication, attacks are generally 1:1, 6to4 router to confirm the identity of the IPv4 node from which it is
o victim receives packets as replies from "dst": unless echo receiving traffic -- whether it is a legitimate 6to4 relay or some
service (e.g. UDP port 7) is used, the attacker has reasonably other node. A 6to4 router has to process traffic from all IPv4
little control on the content of packets; for example, pure "SYN" nodes. Malicious IPv4 nodes can exploit this property and attack
TCP packets often used for flooding cannot be sent, nodes within the 6to4 network.
o attack packets pass through choke point(s), namely (one or more)
6to4 relays; in addition to physical limitations, these could
implement some form 6to4-site-specific traffic limiting, and
o one has to know a valid destination address (however, this is
easily guessable or deducible with e.g. an ICMP echo request with
a limited Hop Count).
The attack can be launched from hosts whose connection is ingress- It is possible to conduct a variety of attacks on the 6to4 nodes.
filtered, too. So, this enables a way to launch attacks which hide These attacks are:
the source address even when it was supposed to be prevented (for
IPv4). 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 all the other 6to4 routers, and 6to4
relays are "on-link" it is possible to attack the 6to4 router using
ND messages from any node in the IPv4 network, unless a prior trust
relationship has been established.
The attacks are targeting 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 these use link-local addresses.
These attacks are exacerbated in case the implementation supports
more tunneling mechanisms than just 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 [7]. 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, one should 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. It 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 (for example, using a separate neighbor cache).
o Either IPsec [4] or an extension of SEND could be used [8] to
secure packet exchange using 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 fixable, this attack is not new as such;
the same is possible 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 [9], 6to4 provides an easy means which would not
exist without 6to4.
4.1.2 Spoofing Traffic to 6to4 Nodes
ATTACK DESCRIPTION
The attacker - a malicious IPv4 or IPv6 node - can send packets with
spoofed source address to a 6to4 node to accomplish a DoS attack.
The IPv6 and IPv4 addresses of the packets will be similar to:
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 or the real
source address.
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" using one of a number of techniques).
This is a DoS attack on 6to4 nodes.
This attack is similar to ones shown in [10].
EXTENSIONS
Replies to the traffic will be directed to the src_v6 address,
resulting in 6to4 nodes in participating in a reflection DoS. This
attack is described in more detail in Section 4.2.3. That is, the
replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to
UDP echo service, ICMPv6 Destination Unreachable, etc.) 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 by the fact that
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. Since traces to the src_v4
address can easily be lost, these attacks can also be be launched
from IPv4 nodes whose connection is ingress-filtered.
However, often this is not a real factor, as usually the attackers However, often this is not a real factor, as usually the attackers
are just zombies and real attackers may not even care if the are just zombies and real attackers may not even care if the
unspoofed source address is discovered. unspoofed source address is discovered.
This is one of the most serious threats. Malicious native IPv6 nodes could be caught easily if ingress
filtering was enabled everywhere in the IPv6 Internet.
5.3. Threats Related to 6to4 Relays These attacks are easy to perform, but the extent of harm is limited:
6to4 Relays are also subject to attacks, but usually in a different o For every packet sent, at most one reply packet is generated:
role than 6to4 Routers; usually Relays' function is the anonymization there is no amplification factor.
of the attack and losing trails, not reflection -- as properly
implemented relays should be resistant to reflection.
6to4 Relays have only one significant security check they must 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 attack serious:
o The attacker may have the ability to choose the relay, and he
might employ the ones best suited for the attacks. Also, some
relays use 192.88.99.1 [3] as the source address making tracing
even more difficult.
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:
1. Ingress filtering in the native IPv6 networks to prevent packets
with spoofed IPv6 source being transmitted. It would, thus, make
it easy to identify the source of the attack.
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.
However, these mitigation methods do not address the case of IPv4
node sending encapsulated IPv6 packets.
There exists no simple way to prevent such attacks, and longer term
solutions like ingress filtering [11] or itrace [12] have to be
deployed in both IPv6 and IPv4 networks to help identify the source
of the attacks.
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 to be 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 the Section 4.2.2) may be sent to
native IPv6 nodes with the aim of performing 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 look like:
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)
One should 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 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 being launched) will filter packets with forged source
address (with security checks mentioned in Section 5), and thus the
attack will be prevented.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The reverse traffic in this case are replies to the messages received
by the 6to4 nodes. The attacker has less control on the packet type
in this case, 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 countered in various ways:
o Implementation of ingress filtering by the IPv4 service providers.
It would prevent forging of the src_v4 address, and would 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 is not
done by the 6to4 router, or if a large number of 6to4 nodes, and/
or a large number of IPv4 nodes are participating in the attack.
o Implementation of ingress filtering by all IPv6 service providers
would eliminate this attack, because src_v6 could not be spoofed
to be 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 the attack, when
launched from an IPv4 node, except when the IPv4 source address
was also spoofed -- but then the attacker would have been able to
just 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 and ingress filtering; where ingress filtering is not
implemented, it's typically easier to attack directly than through
reflection -- unless "traffic laundering" is an explicit goal in 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 it tries to send encapsulated IPv6 packets to a
local broadcast address, or a multicast address. This threat is
mentioned in the specification [1].
There practically two kinds of attacks: where a local 6to4 user tries
to send packets to the address corresponding to the broadcast
address, or when someone is able to do that remotely.
In the first option, assume that 9.0.0.255 is the 6to4 router's
broadcast address. After receiving the packet with a destionation
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 will 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, for example 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
been (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 to an IPv6 address that embeds an invalid IPv4 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's 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 which haven't been secured as described in Section 5.
4.2 Attacks on Native IPv6 Internet
This section describes attacks against native IPv6 Internet which
leverage 6to4 architecture somehow. Attacks against 6to4 nodes were
described in the previous section.
Native IPv6 nodes can be accessed by 6to4 and IPv4 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, check perform for general safety: when decapsulating IPv4 packets, check
that 2002:V4ADDR and V4ADDR match. If this is not done, several that 2002:V4ADDR::/48 and V4ADDR match. If this is not done, several
threats become more serious; in the following, it's assumed that such threats become more serious; in the following analysis, it is assumed
checks are always done. that such checks are implemented.
Also, it is assumed here that the Relay checks that it will not relay 6to4 relay should not relay packets between 6to4 addresses. In
packets between 6to4 addresses. In particular, packets decapsulated particular, packets decapsulated from 6to4 routers should not be
from 6to4 routers cannot be encapsulated again towards 6to4 routers, encapsulated again towards 6to4 routers, as described in rules in
as descibed in rules in section 6. It is not clear whether this kind Section 5. Similarly, packets with 6to4 source and destination
of check is typically implemented. address 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.
5.3.1. Attacks Against the 6to4 Pseudo-Interface 4.2.1 Attacks with ND Messages
The threats are the same as against 6to4 routers. These attacks are the same as employed against 6to4 routers as
described in Section 4.1.1.
5.3.2. Spoofing, DoS against IPv6 Nodes 4.2.2 Spoofing Traffic to Native IPv6 node
If one cannot assume that IPv6 source addresses are ingress-filtered, ATTACK DESCRIPTION
the same threats as listed in 5.2.2 apply.
The difference here is that a native IPv6 node spoofs the source IPv6 The attacker - a malicious IPv4 or 6to4 node - can send packets with
addresses, and the relay router provides a layer of indirection and spoofed (or not spoofed) 6to4 source address to a native IPv6 node to
loses the trails. accomplish a DoS attack.
5.3.3. Participating in DoS attacks against IPv4 The threat is similar as the one involving 6to4 routers as described
in Section 4.1.2.
An attack specific to 6to4 Relays is similar to 6to4 Routers, but The difference here is that the attack is initiated by IPv4 nodes, or
against IPv4; the attacker sends IPv6-native packets with an IPv4 6to4 nodes. The source IPv6 address may or may not be spoofed. Note,
address he wants to bomb as the 6to4 destination address, like: as mentioned above, the relay is assumed to correlate source IPv4
address with the address embedded in the source IPv6 address during
decapsulation. A side effect is that all the spoofed traffic will
have a 6to4 source address.
src = 3ffe:1122:3344::1 (spoofed or real attacker) EXTENSIONS
dst = 2002:0900:0002::1 (victim)
Now the 6to4 relay receives these packets, and encapsulates in IPv4 Spoofed traffic may also be sent to native IPv6 nodes by either other
packets that are sent towards 9.0.0.2; the destination may not have a native IPv6 nodes, or 6to4 nodes, or malicious IPv4 nodes to conduct
faintest idea of what IPv6 is, but is bombed with packets coming from Reflection DoS on either native IPv6 nodes or 6to4 nodes.
the relay's IPv4 address, including IPv6 packets as the payload.
5.3.3.1. Comparison to Situation without 6to4 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 the
fact that the replies from the 6to4 node to the spoofed address will
be lost.
Slightly different arguments apply; below are reasons why this can be THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
considered not too serious an attack:
o 6to4 as an enabling mechanism does not provide any possibility The Denial-of-Service attack based on traffic spoofing is not new;
for packet multiplication, attacks are generally 1:1, the only twist comes from the fact that traces of an attack are more
o victim receives packets as sent by the source; if the victim is easily lost. The 6to4 relay typically does not log IPv4 addresses
an IPv4-only node, it just sees "protocol 41" packets which are (as they would be treated as L2 addresses) and thus the source of the
not typically dangerous and easily filtered, attack (if launched from an IPv4 node) is lost. Since traces to the
o 6to4 relay's source IPv4 address is used in packets, and tracing src_v4 address can easily be lost, these attacks can also be be
is easier, launched from IPv4 nodes whose connection is ingress-filtered.
o source IPv6 address (spoofed or real) is in the packets which may
make manual tracing easier, and
o attack packets pass through choke point(s), namely (one or more)
6to4 relays; in addition to physical limitations, these could
implement some form 6to4-site-specific traffic limiting.
And as counter-arguments, some more serious aspects of it are: These attacks might be not be very easy to perform, and might be
hampered because of:
o victim receives packets as sent by the source; if the victim is o It might be difficult to launch such attacks from 6to4 nodes
6to4 node, IPv6 packet can include almost anything; however if because even if the 6to4 routers allow spoofing of the source IPv6
IPv6 source addess is not spoofed, this attack is nothing new, address, the 6to4 relay would check if source V4ADDR is same as
o the relays can be chosen by the attacker, so if there are a large the one embedded in the source IPv6 address. Thus, 6to4 nodes
number of relays, he can pick ones that are known best suited for will be forced to use the correct IPv6 prefix while lauching
the attack (e.g. bad security policy, ones using 192.88.99.1 as attack, and it is easy to close such attacks.
source for more difficult tracing, etc.), and
o the relay's IPv4 address is used as a source address for these
attacks, potentially causing a lot of complaints or other actions
as the relay seems to be the source of this "attack".
5.3.4. Using Any IPv6 Node for Reflection o Packets may pass through choke point(s), namely a 6to4 relay. In
addition to physical limitations, there could be some sort of
traffic rate limiting mechanisms which may be implemented, and it
could tone down the attack.
Any IPv6 node will respond to IPv6 packets destined to the node with o For every packet sent, at most one reply packet is generated:
source address belonging to 2002::/16. there is no amplification factor.
This attack is applicable if: Some of the mitigation methods for such attacks are:
o the relay chosen by the attacker does not check that IPv4 source 1. Ingress filtering in the IPv4 Internet to prevent packets with
and 2002::/16 source address match, or spoofed IPv4 source being transmitted. As the relay checks that
o the attacker's IPv6 connection is not ingress-filtered (and it the 6to4 address embeds the IPv4 address, no spoofing can be
was really a non-6to4 source). achieved done unless IPv4 addresses can be spoofed.
The IPv6 source address being forged, the node will participate as an 2. Security checks in the 6to4 relay. The 6to4 relay must drop
unwilling intermediary to an attack through a 6to4 relay against any traffic (from 6to4 nodes, or IPv4 nodes) that has non-6to4
IPv4 node (or 6to4 node), like: addresses as source address, or where the source IPv4 address
does not match the address embebdded in the source IPv6 address.
src = 2002:0900:0002::1 (forged, target of the attack) COMPARISON TO SITUATION WITHOUT 6to4
dst = 3ffe:1122:3344::1 (intermediary node)
This is not new: similar attack with any other spoofed source address Compared to Section 4.1.2, which is more serious, this threat appears
is possible if ingress filtering is not enabled. The only difference to be slightly more manageable. If the relays perform proper
here is that when attacking IPv4 nodes, the relay's IPv4 source decapsulation checks, the spoofing can only be achived, to a 6to4
address is seen as the immediate source of the attack. Closer source address, when IPv4 address is spoofable as well.
inspection (after packet reflection) reveals the IPv6 datagram with
(possibly spoofed) 2002::/16 destination address.
5.3.4.1. Comparison to Situation without 6to4 4.2.3 Reflecting Traffic to Native IPv6 nodes
This attack is a reflected variation of the attack above; the ATTACK DESCRIPTION
implications are similar to those in section 5.2.2.1:
o A non-compliant 6to4 implementation or IPv6 source address These reflection attacks are similar to the one involving 6to4
spoofing is required, routers as described in Section 4.1.3. Traffic may be reflected off
o 6to4 as an enabling mechanism does not provide any possibility native IPv6 nodes, or 6to4 nodes. The attack can be initiated by
for packet multiplication, attacks are generally 1:1, either:
o victim receives packets as replies from "dst": unless echo
service (e.g. UDP port 7) is used, the attacker has reasonably
little control on the content of packets; for example, pure "SYN"
TCP packets often used for flooding cannot be sent,
o attack packets pass through choke point(s), namely (one or more)
6to4 relays; in addition to physical limitations, these could
implement some form 6to4-site-specific traffic limiting, and
o the relay's IPv4 address is used as a source address for these
attacks, potentially causing a lot of complaints or other actions
as the relay seems to be the source of this "attack".
5.3.5. IPv4 Local Directed Broadcast Attacks o Native IPv6 nodes. These nodes can send invalid traffic with
spoofed native IPv6 addresses to valid 6to4 nodes. Replies from
the 6to4 nodes are part of a reflection attack.
This threat is applicable if the relay does not check whether the o IPv4 nodes. These nodes can send traffic with native IPv6 source
IPv4 address it tries to send encapsulated IPv6 packets to is a local addresses (encapsulated by the IPv4 node itself into a protocol-41
broadcast address. This threat is mentioned in [6TO4]. The packet packet) to 6to4 nodes. Replies from the 6to4 nodes are part of a
could be sent as follows: reflection attack.
src = 3ffe:ffff:5678::aaaa (may be forged) o 6to4 nodes. These nodes can perform similar attacks to the ones
dst = 2002:0900:00ff::bbbb by IPv4 nodes, but that would require spoofing of the source
address at the 6to4 site before encapsulation; that is likely to
be difficult.
9.0.0.255 is assumed the the relay's broadcast address. After When launched from a native IPv6 node, the traffic goes through 6to4
receiving the packet natively, if the relay doesn't check the relays twice, both after and before the reflection; when launched
destination address for subnet broadcast, it would send the from a 6to4/IPv4 node, the traffic goes through a relay only after
encapsulated IP-IP packet to 9.0.0.255. This would be received by the reflection.
all nodes in the subnet, and the responses would be directed to the
relay.
5.3.5.1. Comparison to Situation without 6to4 EXTENSIONS
This is a special form of "directed broadcast" attack which cannot be A distributed Reflection DoS can be performed if a large number of
protected against except by the mentioned check. However, there is a native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed
significant difference: the reply packets are sent back to the relay. traffic with the same source IPv6 address.
Therefore only the non-compliant device can suffer from this; the
rest of the Internet cannot be affected.
5.3.6. Theft of Service THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The administrators of 6to4 Relay Routers often want to use some Some of the mitigation methods for such attacks are:
policy to limit the use of relay.
The policy control is usually done by applying some restrictions in 1. Attacks from the native IPv6 nodes could be stopped by
where the routing information for 2002::/16 and/or 192.88.99.0/24 (if implementing ingress filtering in the IPv6 Internet.
[6TO4ANY] is used) will spread.
2. Two measures are needed to stop or mitigate the attacks from IPv4
nodes: 1) Implementing ingress filtering in the IPv4 internet,
and 2) logging IPv4 source address in the 6to4 router.
3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4
router in those sites implements egress filtering.
4. The traffic passes through one or two relays, and traffic rate
limiting in the 6to4 relays might help tone down the reflection
attack.
COMPARISON TO SITUATION WITHOUT 6to4
Even thought there are means to mitigate the attack, it is still
rather efficient, especially when used by native IPv6 nodes with
spoofed addresses. Using 6to4 relays and routers could easily take
down the 6to4 relay system and/or provide an easy means for traffic
laundering. However, if the intent of the attack is just to DoS the
victim, it can be achieved more smoothly by doing it directly (as the
source address spoofing was available as well).
Therefore, the threat seems to be higher to the availability and
stability of the 6to4 relay system itself than to native IPv6
Internet.
4.2.4 Local IPv4 Broadcast Attack
This attack is similar to the ones employed against 6to4 routers as
described in Section 4.1.4. There are slight differences with regard
to the source of the attacks. This attack can be initiated by:
o Native IPv6 nodes that may send traffic to the relay's subnet
broadcast address.
o IPv4 nodes that may send traffic with spoofed source IP address
(to be the relay's broadcast address) to elicit replies (e.g.,
ICMPv6 Hop Limit Exceeded messages) from the 6to4 relay to its
local nodes.
The first is more dangerous than in Section 4.1.4 because it can be
initiated by any IPv6 node (which is allowed to use the relay, that
is), not limited to local users.
The second is trickier and not really useful. For it to succeed, the
relay would have to accept native source addresses over the 6to4
pseudo-interface (but we did not assume this check was implemented),
as if coming from another relay, and trigger an ICMPv6 message to the
relay's local IPv4 subnet. The former method is more lucrative.
EXTENSIONS
None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The threat is restricted to the relay's local subnet, and is fixed by
tightening the 6to4 security checks.
COMPARISON TO SITUATION WITHOUT 6to4
This scenario is caused by 6to4, but fortunately, the issue is not
serious.
4.2.5 Theft of Service
ATTACK DESCRIPTION
The 6to4 relay administrators would often want to use some policy to
limit the use of the relay to specific 6to4 sites and/or specific
IPv6 sites.
The policy control is usually done by applying restrictions to where
the routing information for 2002::/16 and/or 192.188.99.0/24 (if the
anycast address used [3]) will spread.
Some users may be able to use the service regardless of these Some users may be able to use the service regardless of these
controls using: controls, by:
o configuring the address of the relay using its IPv4 address o Configuring the address of the relay using its IPv4 address
instead of 192.88.99.1, or instead of 192.88.99.1, or
o using Routing Header to route IPv6 packets to reach some 6to4
Relay (some other routing tricks like neighbors setting static
routes are also possible).
The former can be protected against using configured access lists in o Using the Routing header to route IPv6 packets to reach specific
the relay; this is only feasible if the number of IP networks the 6to4 relays. (Some other routing tricks like using static routes
relay is supposed to serve is relatively low. Another possible way may also be used.)
to mitigate this is to filter out arriving tunneled packets with
EXTENSIONS
None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
Attempts to use the relay's IPv4 address instead of 192.88.99.1 can
be mitigated in the following ways:
1. IPv4 domains should prevent usage of the actual IPv4 address of
the relay instead of 192.88.99.1.
2. Usage of access lists in the 6to4 relay to limit access. This is
only feasible if the number of IP networks the relay is supposed
to serve is relatively low.
3. The 6to4 relay should filter out arriving tunneled packets with
protocol 41 (IPv6) which do not have the the 192.88.99.1 as the protocol 41 (IPv6) which do not have the the 192.88.99.1 as the
destination address. destination address.
The latter has similar issues: the IPv6 source address could be The other threat of using routing tricks in the IPv6 networks to
checked so the packets to the relay only come from the valid IPv6 reach the 6to4 relay has similar solutions:
addresses which are able to reach the relay anyway. As Routing
Header is not specific to 6to4, the main things one could do here
with it would be to select the relay; some generic threats about
Routing Header use are described in [RHHASEC].
Of these, except in really restricted scenarios, only the first may 1. Usage of access lists in the relay to limit access.
be of some interest, and the mitigating the problem by access list is
rather straightforward. 2. Filtering out the packets with a routing header (may have other
implications).
3. Monitoring the source addresses going through the relay, to
detect e.g. peers setting up static routes.
Routing Header is not specific to 6to4, the main things one could do
here with it would be to select the relay; some generic threats about
Routing Header use are described in [10].
As this threat does not have implications on other than the As this threat does not have implications on other than the
organization providing Relay, it is not further analysed. organization providing 6to4 relay, it is not analyzed any further.
5.3.7. Relay Operators Seen as Source of Abuse COMPARISON TO SITUATION WITHOUT 6to4
There are several attacks which use 6to4 Relays to anonymize the These threats are specific to 6to4 relays (or in general, anycast
services), and do not exist in networks without 6to4.
4.2.6 Relay Operators Seen as Source of Abuse
ATTACK DESCRIPTION
There are several attacks which use 6to4 relays to anonymize the
traffic; this often results in packets being tunneled from the relay traffic; this often results in packets being tunneled from the relay
to a supposedly-6to4 site. to a supposedly-6to4 site.
However, as was already pointed out in sections 5.3.3 and 5.3.4, the However, as was already pointed out in Section 4.2, the IPv4 source
IPv4 source address used by the relay could, cursorily looking, be address used by the relay could, cursorily looking, be seen as the
seen as the source of these "protocol-41" attacks. source of these "protocol-41" attacks.
This could cause a number of concerns for the operators deploying This could cause a number of concerns for the operators deploying
6to4 relay service, for example: 6to4 relay service. For example:
o getting contacted a lot (via email, phone, fax or lawyers) on o Getting contacted a lot (via email, phone, fax, or lawyers) on
suspected "abuse", suspected "abuse",
o getting the whole IPv4 address range rejected as a source of
abuse or spam, causing outage to other operations as well, or o Getting the whole IPv4 address range rejected as a source of abuse
o causing the whole IPv4 address range to be to be blacklisted in or spam, causing outage to other operations as well, or
o Causing the whole IPv4 address range to be to be blacklisted in
some "spammer databases", if the relay would be used for those some "spammer databases", if the relay would be used for those
purposes. purposes.
This threat seems slightly similar (but more generic) to the outburst
of SMTP abuse caused by open relays.
EXTENSIONS
None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
This problem can be avoided (or really, "made someone else's This problem can be avoided (or really, "made someone else's
problem") by using the 6to4 anycast address in 192.88.99.0/24 as the problem") by using the 6to4 anycast address in 192.88.99.0/24 as the
source address: blacklisting or rejecting that should not cause source address: blacklisting or rejecting that should not cause
problems to the other operations. Further, when someone is filing problems to the other operations.
complaints to the owner of 192.88.99.0/24, they notice multiple
records and see a pointer to [6TO4ANY], and may learn that the 6to4
relay is in fact innocent. Of course, this could result in these
reports going to the closest anycast 6to4 relay as well, which in
fact had nothing to do with the incident.
5.4. Possible Threat Mitigation Methods Further, when someone is filing complaints to the owner of
192.88.99.0/24, they notice multiple WHOIS records and see a pointer
to [3], and may learn that the 6to4 relay is in fact innocent. Of
course, this could result in these reports going to the closest
anycast 6to4 relay as well, which in fact had nothing to do with the
incident.
This section gives a rough idea of mechanisms thought to mitigate the However, the wide-spread usage of 192.88.99.1 as the source address
threats. may make it more difficult to disambiguate the relays, which might be
a useful feature for debugging purposes.
5.4.1. 6to4 Decapsulation Cache COMPARISON TO SITUATION WITHOUT 6to4
6to4 decapsulators (routers, relays) could keep a least recently used This threat is caused by 6to4 deployment, but can be avoided, at
(LRU) header cache of possibly a few hundred entries of recently seen least in the short-term, by using the use of 192.88.99.1 as the
packets for tracing purposes. source address.
The problem here is how that kind of data could be extracted -- by 4.3 Attacks on IPv4 Internet
third parties that need it -- in timely fashion. Many
implementations are, of course, already able to perform something
like this by e.g. manually set logging access lists.
5.4.2. Rate-limiting at 6to4 Routers/Relays There are two types of attacks on the IPv4 internet - spoofed
traffic, and reflection. They can be initiated by native IPv6 nodes,
6to4 nodes, and IPv4 nodes.
TBD. Attacks initiated by IPv4 nodes that send spoofed traffic that will
not utilize the 6to4 infrastructure are considered out of scope of
this document. 6to4 infrastructure may be utilized in reflection
attacks that are initiated by IPv4 nodes.
5.4.3. An Application of iTrace Model It is difficult for these attacks to be effective as the traffic sent
out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4
nodes unless they have implemented some sort of IPv6-in-IPv4
tunneling.
6to4 decapsulators (or some of them) could send out some specific Such attacks can easily be thwarted by implementing protocol-41
packets probabilitically as a way ensure that reflectors cannot be filtering in IPv4 nodes or sites that do not implement IPv6 over IPv4
used to lose trails of an attack. This could either be a tunneling. Such filters should not be made permanent, as they would
simplification or an extension of e.g. [ITRACE] model, depending on act as a hurdle if IPv6 over IPv4 tunneling mechanisms were ever to
how fast its specification goes. be implemented by the IPv4 node or site.
The most important place for this would be at 6to4 Routers, to XXX: do these need to be spelled out, as in previous sections?
counter the reflection attack descibed in 5.2.2. If so, the check
could be placed at the decapsulation phase where packets have a 6to4
destination address but the source is non-6to4.
The iTrace working group has been concluded due to decreased 4.4 Summary of the Attacks
applicability of the work. The documents may move forward as
individual submissions.
5.5. Summary Columns:
It would be useful to try to characterize the different threats by o Section number. The section that describes the attack.
comparing the severity of the threat to:
1. IPv4 networks today, where in many cases (even most), source o Attack name.
address spoofing is possible and there are no easy ways to
trace attacks
2. Hypothetical IPv4 networks -- the case if ingress filtering o Initiator. The node that initiates the attack.
would be deployed everywhere
3. Hypothetical IPv6 networks -- the case if ingress filtering * I_4 - IPv4 node
would be deployed everywhere in current and future IPv6
networks
However, this would be very difficult as it is not easy to assign * I_6 - native IPv6 node
severity values to all the features 6to4 adds and try to decide
whether it's more serious or not.
5.5.1. Summary of the Threats * 6to4 - 6to4 node
Below is the summary of the threats discussed above. Threat in 5.1 * * - All of the above
was merged with 5.2.2 as the effects are the same but from a
different perspective.
+----+-----+--------------------+-------+-------+---+---+----+ o Victim. The victim node
|Type| Sec | Characterization | Using |Against|Fix|I-F|Comp|
+----+-----+--------------------+-------+-------+---+---+----+
|Othr|5.2.1|Pseudo-Interface |Rtr/Rly|itself |yes|N/A| 3 |
|Othr|5.3.5|Local Direct. Bcast |Rly |itself |yes|N/A| 3 |
|Othr|5.3.6|Theft of Service |Rly |itself |yes|N/A| - |
|Othr|5.3.7|Relay Seems to Abuse|Rly |any v4 | ? | ? | - |
+----+-----+--------------------+-------+-------+---+---+----+
|Spf |5.2.2|Relay Spoofing |Rtr |ownsite| y?| - |same|
+----+-----+--------------------+-------+-------+---+---+----+
|Dir |5.3.3|DoS against IPv4 |Rly |any v4 | ? | 6 |1,2 |
+----+-----+--------------------+-------+-------+---+---+----+
|Refl|5.2.2|Refl. off any 6to4 |Rtr/Any|non6to4| ? | - | 2 |
|Refl|5.3.2|Refl. off any 6to4 |R*/Any |non6to4| ? | 6 | 2 |
|Refl|5.3.4|Refl. off any IPv6 |Rly/Any|any v4 |1/2|4+6|1,2 |
+----+-----+--------------------+-------+-------+---+---+----+
The table is sorted by threat type. Possibilities are spoofing, * I_4 - IPv4 node
direct attack, attack by reflection (ie. final attack consists of
some response packets) and other.
Threats when realize (ab)use some IPv6 nodes: possibilities are * I_6 - native IPv6 node
either 6to4 Routers (Rtr), 6to4 Relays (Rly) or any IPv6 nodes or any
6to4 nodes (Any). "R*" means that both Relays and Routers are used.
The final target of the attack is descibed in "Against"; it can be * 6to4 - 6to4 node
node(s) or network itself, the site itself which could prevent the
attack, any IPv4 node or any non-6to4 IPv6 node (non6to4).
If a fix for the problem is apparent, it is mentioned in the Fix * Relay - 6to4 relay
field.
If it can be assumed that either complete Internet-wide IPv4 or IPv6 * Router - 6to4 router
ingress filtering would (more or less) fix or significantly alleviate
the problem, the fixing version of ingress filtering is noted in I-F
column. The notable case is 5.3.4 where both v4/v6 ingress filtering
is needed -- but if the half of the readily-available fix is done,
IPv6 ingress filtering is enough. The other notable case is threat
5.2.2, which cannot be disabled by ingress filtering.
The last field "Comp" tries to compare the threats to their IPv4 o ToA. Type of Attack
equivalents, using:
1. cannot control packets significantly, ie. a weak attack,
2. can be mitigated significantly by adding some kind of tracing,
or
3. some new form of attack.
5.5.2. Generic Notes about Threats * D - DoS
Note: TBD. * R - Reflection DoS
o correct and fully-implemented base security features are a pre- * T - Theft of Service
requisite for reasonably safe operation,
o being able to spoof IPv4 or IPv6 packets enables one to launch
similar or more powerful attacks even currently,
o some 6to4 attacks provide an additional layer of indirection,
which may or may not be useful,
o 6to4 as an enabling mechanism does not provide any possibility
for packet multiplication which would affect global Internet,
attacks are generally 1:1,
o typically the reflected packets have restricted content, limiting
the usability in an attack,
o attacks typically have either 6to4 relay router's address or some
other information which could be used in manual tracing,
o attack packets pass through choke point(s), namely (one or more)
6to4 relays; in addition to physical limitations, these could
implement some form 6to4-site-specific traffic limiting,
o the relay's IPv4 address is often used as a source address for
these attacks, potentially causing a lot of complaints or other
actions as the relay seems to be the source of this "attack", and
o attacks could in theory be traceable using an extension of
[ITRACE] or [REVITRACE], but as those haven't been specified,
much less used, the point seems rather academic yet.
When considering motives for DoS attacks and how to protect against o Fix. Specified who is responsible for fixing the attack.
them (and considering the cost, and whether the protection actually
buys you anything), the following should not be forgotten:
o IPv4 and IPv6 ingress filtering are not likely to be commonplace * 6 - The 6to4 developer and/or operator can completely mitigate
for a long time; until it is, you cannot really depend on it, this attack.
o the real attacker (launching a DoS or DDoS) may not really even
care whether some zombie nodes get found out,
o techniques to trace DoS attacks are still in infancy (or not even
there) yet; due to time anything takes to get deployed, it is not
clear whether tracing mechanisms even for basic DoS attack
mechanisms would get reasonably widely deployed before it was
time to (more or less) retire 6to4, and
o DoS attacks are something that, in practise, operational people
have to be able to deal with anyway.
6. Implementing Proper Security Checks in 6to4 * 6* - The 6to4 developer and/or operator can partially mitigate
this attack.
* E - This threat cannot be fixed by the 6to4 developer or the
6to4 operator.
Summary of attacks on a 6to4 network:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.1 | Attacks with ND | I_4 | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
Figure 8
Summary of attacks on the native IPv6 internet:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.3 | Reflection Attacks | * | I_6 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.6 | Relay Operators ... | - | - | D | 1) |
+-------+----------------------+---------+----------+-----+-----+
Figure 9
Notes:
1) This attack is a side-effect of the other attacks, and thus does
not have any Initiator, Victim, and Fix. It is a Denial of Service
attack not on the network but on the organization in-charge of the
relay.
Summary of attacks on IPv4 internet:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Spoofing Traffic | * | I_4 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Reflection Attacks | * | I_4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
Figure 10
5. Implementing Proper Security Checks in 6to4
In this section, several ways to implement the security checks In this section, several ways to implement the security checks
required or implied by [6TO4] or augmented by this specification are required or implied by the specification [1] or augmented by this
described. These do not, in general, protech against the majority of memo are described. These do not, in general, protect against the
the threats listed above in the threat analysis. They're just majority of the threats listed above in the "Threat Analysis"
prerequisites for a relatively safe and simple 6to4 implementation. section. They're just prerequisites for a relatively safe and simple
6to4 implementation.
Two different sets of rules are listed, "generic", and "simplified". Note that in in general, the 6to4 router or relay does not know
The former addresses the required rules in the generic form; the whether it is acting as a router or relay. It would be possible to
latter simplifies them using a number number of assumptions to include a toggle to specify the behaviour, to be used e.g., when the
increase the readability. interface is brought up, but at least in February 2004, no
implementations were known to do that. Due to that, the checks are
described as one -- which works independent of whether the node is a
router or relay.
6.1. Generic Approach 5.1 Encapsulating IPv6 into IPv4
6.1.1. Encapsulating IPv6 into IPv4 The checks described in this section are to be performed when
encapsulating IPv6 into IPv4.
src and dst MUST pass ipv6-sanity checks, else drop (defined below) src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below), else drop
if src=2002 if prefix (src_v6) == 2002::/16
src MUST match src_v4 ipv4 address embedded in src_v6 MUST match src_v4
/* the scenario: 4.1. case 1. or 2. */ if prefix (dst_v6) == 2002::/16
if dst=2002 dst_v4 SHOULD NOT be assigned to the router
dst_v4 SHOULD NOT be assigned to the router (avoid misconfigurations)
/* the scenario: 4.1. case 1. */
fi fi
elif dst=2002
dst_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a
user-specified prefix length (restricting who can use the relay)
/* the scenario: 4.1. case 3. */
else else
drop drop
/* the scenario: we somehow got a native-native ipv6 packet */ /* we somehow got a native-native ipv6 packet */
fi fi
accept accept
6.1.2. Decapsulating IPv4 into IPv6 5.2 Decapsulating IPv4 into IPv6
src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop (defined below) The checks described in this section are to be performed when
src and dst MUST pass ipv6-sanity checks, else drop (defined below) decapsulating IPv4 into IPv6. They will be performed in both the
if dst=2002 6to4 router and relay.
dst MUST match dst_v4
/* the scenario: 4.2. case 1. or 2. */ src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop
if src=2002 src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop
src MUST match src_v4 if prefix (dst_v6) == 2002::/16
dst_v4 SHOULD be assigned to the router (see notes below) ipv4 address embedded in dst_v6 MUST match dst_v4
/* the scenario: 4.2. case 1. */ if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
dst_v4 SHOULD be assigned to the router
fi fi
elif src=2002 elif prefix (src_v6) == 2002::/16
src MUST match src_v4 ipv4 address embedded in src_v6 MUST match src_v4
dst_v4 SHOULD be assigned to the router (see notes below) dst_v4 SHOULD be assigned to the router (see notes below)
src_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked by a
user-specified prefix length (restricting who can use the relay)
/* the scenario: 4.2. case 3. */
else else
drop drop
/* the scenario: we somehow got a native-native ipv6 packet */ /* the we somehow got a native-native ipv6 packet */
fi fi
accept accept
6.1.3. IPv4 and IPv6 Sanity Checks 5.3 IPv4 and IPv6 Sanity Checks
6.1.3.1. IPv4 The encapsulation and decapsulation checks included certain sanity
checks for both IPv4 and IPv6. These are described here in detail.
5.3.1 IPv4
IPv4 address MUST be a global unicast address, as required by the IPv4 address MUST be a global unicast address, as required by the
6to4 specification. The disallowed addresses include those defined 6to4 specification. The disallowed addresses include those defined
in [RFC1812], and others widely used and known not to be global. in [13], and others widely used and known not to be global. These
These are: are:
o 0.0.0.0/8 (the system has no address assigned yet) o 0.0.0.0/8 (the system has no address assigned yet)
o 10.0.0.0/8 (private) o 10.0.0.0/8 (private)
o 127.0.0.0/8 (loopback) o 127.0.0.0/8 (loopback)
o 172.16.0.0/12 (private) o 172.16.0.0/12 (private)
o 192.168.0.0/16 (private) o 192.168.0.0/16 (private)
o 169.254.0.0/16 (IANA Assigned DHCP link-local) o 169.254.0.0/16 (IANA Assigned DHCP link-local)
o 224.0.0.0/4 (multicast) o 224.0.0.0/4 (multicast)
o 255.0.0.0/8 (broadcast)
In addition it MUST be checked that the address is not any of the o 240.0.0.0/4 (reserved and broadcast)
system's broadcast addresses. This is especially important if the
implementation is made so that it can: In addition, the address MUST NOT be any of the system's broadcast
addresses. This is especially important if the implementation is
made so that it can:
o receive and process encapsulated IPv4 packets arriving at its o receive and process encapsulated IPv4 packets arriving at its
broadcast addresses, or broadcast addresses, or
o send encapsulated IPv4 packets to one of its broadcast addresses. o send encapsulated IPv4 packets to one of its broadcast addresses.
6.1.3.2. IPv6 5.3.2 IPv6
IPv6 address MUST NOT be: IPv6 address MUST NOT be:
o 0::/16 (compatible, mapped addresses, loopback, unspecified,
...) o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...)
o fe80::/10 (link-local) o fe80::/10 (link-local)
o fec0::/10 (site-local) o fec0::/10 (site-local)
o ff02::/16 (link-local multicast)
Other multicast could also be considered for filtering. o ff00::/8 (any multicast)
In addition, it MUST be checked that equivalent 2002:V4ADDR checks, Note: only link-local multicast would be strictly required, but it is
where V4ADDR is any of the above IPv4 addresses, will not be passed. believed that multicast with 6to4 will not be feasible, so it has
been disallowed as well.
6.1.3.3. Optional Ingress Filtering In addition, it MUST be checked that equivalent 2002:V4ADDR::/48
checks, where V4ADDR is any of the above IPv4 addresses, will not be
passed.
In addition, the implementation may perform some form of ingress 5.3.3 Optional Ingress Filtering
filtering (e.g. Unicast Reverse Path Forwarding checks). For
example, if the 6to4 Router has multiple interfaces, of which some
are "internal", receiving either IPv4 or IPv6 packets with source
address belonging to any of these internal networks from the Internet
might be disallowed.
If these checks are implemented, it is RECOMMENDED that they default In addition, the implementation in the 6to4 router may perform some
to disabled. form of ingress filtering (e.g. Unicast Reverse Path Forwarding
checks). For example, if the 6to4 router has multiple interfaces, of
which some are "internal", receiving either IPv4 or IPv6 packets with
source address belonging to any of these internal networks from the
Internet might be disallowed.
6.1.3.4. Notes About the Checks If these checks are implemented, and are enabled by default, it's
recommended that there is a toggle to disable them if needed.
The rule 'dst_v4 SHOULD be assigned to the router' is not needed if 5.3.4 Notes About the Checks
the implementation is made in such a way that it only accepts and
processes encapsulated IPv4 packets arriving on unicast IPv4 The rule "dst_v4 SHOULD be assigned to the router" is not needed if
addresses, and that if destination address is known to be a local the 6to4 router implementation only accepts and processes
broadcast address, not try to encapsulate and send packets to it (see encapsulated IPv4 packets arriving its unicast IPv4 addresses, and
section 5.3.5 about this threat). when destination address is known to be a local broadcast address, it
does not try to encapsulate and send packets to it. (see Section
4.1.4, and Section 4.2.4 about this threat).
Some checks, especially the IPv4/IPv6 Sanity Checks, could be at Some checks, especially the IPv4/IPv6 Sanity Checks, could be at
least partially implementable with system-level access lists, if one least partially implementable with system-level access lists, if one
would like to avoid placing too many restrictions in the 6to4 would like to avoid placing too many restrictions in the 6to4
implementation itself. This depends on how many hooks for the access implementation itself. This depends on how many hooks for the access
lists are in place. In practice it seems like this could not be done lists are in place. In practice it seems that this could not be done
effectively enough unless the access list mechanism is able to parse effectively enough unless the access list mechanism is able to parse
the encapsulated packets within IP-IP. the encapsulated packets.
6.2. Simplified Approach
This makes some assumptions about the implementation as pointed above
to simplify the above rules.
6.2.1. Encapsulating IPv6 into IPv4
src and dst MUST pass ipv6-sanity checks, else drop
if src=2002
src MUST match src_v4
elif dst=2002
(accept)
else
drop
fi
accept
6.2.2. Decapsulating IPv4 into IPv6
src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop
src and dst MUST pass ipv6-sanity checks, else drop
if dst=2002
dst MUST match dst_v4
if src=2002
src MUST match src_v4
fi
elif src=2002
src MUST match src_v4
else
drop
fi
accept
7. Issues 6. Issues in 6to4 Implementation and Use
This section tries to give an overview of some of the problems 6to4 This section tries to give an overview of some of the problems 6to4
implementations are faced with, and which kind of generic problems implementations are faced with, and the kind of generic problems the
the 6to4 users could come up with. 6to4 users could come up with.
7.1. Implementation Considerations with Automatic Tunnels 6.1 Implementation Considerations with Automatic Tunnels
There is a problem with multiple transition mechanisms if strict There is a problem with multiple transition mechanisms if strict
security checks are implemented. This may vary a bit from security checks are implemented. This may vary a bit from
implementation to implementation. implementation to implementation.
Consider three mechanisms using automatic tunneling: 6to4, ISATAP Consider three mechanisms using automatic tunneling: 6to4, ISATAP
[ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. [14] and Automatic Tunneling using Compatible Addresses [4]. All of
All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, these use IP-IP (protocol 41) [15] IPv4 encapsulation with, more or
more or less, a pseudo-interface. less, a pseudo-interface.
When a router, which has any two of these enabled, receives an IPv4 When a router, which has any two of these enabled, receives an IPv4
encapsulated IPv6 packet: encapsulated IPv6 packet:
src_v6 = 2001:db8::1
dst_v6 = 2002:1010:1010::2
src_v4 = 10.0.0.1 src_v4 = 10.0.0.1
dst_v4 = 20.20.20.20 dst_v4 = 20.20.20.20
src = 3ffe:ffff::1
dst = 2002:1010:1010::2
what can it do? How should it decide which transition mechanism this What can it do? How should it decide which transition mechanism this
belongs to; there is no "transition mechanism number" in IPv6 or IPv4 belongs to; there is no "transition mechanism number" in IPv6 or IPv4
header to signify this. (This can also be viewed as a flexibility header to signify this. (This can also be viewed as a flexibility
benefit.) benefit.)
Without any kind of security checks (in any of implemented methods) Without any kind of security checks (in any of implemented methods)
these often just "work" as the mechanisms aren't differentiated but these often just "work" as the mechanisms aren't differentiated but
handled in "one big lump". handled in "one big lump".
Configured tunneling [MECH] does not suffer from this as it is point- Configured tunneling [4] does not suffer from this as it is
to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses point-to-point, and based on src_v6/dst_v6 pairs of both IPv4 and
it can be deduced which logical tunnel interface is in the question. IPv6 addresses it can be deduced which logical tunnel interface is in
the question.
Solutions for this include not using more than one automatic
tunneling mechanisms in the same system or binding different
mechanisms to different IPv4 addresses.
7.2. Reduced Flexibility
There is a worry about too strict rules limiting the (future)
flexibility of 6to4. If later, for some reason, one would want to
introduce new revolutionary ways to use 6to4, strict checking in all
relevant nodes might prevent it, as new updated version would have to
be deployed everywhere before the new method could be used.
On the other hand, one could argue that 6to4 has always been intended
as an intermediate mechanism, and that future flexibility should not
be critical. However, it is difficult to predict how long the
intermediate period will be.
7.3. Anyone Pretending to Be a Relay Router Solutions for this include 1) not using more than one automatic
tunneling mechanism in a node or 2) binding different mechanisms to
different IPv4 addresses.
6to4 Routers receive traffic from non-6to4 ("native") sources via 6.2 Anyone Pretending to Be a 6to4 Relay
6to4 Relays. 6to4 Routers have no way of matching IPv4 source
address of the relay with non-6to4 IPv6 address of the source. In
consequence, anyone can spoof any non-6to4 IPv6 address he wants by
sending traffic, encapsulated, directly to 6to4 Routers. This is
analyzed in more detail in the Threat Analysis section, above.
Of course, as the source IPv4 address may be logged, many may spoof Even though this was already discussed in Section 4.1.2, it bears
their IPv4 source address, but the ability to do so is not be some additional elaboration as it was the only problem which cannot
required: it is unlikely that source IPv4 (but rather, the spoofed be even partially solved.
IPv6 address) will be logged anywhere -- this would be equivalent to
logging the MAC-address of IP packets.
Unfortunately, this problem is very difficult to solve properly. That is, 6to4 routers receive traffic from non-6to4 ("native")
There have been three rough ideas: sources via 6to4 relays. 6to4 routers have no way of matching IPv4
source address of the relay with non-6to4 IPv6 address of the source.
Consequently, anyone can spoof any non-6to4 IPv6 address he wants by
sending traffic, encapsulated, directly to 6to4 routers.
o Every 6to4 Relay must configure and use "192.88.99.1" as the Two different models of thinking have been proposed to fix this
source address of packets that are encapsulated towards 6to4 problem if it is considered to be important:
Routers.
o Every 6to4 Relay must participate in an eBGP multi-hop peering o Every 6to4 relay must participate in an eBGP multi-hop peering
mesh (which can be hierarchical): there more specific routes will mesh (which can be hierarchical); it would be used to advertise
be advertised. more specific routes.
o The 6to4 usage model would be turned upside-down, and the o The 6to4 usage model would be turned upside-down, and the
deployment of 6to4 would be have to be borne by native IPv6 deployment of 6to4 would be have to be borne by native IPv6 users.
users.
It should be noted that if IPv6 operators do not implement ingress
filtering for IPv6, so that spoofing IPv6 is not more difficult than
spoofing IPv4, these problems have only little impact on the overall
security of 6to4 nodes.
The first has since then been rejected: the difference in the These are described at a bit more length below.
difficulty of spoofing an address and spoofing it to be 192.88.99.1
does not seem to justify the mechanism. A tentative analysis for the
second and third is given below.
7.3.1. Limited Distribution of More Specific Routes 6.2.1 Limited Distribution of More Specific Routes
If 6to4 prefixes more specific than 2002::/16 could be advertised, If 6to4 prefixes more specific than 2002::/16 could be advertised,
the traffic model between native<->6to4 and 6to4<-> could be changed the traffic model between native to 6to4 and 6to4 to native could be
so that only one Relay would always be used, most often the one changed so that only one 6to4 relay would always be used, most often
closest to the 6to4 Router. the one closest to the 6to4 router.
This model was rejected in the base specification, as IPv6 routing This model was rejected in the base specification, as IPv6 routing
table was not to be polluted by 6to4 prefixes derived of IPv4 table was not to be polluted by 6to4 prefixes derived of IPv4
prefixes. prefixes.
However, the problem could be avoided with some effort: creating a However, the problem could be avoided with some effort: creating a
separate, possibly hierarchical based on IPv6 connections, peering separate, possibly hierarchical based on IPv6 connections, peering
mesh for 6to4 Relay routers. This could be done by forming eBGP mesh for 6to4 relay routers. This could be done by forming eBGP [5]
[BGP] multi-hop peerings between Relays, and advertising more multi-hop peerings between 6to4 relays, and advertising more specific
specific routes (e.g. the same superblocks of IPv4 addresses one routes (e.g., the same superblocks of IPv4 addresses one expects to
expects to service) to all the other Routers. service) to all the other routers.
In that way, the global routing table would not be impacted at all. In that way, the global routing table would not be impacted at all.
This seems to have at least three potential issues: This seems to have at least three potential issues:
o Every Relay should be part of this (if one wants to have some 1. Every 6to4 relay should be part of this (if one wants to have
extra safety that the addresses haven't been spoofed), some extra safety that the addresses haven't been spoofed),
o The route from a native source takes the path to the first Relay, 2. The route from a native source takes the path to the first 6to4
and there (possibly through other Relays) to the last Relay to relay, and there (possibly through other Relays) to the last 6to4
tunnel the packet to the 6to4 Router; this adds at least some relay to tunnel the packet to the 6to4 router; this adds at least
latency, and some latency, and
o The mechanism of redistributing IPv4 6to4 client addresses to 3. The mechanism of redistributing IPv4 6to4 client addresses to
other relays as 6to4 prefixes needs work. other relays as 6to4 prefixes needs work.
Of these, only the last requires more discussion. It could be argued Of these, only the last requires more discussion. It could be argued
that this advertising should either be manually configured once (ie. that this advertising should either be manually configured once
relatively static prefixes, or generated from IPv4 route-objects in (i.e., relatively static prefixes, or generated from IPv4
RADB etc.) or generated automatically (e.g. when a 6to4 Router first route-objects in RADB [16] or generated automatically (e.g., when a
sends a "triggering" packet through the Relay). Of course, this data 6to4 router first sends a "triggering" packet through the 6to4
could even be derived in some form from the IPv4 routing tables. relay). Of course, this data could even be derived in some form from
Further analysis on this is TBD if necessary. the IPv4 routing tables. Further analysis on this is TBD if
necessary.
This method seems to be the only one where strong cryptography-based Even if the traffic to 6to4 routers is limited to few relays, other
mechanisms to be sure about the 6to4 Router - 6to4 Relay IPv4 nodes can still spoof both IPv4, and IPv6 address and perform
-relationship could be doable; otherwise, some sort of infrastructure the spoofing attack. Hence, a necessary step is to use strong
(e.g. small-scale PKI) would have to be established which would have cryptography-based mechanisms to ensure the 6to4 router - 6to4 relay
to include all the possible 6to4 Relays in the Internet. relationship. Alternatively, some sort of infrastructure (e.g.,
small-scale PKI) would have to be established which would have to
include all the possible 6to4 relays in the Internet.
7.3.2. A Different Model for 6to4 Deployment 6.2.2 A Different Model for 6to4 Deployment
It could be possible to turn the deployment assumptions of 6to4 It could be possible to turn the deployment assumptions of 6to4
around a bit to eliminate some threats caused by untrusted 6to4 around a bit to eliminate some threats caused by untrusted 6to4
relays. That is: relays. That is:
o Every dual-stack site (or even ISP) would be required to have o Every dual-stack site (or even ISP) would be required to have
their own 6to4 relay. That is, there would not be third-party their own 6to4 relay. That is, there would not be third-party
relays, and the 2002::/16 route would not need to be advertised relays, and the 2002::/16 route would not need to be advertised
globally, and globally, and
o The security implications of 6to4 use could be pushed back to the o The security implications of 6to4 use could be pushed back to the
level of trust inside the site or ISP (or their acceptable use level of trust inside the site or ISP (or their acceptable use
policies) -- this is something that the sites and ISPs should be policies) -- this is something that the sites and ISP's should be
familiar with already. familiar with already.
However, this has a number of problems: However, this has a number of problems:
This model would shift the majority of burden of supporting 6to4 to This model would shift the majority of burden of supporting 6to4 to
IPv6 sites which don't employ or use 6to4 at all, e.g. "those who IPv6 sites which don't employ or use 6to4 at all, i.e., "those who
deploy proper native dual-stack". It could be argued that the pain deploy proper native dual-stack". It could be argued that the
should be borne by 6to4 users, not the others. deployment pain should be borne by 6to4 users, not the others.
The main advantage of 6to4 is easy deployment and free relays. This The main advantage of 6to4 is easy deployment and free relays. This
would require that everyone the 6to4 sites wish to communicate with would require that everyone the 6to4 sites wish to communicate with
implement these measures. implement these measures.
The model would not fix the "relay spoofing problem", only restrict The model would not fix the "relay spoofing problem", unless
it a bit, unless everybody deployed also 6to4 addresses on the nodes everybody deployed also 6to4 addresses on the nodes (alongside with
(alongside with native addresses, if necessary), which in turn would native addresses, if necessary), which in turn would change 6to4 to
change 6to4 to operate without relays completely. operate without relays completely.
To summarize, it seems like 6to4 cannot be salvaged: the decision is 7. Security Considerations
either to embrace it or trash it.
8. Security Considerations This draft discusses security considerations of 6to4.
This draft discusses security considerations. Even if proper checks are implemented, there are a large number of
different kind of security threats; these threats are analyzed in
Section 4.
Even if proper checks are implemented, there are significant security There are mainly three classes of potential problem sources:
threats ranging from DoS proxy attacks to spoofing and attacks
against 6to4 pseudo-interface. These threats are analyzed in section
5.
As can be seen, there are mainly three classes of potential problem 1. 6to4 routers not being able to identify whether relays are
sources: legitimate,
o 6to4 routers not being able to identify whether relays are 2. Wrong or impartially implemented 6to4 router or relay security
legitimate checks,
o wrong or impartially implemented 6to4 Routers
o relays performing packet laundering 3. 6to4 architecture used to participate in DoS or reflected DoS
attacks, or made to participate in "packet laundering", i.e.,
making another attack harder to trace, or
4. 6to4 relays being subject to "administrative abuse", e.g., theft
of service, or being seen as a source of abuse.
The first is the toughest problem, still under research. The second The first is the toughest problem, still under research. The second
can be fixed by ensuring the correctness of implementations; this is can be fixed by ensuring the correctness of implementations; this is
important. The third is also a difficult, but a fairly restricted important. The third is also a very difficult problem, and
problem as relays are limited in number. impossible to solve completely -- therefore it is important to be
able to analyze whether this results in a significant increase of
threats. The fourth problem seems to have feasible solutions.
These are analyzed in detail in Threat Analysis section, above. These are analyzed in detail in Threat Analysis, in Section 4.
9. Acknowledgements 8. Acknowledgments
Some issues were first brought up by Itojun Hagino in [TRANSAB], and Some issues were first brought up by Itojun Hagino in [17], and Alain
Alain Durand introduced one specific problem at IETF51 in August 2001 Durand introduced one specific problem at IETF51 in August 2001
(though there was some discussion on the list prior to that); these (though there was some discussion on the list prior to that); these
gave the author the push to start looking into the details of gave the author the push to start looking into the details of
securing 6to4. securing 6to4.
Alexey Kuznetsov brought up the implementation problem with IPv6 Alexey Kuznetsov brought up the implementation problem with IPv6
martian checks. Christian Huitema formulated the rules that rely on martian checks. Christian Huitema formulated the rules that rely on
Relays using only anycast. Keith Moore brought up the point about 6to4 relays using only anycast. Keith Moore brought up the point
reduced flexibility. Brian Carpenter, Tony Hain and Vladislav about reduced flexibility. Brian Carpenter, Tony Hain and Vladislav
Yasevich are acknowledged for lengthy discussions. Alain Durand Yasevich are acknowledged for lengthy discussions. Alain Durand
reminded of relay spoofing problems. Brian Carpenter reminded of the reminded of relay spoofing problems. Brian Carpenter reminded of the
BGP-based 6to4 router model. Christian Huitema gave a push to a more BGP-based 6to4 router model. Christian Huitema gave a push to a more
complete threat analysis. Itojun Hagino spelled out the operators' complete threat analysis. Itojun Hagino spelled out the operators'
fears about 6to4 relay abuse. Rob Austein brought up the idea of a fears about 6to4 relay abuse. Rob Austein brought up the idea of a
different 6to4 deployment model. different 6to4 deployment model.
In the latter phase, especially discussions with Christian Huitema, In the latter phase, especially discussions with Christian Huitema,
Brian Carpenter and Alain Durand were helpful when improving the Brian Carpenter and Alain Durand were helpful when improving the
document. document.
David Malone and [your name could be here] gave feedback on the David Malone and [your name could be here] gave feedback on the
document. document.
10. References Normative References
10.1. Normative References [1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001.
[6TO4] Carpenter, B. and Moore K., "Connection of IPv6 Domains [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
via IPv4 Clouds", RFC 3056, February 2001. Levels", BCP 14, RFC 2119, March 1997.
[6TO4ANY] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
RFC 3068, June 2001. 3068, June 2001.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G. Informative References
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Requirement Levels", BCP 14, RFC 2119, March 1997. Hosts and Routers", RFC 2893, August 2000.
10.2. Informative References [5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[ADDRSEL] Draves, R., "Default Address Selection for IPv6", [6] Draves, R., "Default Address Selection for Internet Protocol
RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[BGP] Rekhter, Y., Li, T., "A Border Gateway Protocol 4", [7] Nikander, P., "IPv6 Neighbor Discovery trust models and
RFC1771, March 1995. threats", draft-ietf-send-psreq-04 (work in progress), October
2003.
[IPIP] Simpson, W., "IP in IP Tunneling", RFC 1853, October [8] Arkko, J., "SEcure Neighbor Discovery (SEND)",
1995. draft-ietf-send-ndopt-03 (work in progress), January 2004.
[ISATAP] Templin, F. et al, "Intra-Site Automatic Tunnel [9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
Addressing Protocol (ISATAP)", draft-ietf-ngtrans- IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in
isatap-15.txt (work-in-progress), August 2003. progress), February 2004.
[ITRACE] Bellovin, S., Leech, M., Taylor, T., "ICMP Traceback [10] Savola, P., "Security of IPv6 Routing Header and Home Address
Messages", draft-ietf-itrace-04.txt (work in progress), Options", draft-savola-ipv6-rh-ha-security-02 (work in
February 2003. progress), March 2002.
[MECH] Gilligan, R., and Nordmark, E. "Transition Mechanisms for [11] Ferguson, P. and D. Senie, "Network Ingress Filtering:
IPv6 Hosts and Routers", RFC 2893, August 2000. Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[REVITRACE] Barros, C., "A Proposal for ICMP Traceback Messages", [12] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback
http://www.research.att.com/lists/ietf-itrace/2000/09/ Messages", draft-ietf-itrace-04 (work in progress), February
msg00044.html. 2003.
[RHHASEC] Savola, P., "Security of IPv6 Routing Header and Home [13] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
Address Options", draft-savola-ipv6-rh-ha-security-03.txt June 1995.
(work-in-progress), December 2002.
[SEND] Nikander, P. (Ed.), "IPv6 Neighbor Discovery trust [14] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site
models and threats", draft-ietf-send-psreq-03.txt Automatic Tunnel Addressing Protocol (ISATAP)",
(work-in-progress), April 2003. draft-ietf-ngtrans-isatap-18 (work in progress), February 2004.
[TRANSAB] Hagino, J., "Possible abuse against IPv6 transition [15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[16] Merit Network Inc., "Routing Assets Database (http://
www.radb.net)".
[17] Hagino, J., "Possible abuse against IPv6 transition
technologies", draft-itojun-ipv6-transition-abuse-01.txt technologies", draft-itojun-ipv6-transition-abuse-01.txt
(expired, work-in-progress), July 2000. (expired, work-in-progress), July 2000.
Author's Address [18] Barros, C., "Proposal for ICMP Traceback Messages", http://
www.research.att.com/lists/ietf-itrace/2000/09/msg00044.html .
Authors' Addresses
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo, Finland Espoo
Finland
EMail: psavola@funet.fi EMail: psavola@funet.fi
A. Some Trivial Attack Scenarios Outlined Chirayu Patel
All Play, No Work
185, Defence Colony
Bangalore, Karnataka 560038
India
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
URI: http://www.chirayu.org
Appendix A. Some Trivial Attack Scenarios Outlined
Here, a few trivial attack scenarios are outlined -- ones that are Here, a few trivial attack scenarios are outlined -- ones that are
prevented by implementing checks listed in [6TO4] or in section 6. prevented by implementing checks listed in [1] or in section 6.
When two 6to4 Routers send traffic to each others' domains, packet When two 6to4 routers send traffic to each others' domains, packet
sent by RA to RB is like (note: addresses from 8.0.0.0/24 are just sent by RA to RB is like (note: addresses from 8.0.0.0/24 are just
examples of global IPv4 addresses): examples of global IPv4 addresses):
src = 2002:0800:0001::aaaa src_v6 = 2002:0800:0001::aaaa
dst = 2002:0800:0002::bbbb dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4) src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
When the packet is received by IPv4 stack on RB, it will be When the packet is received by IPv4 stack on RB, it will be
decapsulated so that only src and dst remain, as originally sent by decapsulated so that only src_v6 and dst_v6 remain, as originally
RA: sent by RA:
src = 2002:0800:0001::aaaa src_v6 = 2002:0800:0001::aaaa
dst = 2002:0800:0002::bbbb dst_v6 = 2002:0800:0002::bbbb
As every other node is just one hop away (IPv6-wise) and the link- As every other node is just one hop away (IPv6-wise) and the
layer (IPv4) addresses are lost, this may open a lot of possibilities link-layer (IPv4) addresses are lost, this may open a lot of
for misuse. possibilities for misuse.
As an example, unidirectional IPv6 spoofing is made trivial because As an example, unidirectional IPv6 spoofing is made trivial because
nobody can check (without delving into IP-IP packets) whether the nobody can check (without delving into IP-IP packets) whether the
encapsulated IPv6 addresses were authentic (With native IPv6, this encapsulated IPv6 addresses were authentic (With native IPv6, this
can be done by e.g. RPF-like mechanisms or access lists in upstream can be done by e.g., RPF-like mechanisms or access lists in upstream
routers). routers).
src = 2002:1234:5678::aaaa (forged) src_v6 = 2002:1234:5678::aaaa (forged)
dst = 2002:0800:0002::bbbb dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4) src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
A similar attack with "src" being native address is possible even A similar attack with "src" being native address is possible even
with the security checks, by having the sender node pretend to be a with the security checks, by having the sender node pretend to be a
6to4 Relay router. 6to4 relay router.
More worries come in to the picture if e.g. More worries come in to the picture if e.g.,
src = ::ffff:[some trusted IPv4 in a private network] src_v6 = ::ffff:[some trusted IPv4 in a private network]
src/dst = ::ffff:127.0.0.1 src_v6/dst_v6 = ::ffff:127.0.0.1
src/dst = ::1 src_v6/dst_v6 = ::1
src/dst = ... src_v6/dst_v6 = ...
Some implementations might have been careful enough to have designed Some implementations might have been careful enough to have designed
the stack to as to avoid the incoming (or reply) packets going to the stack to as to avoid the incoming (or reply) packets going to
IPv4 packet processing through special addresses (e.g. IPv4-mapped IPv4 packet processing through special addresses (e.g., IPv4-mapped
addresses), but who can say for all ... addresses), but who can say for all ...
Appendix B. Change Log
[[ RFC-EDITOR note: to be removed before publication ]]
Changes from -00 to -01
1. Lots of editorial changes in other sections
2. Revamped the "Threat Analysis" section completely; ripple the
effects elsewhere in the document as well.
3. Added Chirayu Patel as a co-author.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/