draft-ietf-v6ops-6to4-security-02.txt   draft-ietf-v6ops-6to4-security-03.txt 
v6ops Working Group P. Savola v6ops Working Group P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Expires: September 7, 2004 C. Patel Expires: December 16, 2004 C. Patel
All Play, No Work All Play, No Work
Mar 9, 2004 June 17, 2004
Security Considerations for 6to4 Security Considerations for 6to4
draft-ietf-v6ops-6to4-security-02.txt draft-ietf-v6ops-6to4-security-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3667. RFC 3668.
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-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 http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at 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 September 7, 2004. This Internet-Draft will expire on December 16, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The IPv6 interim mechanism 6to4 (RFC3056) uses automatic The IPv6 interim mechanism 6to4 (RFC3056) uses automatic
IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The
architecture includes 6to4 routers and 6to4 relay routers, which architecture includes 6to4 routers and 6to4 relay routers, which
accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from
any node in the IPv4 internet. This characteristic enables a number any node in the IPv4 internet. This characteristic enables a number
of security threats, mainly Denial of Service. It also makes it of security threats, mainly Denial of Service. It also makes it
easier for nodes to spoof IPv6 addresses. This document discusses easier for nodes to spoof IPv6 addresses. This document discusses
these issues in more detail and suggests enhancements to alleviate these issues in more detail and suggests enhancements to alleviate
the problems. 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 . . . . . . . . . . . . . . . . . 4 2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . 5
2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . 5 2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . 6
2.4 Other Models . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . 6 2.4.2 6to4 as an Optimization Method . . . . . . . . . . . . 7
2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . 6 2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . . . . 7
3. Functionalities of 6to4 Network Components . . . . . . . . . 8 3. Functionalities of 6to4 Network Components . . . . . . . . . . 9
3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . 8 3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . 9 3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . 10
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . 10 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . 11 4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . 12
4.1.1 Attacks with ND Messages . . . . . . . . . . . . 12 4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . 13
4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . 13 4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . 14
4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . 16 4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . 17
4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . 17 4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 18
4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . 19 4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . 20
4.2.1 Attacks with ND Messages . . . . . . . . . . . . 19 4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . 20
4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . 20 4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . 21
4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . 21 4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . 22
4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . 23 4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 24
4.2.5 Theft of Service . . . . . . . . . . . . . . . . 23 4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . 24
4.2.6 Relay Operators Seen as Source of Abuse . . . . 25 4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . 26
4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . 26 4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . 27
4.4 Summary of the Attacks . . . . . . . . . . . . . . . . 26 4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . 27
5. Implementing Proper Security Checks in 6to4 . . . . . . . . 28 5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 29
5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . 29 5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . 30
5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . 29 5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . 30
5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . 30 5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . 31
5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . 30 5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . 31 5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.3 Optional Ingress Filtering . . . . . . . . . . . 31 5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . 32
5.3.4 Notes About the Checks . . . . . . . . . . . . . 31 5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . 32
6. Issues in 6to4 Implementation and Use . . . . . . . . . . . 32 6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 33
6.1 Implementation Considerations with Automatic Tunnels . 32 6.1 Implementation Considerations with Automatic Tunnels . . . 33
6.2 A Different Model for 6to4 Deployment . . . . . . . . 33 6.2 A Different Model for 6to4 Deployment . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
Normative References . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
Informative References . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . 37 10.2 Informative References . . . . . . . . . . . . . . . . . . . 36
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . 39 A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 38
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . 40
1. Introduction 1. Introduction
The IPv6 interim mechanism "6to4" [1] specifies automatic The IPv6 interim mechanism "6to4" [1] specifies automatic
IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by
embedding the tunnel IPv4 address in the IPv6 6to4 prefix. embedding the tunnel IPv4 address in the IPv6 6to4 prefix.
Two characteristics of the 6to4 mechanism introduce most of the Two characteristics of the 6to4 mechanism introduce most of the
security considerations: security considerations:
skipping to change at page 8, line 18 skipping to change at page 9, line 18
destination, it will not go through the main office as the 6to4 destination, it will not go through the main office as the 6to4
2002::/16 route overrides the default route. 2002::/16 route overrides the default route.
This approach may make addressing and routing slightly easier in some This approach may make addressing and routing slightly easier in some
circumstances. circumstances.
3. Functionalities of 6to4 Network Components 3. Functionalities of 6to4 Network Components
This section summarizes the main functionalities of the 6to4 network This section summarizes the main functionalities of the 6to4 network
components (6to4 routers, and 6to4 relays), and the security checks components (6to4 routers, and 6to4 relays), and the security checks
that must be done by them. The pseudo-code for the security checks is that must be done by them. The pseudo-code for the security checks
provided in Section 5. is provided in Section 5.
This section summarizes the main functions of the various components This section summarizes the main functions of the various components
that are part of a 6to4 network - 6to4 relay routers, and 6to4 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 routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4 related
definitions. definitions.
3.1 6to4 Routers 3.1 6to4 Routers
The 6to4 routers acts as the border router of a 6to4 domain. It does The 6to4 routers acts as the border router of a 6to4 domain. It does
not have a native, global IPv6 address except in certain special not have a native, global IPv6 address except in certain special
skipping to change at page 9, line 5 skipping to change at page 10, line 5
o Tunnel packets sent to non-6to4 addresses, to the configured/ o Tunnel packets sent to non-6to4 addresses, to the configured/
closest-by-anycast 6to4 relay router. closest-by-anycast 6to4 relay router.
o Decapsulate directly received IPv4 packets from foreign 6to4 o Decapsulate directly received IPv4 packets from foreign 6to4
addresses. addresses.
o Decapsulate IPv4 packets received via the relay closest to the o Decapsulate IPv4 packets received via the relay closest to the
native IPv6 sources. Note, it is not easily distinguishable that native IPv6 sources. Note, it is not easily distinguishable that
the packet was really received from a 6to4 relay router, not from the packet was really received from a 6to4 relay router, not from
a spoofing third party.) a spoofing third party.
The 6to4 router should also perform security checks on traffic that The 6to4 router should also perform security checks on traffic that
it will receive from other 6to4 relays, or 6to4 routers, or from it will receive from other 6to4 relays, or 6to4 routers, or from
within the 6to4 site. These checks include: within the 6to4 site. These checks include:
o Disallow traffic that has private, broadcast or reserved IPv4 o Disallow traffic that has private, broadcast or reserved IPv4
addresses in tunnels, or the matching 6to4 prefixes. addresses in tunnels, or the matching 6to4 prefixes.
o Disallow traffic from 6to4 routers where the IPv4 tunnel source o Disallow traffic from 6to4 routers where the IPv4 tunnel source
address does not match the 6to4 prefix. (Note that the address does not match the 6to4 prefix. (Note that the
skipping to change at page 10, line 36 skipping to change at page 11, line 36
global address; in particular, e.g. link-local addresses, mapped global address; in particular, e.g. link-local addresses, mapped
addresses and such should not be used. addresses and such should not be used.
o Discard traffic received from 6to4 routers with the destination as o Discard traffic received from 6to4 routers with the destination as
a 6to4 prefix. a 6to4 prefix.
4. Threat Analysis 4. Threat Analysis
This section discusses attacks against the 6to4 network or attacks This section discusses attacks against the 6to4 network or attacks
that are caused by the 6to4 network. The threats are discussed in that are caused by the 6to4 network. The threats are discussed in
light of the 6to4 deployment models defined in the Section 2. light of the 6to4 deployment models defined in Section 2.
There are three general types of threats: There are three general types of threats:
1. Denial-of-Service (DoS) attacks, in which a malicious node 1. Denial-of-Service (DoS) attacks, in which a malicious node
prevents communication between the node under attack and other prevents communication between the node under attack and other
nodes. nodes.
2. Reflection Denial-of-Service (DoS) attacks, in which a malicious 2. Reflection Denial-of-Service (DoS) attacks, in which a malicious
node reflects the traffic off unsuspecting nodes to a particular node reflects the traffic off unsuspecting nodes to a particular
node (node under attack) with the intent of preventing node (node under attack) with the intent of preventing
skipping to change at page 14, line 24 skipping to change at page 15, line 24
This attack is similar to ones shown in [10]. This attack is similar to ones shown in [10].
EXTENSIONS EXTENSIONS
Replies to the traffic will be directed to the src_v6 address, Replies to the traffic will be directed to the src_v6 address,
resulting in 6to4 nodes in participating in a reflection DoS. This 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 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 replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to
UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to
the victim (src_v6), above. All the traces from the original attacker the victim (src_v6), above. All the traces from the original
(src_v4) have been discarded. These return packets will go through a attacker (src_v4) have been discarded. These return packets will go
relay. through a relay.
Certain 6to4 networks may have a trivial ACL (Access Control List) Certain 6to4 networks may have a trivial ACL (Access Control List)
based firewall that allows traffic to pass through if it comes from based firewall that allows traffic to pass through if it comes from
particular source(s). Such a firewalling mechanism can be bypassed by particular source(s). Such a firewalling mechanism can be bypassed
address spoofing. This attack can therefore be used for trivial ACL by address spoofing. This attack can therefore be used for trivial
avoidance as well. These attacks might be hampered by the fact that ACL avoidance as well. These attacks might be hampered by the fact
the replies from the 6to4 node to the spoofed address will be lost. that the replies from the 6to4 node to the spoofed address will be
lost.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The Denial-of-Service attack based on traffic spoofing is not new; 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 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 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 those who are unable to do so in their current networks. The 6to4
router typically does not log IPv4 addresses (as they would be router typically does not log IPv4 addresses (as they would be
treated as L2 addresses) and thus the source of the attack (if 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 launched from an IPv4 node) is lost. Since traces to the src_v4
skipping to change at page 15, line 19 skipping to change at page 16, line 21
there is no amplification factor. there is no amplification factor.
o Attack packets, if initiated from an IPv6 node, will pass through o Attack packets, if initiated from an IPv6 node, will pass through
choke point(s), namely a 6to4 relay; in addition to physical choke point(s), namely a 6to4 relay; in addition to physical
limitations, these could implement some form of 6to4-site-specific limitations, these could implement some form of 6to4-site-specific
traffic limiting. traffic limiting.
On the other hand, a variety of factors can make the attack serious: 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 o The attacker may have the ability to choose the relay, and he
might employ the ones best suited for the attacks. Also, some might employ the ones best suited for the attacks. Also, many
relays use 192.88.99.1 [3] as the source address making tracing relays use 192.88.99.1 [3] as the source address making tracing
even more difficult. even more difficult (also see Section 4.2.6).
o The relay's IPv4 address may be used as a source address for these 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 attacks, potentially causing a lot of complaints or other actions
as the relay might seem to be the source of the attack (see as the relay might seem to be the source of the attack (see
Section 4.2.6 for more). Section 4.2.6 for more).
Some of the mitigation methods for such attacks are: Some of the mitigation methods for such attacks are:
1. Ingress filtering in the native IPv6 networks to prevent packets 1. Ingress filtering in the native IPv6 networks to prevent packets
with spoofed IPv6 source being transmitted. It would, thus, make with spoofed IPv6 source being transmitted. It would, thus, make
it easy to identify the source of the attack. it easy to identify the source of the attack.
2. Security checks in the 6to4 relay. The 6to4 relay must drop 2. Security checks in the 6to4 relay. The 6to4 relay must drop
traffic (from the IPv6 internet) that has 6to4 addresses as traffic (from the IPv6 internet) that has 6to4 addresses as
source address, see Section 5 for more. source address, see Section 5 for more.
However, these mitigation methods do not address the case of IPv4 However, these mitigation methods do not address the case of IPv4
node sending encapsulated IPv6 packets. node sending encapsulated IPv6 packets.
There exists no simple way to prevent such attacks, and longer term There exists no simple way to prevent such attacks, and longer term
solutions like ingress filtering [11] or itrace [12] have to be solutions like ingress filtering [11] or itrace [12] would have to be
deployed in both IPv6 and IPv4 networks to help identify the source deployed in both IPv6 and IPv4 networks to help identify the source
of the attacks. of the attacks. (Note that itrace work has been discontinued, as of
this writing.)
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just
makes it easier: anyone can, regardless of ingress filtering, spoof a makes it easier: anyone can, regardless of ingress filtering, spoof a
native IPv6 address to a 6to4 node, even if "maximal security" would native IPv6 address to a 6to4 node, even if "maximal security" would
be implemented and deployed. Losing trails is also easier. be implemented and deployed. Losing trails is also easier.
Therefore, depending on how much one assumes ingress filtering is Therefore, depending on how much one assumes ingress filtering is
deployed for IPv4 and IPv6, this could be considered to be a very deployed for IPv4 and IPv6, this could be considered to be a very
serious issue, or close to irrelevant compared to the IP spoofing serious issue, or close to irrelevant compared to the IP spoofing
capabilities without 6to4. capabilities without 6to4.
4.1.3 Reflecting Traffic to 6to4 Nodes 4.1.3 Reflecting Traffic to 6to4 Nodes
ATTACK DESCRIPTION ATTACK DESCRIPTION
Spoofed traffic (as described in the Section 4.2.2) may be sent to Spoofed traffic (as described in Section 4.2.2) may be sent to native
native IPv6 nodes with the aim of performing a reflection attack IPv6 nodes with the aim of performing a reflection attack against
against 6to4 nodes. 6to4 nodes.
The spoofed traffic is sent to a native IPv6 node, either from an 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 IPv4 node (through a 6to4 relay), or from a native IPv6 node (unless
ingress filtering has been deployed). With the former, the sent ingress filtering has been deployed). With the former, the sent
packets would look like: packets would look like:
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node) src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
dst_v6 = 2002:0900:0002::1 (valid address) dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or invalid address) src_v4 = 8.0.0.1 (valid or invalid address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6) dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
skipping to change at page 18, line 25 skipping to change at page 19, line 27
broadcast address. After receiving the packet with a destionation broadcast address. After receiving the packet with a destionation
address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the
router doesn't check the destination address for subnet broadcast, it 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 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 would be received by all nodes in the subnet, and the responses would
be directed to the 6to4 router. be directed to the 6to4 router.
Malicious sites may also embed forged 6to4 addresses in the DNS, use 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 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 router. One way to perform this attack would be to send an HTML mail
containing a link to an invalid URL (for example, http:// containing a link to an invalid URL (for example,
[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4
based network. Opening of the mail simultaneously would result in a technology based network. Opening of the mail simultaneously would
broadcast storm. result in a broadcast storm.
The second kind of attack is more complex: the attack can be 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 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) they can send traffic with invalid (for example 2002:0900:00ff::bbbb)
source address. The 6to4 router has to respond to the traffic by source address. The 6to4 router has to respond to the traffic by
sending ICMPv6 packets back to the source, for example Hop Limit sending ICMPv6 packets back to the source, for example Hop Limit
Exceeded or Destination Unreachable. The packet would be as follows: Exceeded or Destination Unreachable. The packet would be as follows:
src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router) src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router)
dst_v6 = 2002:0800:0001::0001 (valid non-existent address) dst_v6 = 2002:0800:0001::0001 (valid non-existent address)
skipping to change at page 20, line 17 skipping to change at page 21, line 17
ATTACK DESCRIPTION ATTACK DESCRIPTION
The attacker - a malicious IPv4 or 6to4 node - can send packets with The attacker - a malicious IPv4 or 6to4 node - can send packets with
spoofed (or not spoofed) 6to4 source address to a native IPv6 node to spoofed (or not spoofed) 6to4 source address to a native IPv6 node to
accomplish a DoS attack. accomplish a DoS attack.
The threat is similar as the one involving 6to4 routers as described The threat is similar as the one involving 6to4 routers as described
in Section 4.1.2. in Section 4.1.2.
The difference here is that the attack is initiated by IPv4 nodes, or The difference here is that the attack is initiated by IPv4 nodes, or
6to4 nodes. The source IPv6 address may or may not be spoofed. Note, 6to4 nodes. The source IPv6 address may or may not be spoofed.
as mentioned above, the relay is assumed to correlate source IPv4 Note, as mentioned above, the relay is assumed to correlate source
address with the address embedded in the source IPv6 address during IPv4 address with the address embedded in the source IPv6 address
decapsulation. A side effect is that all the spoofed traffic will during decapsulation. A side effect is that all the spoofed traffic
have a 6to4 source address. will have a 6to4 source address.
EXTENSIONS EXTENSIONS
Spoofed traffic may also be sent to native IPv6 nodes by either other Spoofed traffic may also be sent to native IPv6 nodes by either other
native IPv6 nodes, or 6to4 nodes, or malicious IPv4 nodes to conduct native IPv6 nodes, or 6to4 nodes, or malicious IPv4 nodes to conduct
Reflection DoS on either native IPv6 nodes or 6to4 nodes. Reflection DoS on either native IPv6 nodes or 6to4 nodes.
Certain native IPv6 networks may have a trivial ACL (Access Control Certain native IPv6 networks may have a trivial ACL (Access Control
List) based firewall that allows traffic to pass through if it comes List) based firewall that allows traffic to pass through if it comes
from particular source(s). Such a firewalling mechanism can be from particular source(s). Such a firewalling mechanism can be
bypassed by address spoofing. This attack can therefore be used for bypassed by address spoofing. This attack can therefore be used for
trivial ACL avoidance as well. These attacks might be hampered by the trivial ACL avoidance as well. These attacks might be hampered by
fact that the replies from the 6to4 node to the spoofed address will the fact that the replies from the 6to4 node to the spoofed address
be lost. will be lost.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The Denial-of-Service attack based on traffic spoofing is not new; The Denial-of-Service attack based on traffic spoofing is not new;
the only twist comes from the fact that traces of an attack are more the only twist comes from the fact that traces of an attack are more
easily lost. The 6to4 relay typically does not log IPv4 addresses easily lost. The 6to4 relay typically does not log IPv4 addresses
(as they would be treated as L2 addresses) and thus the source of the (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 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 src_v4 address can easily be lost, these attacks can also be be
launched from IPv4 nodes whose connection is ingress-filtered. launched from IPv4 nodes whose connection is ingress-filtered.
skipping to change at page 26, line 35 skipping to change at page 27, line 35
Attacks initiated by IPv4 nodes that send spoofed traffic that will Attacks initiated by IPv4 nodes that send spoofed traffic that will
not utilize the 6to4 infrastructure are considered out of scope of not utilize the 6to4 infrastructure are considered out of scope of
this document. 6to4 infrastructure may be utilized in reflection this document. 6to4 infrastructure may be utilized in reflection
attacks that are initiated by IPv4 nodes. attacks that are initiated by IPv4 nodes.
It is difficult for these attacks to be effective as the traffic sent 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 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 nodes unless they have implemented some sort of IPv6-in-IPv4
tunneling. tunneling.
XXX: do these need to be spelled out, as in previous sections?
4.4 Summary of the Attacks 4.4 Summary of the Attacks
Columns: Columns:
o Section number. The section that describes the attack. o Section number. The section that describes the attack.
o Attack name. o Attack name.
o Initiator. The node that initiates the attack. o Initiator. The node that initiates the attack.
* I_4 - IPv4 node * I_4 - IPv4 node
* I_6 - native IPv6 node * I_6 - native IPv6 node
* 6to4 - 6to4 node * 6to4 - 6to4 node
* * - All of the above
* * - All of the above
o Victim. The victim node o Victim. The victim node
* I_4 - IPv4 node * I_4 - IPv4 node
* I_6 - native IPv6 node * I_6 - native IPv6 node
* 6to4 - 6to4 node * 6to4 - 6to4 node
* Relay - 6to4 relay * Relay - 6to4 relay
skipping to change at page 29, line 24 skipping to change at page 30, line 24
The checks described in this section are to be performed when The checks described in this section are to be performed when
encapsulating IPv6 into IPv4. encapsulating IPv6 into IPv4.
The encapsulation rules are mainly designed to keep one from The encapsulation rules are mainly designed to keep one from
"shooting yourself on the foot" -- for example, the source address "shooting yourself on the foot" -- for example, the source address
check verifies that the packet will be acceptable to the check verifies that the packet will be acceptable to the
decapsulator, or the sanity checks ensure that addresses derived from decapsulator, or the sanity checks ensure that addresses derived from
private addresses are not used (which would be equally unacceptable). private addresses are not used (which would be equally unacceptable).
src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below), else drop src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop
if prefix (src_v6) == 2002::/16 if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4 ipv4 address embedded in src_v6 MUST match src_v4
else if prefix (dst_v6) == 2002::/16 else if prefix (dst_v6) == 2002::/16
dst_v4 SHOULD NOT be assigned to the router dst_v4 SHOULD NOT be assigned to the router
else else
drop drop
/* we somehow got a native-native ipv6 packet */ /* we somehow got a native-native ipv6 packet */
fi fi
accept accept
skipping to change at page 32, line 26 skipping to change at page 33, line 26
implementations are faced with, and the kind of generic problems the implementations are faced with, and the kind of generic problems the
6to4 users could come up with. 6to4 users could come up with.
6.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
[14] and Automatic Tunneling using Compatible Addresses [4]. All of [14] and Automatic Tunneling using Compatible Addresses [4]
these use IP-IP (protocol 41) [15] IPv4 encapsulation with, more or (currently removed [9] but typically still supported). All of these
less, a pseudo-interface. use IP-IP (protocol 41) [15] IPv4 encapsulation with, more or 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 src_v6 = 2001:db8::1
dst_v6 = 2002:1010:1010::2 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
What can it do? How should it decide which transition mechanism this What can it do? How should it decide which transition mechanism this
skipping to change at page 33, line 25 skipping to change at page 34, line 27
sources via 6to4 relays. 6to4 routers have no way of matching IPv4 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. 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 Consequently, anyone can spoof any non-6to4 IPv6 address he wants by
sending traffic, encapsulated, directly to 6to4 routers. sending traffic, encapsulated, directly to 6to4 routers.
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. (This assumes that IPv6-only is so long away their own 6to4 relay. (This assumes that IPv6-only is so long
that 6to4 would be hopefully retired at that point.) That is, away that 6to4 would be hopefully retired at that point.) That
there would not be third-party relays, and the 2002::/16 route is, there would not be third-party relays, and 2002::/16 and
would not need to be advertised globally, and 192.88.99.0/24 routes would not need to be advertised 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 ISP's 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, i.e., "those who IPv6 sites which don't employ or use 6to4 at all, i.e., "those who
skipping to change at page 34, line 37 skipping to change at page 35, line 37
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 very difficult problem, and important. The third is also a very difficult problem, and
impossible to solve completely -- therefore it is important to be impossible to solve completely -- therefore it is important to be
able to analyze whether this results in a significant increase of able to analyze whether this results in a significant increase of
threats. The fourth problem seems to have feasible solutions. threats. The fourth problem seems to have feasible solutions.
These are analyzed in detail in Threat Analysis, in Section 4. These are analyzed in detail in Threat Analysis, in Section 4.
8. Acknowledgments 8. IANA Considerations
This memo makes no requet to IANA. (RFC-editor note: please remove
this section on publication.)
9. Acknowledgments
Some issues were first brought up by Itojun Hagino in [16], and Alain Some issues were first brought up by Itojun Hagino in [16], and 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
6to4 relays using only anycast. Keith Moore brought up the point 6to4 relays using only anycast. Keith Moore brought up the point
skipping to change at page 35, line 11 skipping to change at page 36, line 16
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 Iljitsch van Beijnum gave feedback on the document. David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on
the document.
Normative References 10. References
10.1 Normative References
[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 [1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001. Clouds", RFC 3056, February 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC [3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
3068, June 2001. 3068, June 2001.
Informative References 10.2 Informative References
[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000. Hosts and Routers", RFC 2893, August 2000.
[5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", [5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995. RFC 1771, March 1995.
[6] Draves, R., "Default Address Selection for Internet Protocol [6] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[7] Nikander, P., "IPv6 Neighbor Discovery trust models and [7] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
threats", draft-ietf-send-psreq-04 (work in progress), October Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
2003.
[8] Arkko, J., "SEcure Neighbor Discovery (SEND)", [8] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
draft-ietf-send-ndopt-04 (work in progress), February 2004. "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05
(work in progress), April 2004.
[9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for [9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in
progress), February 2004. progress), June 2004.
[10] Savola, P., "Security of IPv6 Routing Header and Home Address [10] Savola, P., "Security of IPv6 Routing Header and Home Address
Options", draft-savola-ipv6-rh-ha-security-02 (work in Options", draft-savola-ipv6-rh-ha-security-02 (work in
progress), March 2002. progress), March 2002.
[11] Ferguson, P. and D. Senie, "Network Ingress Filtering: [11] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[12] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback [12] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback
Messages", draft-ietf-itrace-04 (work in progress), February Messages", draft-ietf-itrace-04 (work in progress), February
2003. 2003.
[13] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, [13] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995. June 1995.
[14] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site [14] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", Automatic Tunnel Addressing Protocol (ISATAP)",
draft-ietf-ngtrans-isatap-20 (work in progress), February 2004. draft-ietf-ngtrans-isatap-22 (work in progress), May 2004.
[15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[16] Hagino, J., "Possible abuse against IPv6 transition [16] 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.
[17] Barros, C., "Proposal for ICMP Traceback Messages", http://
www.research.att.com/lists/ietf-itrace/2000/09/msg00044.html .
[18] Merit Network Inc., "Routing Assets Database (http://
www.radb.net)".
Authors' Addresses Authors' Addresses
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo Espoo
Finland Finland
EMail: psavola@funet.fi EMail: psavola@funet.fi
Chirayu Patel Chirayu Patel
skipping to change at page 38, line 12 skipping to change at page 39, line 12
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 Appendix B. Change Log
[[ RFC-EDITOR note: to be removed before publication ]] [[ RFC-EDITOR note: to be removed before publication ]]
Changes from -02 to -03
1. Only rather minor editorial changes.
Changes from -01 to -02 Changes from -01 to -02
1. Incorporate Iljitsch's feedback 1. Incorporate Iljitsch's feedback
2. Clean up section 6.2 2. Clean up section 6.2
3. Fix encapsulation code (had been munged in -01) 3. Fix encapsulation code (had been munged in -01)
Changes from -00 to -01 Changes from -00 to -01
skipping to change at page 39, line 13 skipping to change at page 40, line 13
3. Added Chirayu Patel as a co-author. 3. Added Chirayu Patel as a co-author.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
 End of changes. 

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