draft-ietf-v6ops-6to4-security-03.txt   draft-ietf-v6ops-6to4-security-04.txt 
v6ops Working Group P. Savola v6ops Working Group P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Expires: December 16, 2004 C. Patel Expires: January 16, 2005 C. Patel
All Play, No Work All Play, No Work
June 17, 2004 July 18, 2004
Security Considerations for 6to4 Security Considerations for 6to4
draft-ietf-v6ops-6to4-security-03.txt draft-ietf-v6ops-6to4-security-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. 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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. 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 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.
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 December 16, 2004. This Internet-Draft will expire on January 16, 2005.
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
skipping to change at page 2, line 11 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 5 2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 5
2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . 5 2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . 5
2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . 5 2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . 6
2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . 6 2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . 6
2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 BGP Between 6to4 Routers and Relays . . . . . . . . . 7 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 . . . . 8
3. Functionalities of 6to4 Network Components . . . . . . . . . . 9 3. Functionalities of 6to4 Network Components . . . . . . . . . . 9
3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . 10 3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . 11
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . 12 4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . 13
4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . 13 4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . 13
4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . 14 4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . 15
4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . 17 4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . 17
4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 18 4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 19
4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . 20 4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . 21
4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . 20 4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . 21
4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . 21 4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . 21
4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . 22 4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . 23
4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 24 4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 24
4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . 24 4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . 25
4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . 26 4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . 26
4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . 27 4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . 28
4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . 27 4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . 28
5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 29 5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30
5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . 30 5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . 31
5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . 30 5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . 31
5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . 31 5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . 32
5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . 32 5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . 33
5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . 32 5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . 33
6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 33 6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34
6.1 Implementation Considerations with Automatic Tunnels . . . 33 6.1 Implementation Considerations with Automatic Tunnels . . . 34
6.2 A Different Model for 6to4 Deployment . . . . . . . . . . 34 6.2 A Different Model for 6to4 Deployment . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
10.2 Informative References . . . . . . . . . . . . . . . . . . . 36 10.2 Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38
A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 38 A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . 41
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:
1. All 6to4 routers must accept and decapsulate IPv4 packets from 1. All 6to4 routers must accept and decapsulate IPv4 packets from
every other 6to4 router, and 6to4 relays. every other 6to4 router, and 6to4 relays.
2. 6to4 relay routers must accept traffic from any native IPv6 node. 2. 6to4 relay routers must accept traffic from any native IPv6 node.
Since the 6to4 router must accept from traffic from any other 6to4 Since the 6to4 router must accept traffic from any other 6to4 router
router or relay, a certain requirement for trust is implied, and or relay, a certain requirement for trust is implied, and there are
there are no strict constraints on what the IPv6 packet may contain. no strict constraints on what the IPv6 packet may contain. Thus,
Thus, addresses within the IPv4, and IPv6 header may be spoofed, and addresses within the IPv4, and IPv6 header may be spoofed, and this
this property leads to various types of threats including different property leads to various types of threats including different
flavors of Denial of Service -attacks. flavors of Denial of Service -attacks.
The 6to4 specification outlined a few security considerations and The 6to4 specification outlined a few security considerations and
rules, but was very ambiguous on their exact requirement level. rules, but was very ambiguous on their exact requirement level.
Further, the description of the considerations was rather short, and Further, the description of the considerations was rather short, and
in fact, some of them have been proven to be difficult to understand in fact, some of them have been proven to be difficult to understand
or impossible to implement. or impossible to implement.
This draft analyzes 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.
skipping to change at page 4, line 46 skipping to change at page 4, line 46
rehashing how 6to4 is used today based on the 6to4 specification, so rehashing how 6to4 is used today based on the 6to4 specification, so
that it is easier to understand how security could be affected. that it is easier to understand how security could be affected.
Section 4 provides a threat analysis for implementations that already Section 4 provides a threat analysis for implementations that already
implement most of the security checks. Section 5 describes the implement most of the security checks. Section 5 describes the
optimal decapsulation/encapsulation rules for 6to4 implementations, optimal decapsulation/encapsulation rules for 6to4 implementations,
and Section 6 provides further discussion on a few issues which have and Section 6 provides further discussion on a few issues which have
proven to be difficult to implement. Appendix A outlines a few proven to be difficult to implement. Appendix A outlines a few
possible trivial attack scenarios in the case that very little or no possible trivial attack scenarios in the case that very little or no
security has been implemented. security has been implemented.
For the sake of simplicity, in this document, native IPv6 Internet is For the sake of simplicity, in this document, the native Internet is
assumed to encompass IPv6 networks formed using other transition assumed to encompass IPv6 networks formed using other transition
mechanisms (e.g. RFC 2893 [4]), as these mechanisms cannot talk mechanisms (e.g. RFC 2893 [4]), as these mechanisms cannot talk
directly 6to4 network. directly to the 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 RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
Throughout this memo, IPv4 addresses from blocks 7.0.0.0/24, 8.0.0.0/
24 and 9.0.0.0/24 are used for demonstrative purposes, to represent
global IPv4 addresses which have no relation to each other. This
approach was chosen instead of just using addresses from 192.0.2.0/24
[5] for two reasons: to use addresses whose 6to4 mapping is
blindingly obvious, and to make it obvious that the IPv4 addresses of
different 6to4 gateways do not have to have any relation to each
other.
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 6to4 relays that will be used in the two directions are domains, the 6to4 relays that will be used in the two directions are
very likely different; routing is highly asymmetric. Because of very likely different; routing is highly asymmetric. Because of
this, it is not feasible to limit relays from which 6to4 routers may this, it is not feasible to limit relays from which 6to4 routers may
accept traffic. 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.
skipping to change at page 7, line 10 skipping to change at page 7, line 30
2.4 Other Models 2.4 Other Models
These are more or less special cases of 6to4 operations. In later 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
Section 5.2.2.2 in [1] presents a model where, instead of static Section 5.2.2.2 in [1] presents a model where, instead of static
configuration, BGP [5] is used between 6to4 relay routers and 6to4 configuration, BGP [6] is used between 6to4 relay routers and 6to4
routers. routers (for outgoing relay selection only).
If the 6to4 router established a BGP session between all the possible Going further than [1], if the 6to4 router established a BGP session
6to4 relays, and advertised its /48 prefix to them, the traffic from between all the possible 6to4 relays, and advertised its /48 prefix
non-6to4 sites would always come from a "known" relay. to them, the traffic from non-6to4 sites would always come from a
Alternatively, the 6to4 relays might advertise the more specific 6to4 "known" relay. Alternatively, the 6to4 relays might advertise the
routes between 6to4 relays. more specific 6to4 routes between 6to4 relays.
Both of these approaches are more or less obviously infeasible due to Both of these approaches are more or less obviously infeasible due to
scalability issues. scalability issues.
Neither of these models are known to be used at the time of writing; Neither of these models are known to be used at the time of writing;
this is probably caused by the fact that parties that need 6to4 are this is probably caused by the fact that parties that need 6to4 are
those that are not able to run BGP, and because setting up these those that are not able to run BGP, and because setting up these
sessions 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 sites seem to use 6to4 as an IPv6 connectivity "optimization Some sites seem to use 6to4 as an IPv6 connectivity "optimization
method"; that is, they have also non-6to4 addresses on their nodes method"; that is, they have also non-6to4 addresses on their nodes
and border 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.
These sites also publish both 6to4 and non-6to4 addresses in DNS to These sites also publish both 6to4 and non-6to4 addresses in DNS to
affect inbound connections; if the source host's default address affect inbound connections; if the source host's default address
selection [6] works properly, 6to4 sources will use 6to4 addresses to selection [7] 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
behavior 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
skipping to change at page 10, line 11 skipping to change at page 10, line 31
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 certain specific
addresses in tunnels, or the matching 6to4 prefixes. reserved IPv4 addresses (see Section 5.3.1 for details) 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
pseudo-interface must pick the IPv4 address corresponding to the pseudo-interface must pick the IPv4 address corresponding to the
prefix when encapsulating, or else problems may ensue on e.g., prefix when encapsulating, or else problems may ensue on e.g.,
multi-interface routers.) multi-interface routers.)
o Disallow traffic where the destination IPv6 address is not a o Disallow traffic where the destination IPv6 address is not a
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.
skipping to change at page 11, line 16 skipping to change at page 11, line 35
through tunneling, using normal IPv6 routing. through tunneling, using normal IPv6 routing.
o Tunnels packets received through normal IPv6 routing from native o Tunnels packets received through normal IPv6 routing from native
addresses, and are destined for 2002::/16, to the corresponding addresses, and are destined for 2002::/16, to the corresponding
6to4 router. 6to4 router.
The 6to4 relay should also perform security checks on traffic that it The 6to4 relay should also perform security checks on traffic that it
will receive from 6to4 routers, or from native IPv6 nodes. These will receive from 6to4 routers, or from native IPv6 nodes. These
checks are: checks are:
o Disallow traffic that has private, broadcast or reserved IPv4 o Disallow traffic that has private, broadcast or certain specific
addresses in tunnels, or the matching 6to4 prefixes. reserved IPv4 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
pseudo-interface must pick the IPv4 address corresponding to the pseudo-interface must pick the IPv4 address corresponding to the
prefix when encapsulating, or else problems may ensue on e.g., prefix when encapsulating, or else problems may ensue on e.g.,
multi-interface routers.) multi-interface routers.)
o Disallow traffic where the destination IPv6 address is not a o Disallow traffic where the destination IPv6 address is not a
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.
skipping to change at page 12, line 32 skipping to change at page 12, line 52
The attacks descriptions are classified based on the target of the The attacks descriptions are classified based on the target of the
attack: attack:
1. Attacks on 6to4 networks. 1. Attacks on 6to4 networks.
2. Attacks on IPv6 networks. 2. Attacks on IPv6 networks.
3. Attacks on IPv4 networks. 3. Attacks on IPv4 networks.
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.
Note, one of the mitigation methods listed for various attacks is Note, one of the mitigation methods listed for various attacks is
based on the premise that 6to4 relays will a have a feature that may based on the premise that 6to4 relays could have a feature that may
be able to limit traffic to/from specific 6to4 sites. At the time of be able to limit traffic to/from specific 6to4 sites. At the time of
writing this document, such a feature is speculation, and more work writing this document, such a feature is speculation, and more work
needs to be done to determine the logistics of such a feature. needs to be done to determine the logistics of such a feature.
4.1 Attacks on 6to4 Networks 4.1 Attacks on 6to4 Networks
This section describes attacks against 6to4 networks. Attacks which This section describes attacks against 6to4 networks. Attacks which
leverage 6to4 networks, but where the ultimate victim is elsewhere leverage 6to4 networks, but where the ultimate victim is elsewhere
(e.g., a native IPv6 user, an IPv4 user) are described later in the (e.g., a native IPv6 user, an IPv4 user) are described later in the
memo. memo.
skipping to change at page 13, line 46 skipping to change at page 14, line 16
dst_v6 = fe80::1 (valid or invalid address) dst_v6 = fe80::1 (valid or invalid address)
src_v4 = 8.0.0.1 (valid or forged address) src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6) dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
These attacks are exacerbated in case the implementation supports These attacks are exacerbated in case the implementation supports
more tunneling mechanisms than just 6to4 (or configured tunneling), more tunneling mechanisms than just 6to4 (or configured tunneling),
because it is impossible to disambiguate such mechanisms, making it because it is impossible to disambiguate such mechanisms, making it
difficult to enable strict security checks (see Section 6.1). difficult to enable strict security checks (see Section 6.1).
The Neighbor Discovery threats (Redirect DoS, or DoS) are described The Neighbor Discovery threats (Redirect DoS, or DoS) are described
in [7]. Note that all attacks may not be applicable, as the 6to4 in [8]. Note that all attacks may not be applicable, as the 6to4
pseudo-interface is assumed not to have a link-layer address (Section 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 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. be either a router or host from the Neighbor Discovery perspective.
THREAT ANALYSIS AND MITIGATION METHODS THREAT ANALYSIS AND MITIGATION METHODS
The attacks can be mitigated by using any of the following 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 o The usage of ND messages could be prohibited. It implies that all
packets using addresses of scope link-local will be silently packets using addresses of scope link-local will be silently
discarded. Section 3.1 of RFC 3056 [1] leaves scope for future discarded. Section 3.1 of RFC 3056 [1] leaves scope for future
uses of link-local address. This method has its pitfalls - it uses of link-local address. This method has its pitfalls - it
would prohibit any sort of ND message, and thus close the doors on would prohibit any sort of ND message, and thus close the doors on
development, and use of other ND options. Whether this is a development, and use of other ND options. Whether this is a
significant problem is another thing. significant problem is another thing.
o The 6to4 pseudo-interface could be insulated from the other o The 6to4 pseudo-interface could be insulated from the other
interfaces (for example, using a separate neighbor cache). interfaces, particularly the other tunnel interfaces (if any), for
example using a separate neighbor cache.
o Either IPsec [4] or an extension of SEND could be used [8] to o If ND messages are needed, either IPsec [4] or an extension of
secure packet exchange using link-local address; vanilla SEND SEND could be used [9] to secure packet exchange using link-local
would not work as the link-layer does not have an address -- and address; vanilla SEND would not work as the link-layer does not
IPsec would be rather complex. have an address -- and IPsec would be rather complex.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
Even though rather simply fixable, this attack is not new as such; Even though rather simply fixable, this attack is not new as such;
the same is possible using automatic tunneling [4] or configured the same is possible using automatic tunneling [4] or configured
tunneling (if one is able to spoof source IPv4 address to that of the tunneling (if one is able to spoof source IPv4 address to that of the
tunnel end-point). tunnel end-point).
However, as 6to4 provides open decapsulation, and automatic tunneling However, as 6to4 provides open decapsulation, and automatic tunneling
is being deprecated [9], 6to4 provides an easy means which would not is being deprecated [10], 6to4 provides an easy means which would not
exist without 6to4. exist without 6to4.
4.1.2 Spoofing Traffic to 6to4 Nodes 4.1.2 Spoofing Traffic to 6to4 Nodes
ATTACK DESCRIPTION ATTACK DESCRIPTION
The attacker - a malicious IPv4 or IPv6 node - can send packets which The attacker - a malicious IPv4 or IPv6 node - can send packets which
are difficult to trace (e.g., due to spoofing or going through a are difficult to trace (e.g., due to spoofing or going through a
relay) to a 6to4 node. This can be used e.g., to accomplish a DoS relay) to a 6to4 node. This can be used e.g., to accomplish a DoS
attack. attack.
skipping to change at page 15, line 15 skipping to change at page 15, line 33
node. From IPv4 nodes, src_v4 can be either a spoofed or the real node. From IPv4 nodes, src_v4 can be either a spoofed or the real
source address. source address.
The 6to4 router receives these packets from 8.0.0.1, decapsulates 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 them, discards the IPv4 header containing the source address 8.0.0.1
and processes them as normal (the attacker has guessed or obtained and processes them as normal (the attacker has guessed or obtained
"dst_v6" using one of a number of techniques). "dst_v6" using one of a number of techniques).
This is a DoS attack on 6to4 nodes. This is a DoS attack on 6to4 nodes.
This attack is similar to ones shown in [10]. This attack is similar to ones shown in [11].
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 the victim (src_v6), above. All the traces from the original
attacker (src_v4) have been discarded. These return packets will go attacker (src_v4) have been discarded. These return packets will go
skipping to change at page 16, line 34 skipping to change at page 16, line 50
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. Unfortunately,
this would depend on significant (or even complete) ingress
filtering everywhere in other networks; while this is highly
desirable, it may also be practically unfeasible.
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. This has very little
cost.
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] would have to be solutions like ingress filtering [12] or itrace [13] 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. (Note that itrace work has been discontinued, as of of the attacks. A total penetration is likely impossible to achieve.
this writing.) (Note that itrace work has been discontinued, as of this writing in
July 2004.)
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
skipping to change at page 18, line 4 skipping to change at page 18, line 24
are involved in sending spoofed traffic with the same src_v6. are involved in sending spoofed traffic with the same src_v6.
Malicious 6to4 nodes can also (try to) initiate this attack by Malicious 6to4 nodes can also (try to) initiate this attack by
bouncing traffic off 6to4 nodes in other 6to4 sites. However this 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 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 the attack is being launched) will filter packets with forged source
address (with security checks mentioned in Section 5), and thus the address (with security checks mentioned in Section 5), and thus the
attack will be prevented. attack will be prevented.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The reverse traffic in this case are replies to the messages received 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 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 in this case, and this would inhibit certain types of attacks. For
example, flooding a 6to4 node with TCP SYN packets will not be example, flooding a 6to4 node with TCP SYN packets will not be
possible (but e.g., a SYN-ACK or RST would be). possible (but e.g., a SYN-ACK or RST would be).
These attacks may be countered in various ways: These attacks may be mitigated in various ways:
o Implementation of ingress filtering by the IPv4 service providers. o Implementation of ingress filtering by the IPv4 service providers.
It would prevent forging of the src_v4 address, and would help in 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 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 difficult to shut down the attack if a large number of IPv4 nodes
are involved. are involved.
These attacks may be also be stopped at the 6to4 sites if the 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 culprit src_v4 address is identified, and if it is constant, by
filtering traffic from this address. Note that it would be filtering traffic from this address. Note that it would be
difficult to implement this method, if appropriate logging is not difficult to implement this method, if appropriate logging is not
done by the 6to4 router, or if a large number of 6to4 nodes, and/ 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. or a large number of IPv4 nodes are participating in the attack.
Unfortunately, as many IPv4 service providers don't implement
ingress filtering, for whatever reasons, this may not be a
satisfactory resolution.
o Implementation of ingress filtering by all IPv6 service providers o Implementation of ingress filtering by all IPv6 service providers
would eliminate this attack, because src_v6 could not be spoofed would eliminate this attack, because src_v6 could not be spoofed
to be a 6to4 address. However, expecting this to happen may not to be a 6to4 address. However, expecting this to happen may not
be practical. be practical.
o Proper implementation of security checks (see Section 5) both at o Proper implementation of security checks (see Section 5) both at
the 6to4 relays and routers would eliminate the attack, when the 6to4 relays and routers would eliminate the attack, when
launched from an IPv4 node, except when the IPv4 source address launched from an IPv4 node, except when the IPv4 source address
was also spoofed -- but then the attacker would have been able to was also spoofed -- but then the attacker would have been able to
just attack the ultimate destination directly. just attack the ultimate destination directly.
o Rate limiting traffic at the 6to4 relays. In a scenario where o Rate limiting traffic at the 6to4 relays. In a scenario where
most of the traffic is passing through few 6to4 relays, these most of the traffic is passing through few 6to4 relays, these
relays can implement traffic rate-limiting features, and relays can implement traffic rate-limiting features, and
rate-limit the traffic from 6to4 sites rate-limit the traffic from 6to4 sites.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
This particular attack can be mitigated by proper implementation of This particular attack can be mitigated by proper implementation of
security checks and ingress filtering; where ingress filtering is not security checks (which is quite straightforward) and ingress
implemented, it's typically easier to attack directly than through filtering; where ingress filtering is not implemented, it's typically
reflection -- unless "traffic laundering" is an explicit goal in the easier to attack directly than through reflection -- unless "traffic
attack. Therefore, this attack does not seem very serious. laundering" is an explicit goal in the attack. Therefore, this
attack does not seem very serious.
4.1.4 Local IPv4 Broadcast Attack 4.1.4 Local IPv4 Broadcast Attack
ATTACK DESCRIPTION ATTACK DESCRIPTION
This threat is applicable if the 6to4 router does not check whether This threat is applicable if the 6to4 router does not check whether
the IPv4 address it tries to send encapsulated IPv6 packets to a the IPv4 address it tries to send encapsulated IPv6 packets to a
local broadcast address, or a multicast address. local broadcast address, or a multicast address.
This threat is described in the specification [1], and implementing This threat is described in the specification [1], and implementing
the checks eliminates this threat. However, as this has not been the checks eliminates this threat. However, as this has not been
widely implemented, it is included here regardless for completeness. widely implemented, it is included here regardless for completeness.
There practically two kinds of attacks: where a local 6to4 user tries There practically two kinds of attacks: where a local 6to4 user tries
to send packets to the address corresponding to the broadcast to send packets to the address corresponding to the broadcast
skipping to change at page 19, line 27 skipping to change at page 20, line 6
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, containing a link to an invalid URL (for example, http://
http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 [2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology
technology based network. Opening of the mail simultaneously would based network. Opening of the mail simultaneously would result in a
result in a broadcast storm. 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 22, line 21 skipping to change at page 22, line 49
could tone down the attack. could tone down the attack.
o For every packet sent, at most one reply packet is generated: o For every packet sent, at most one reply packet is generated:
there is no amplification factor. there is no amplification factor.
Some of the mitigation methods for such attacks are: Some of the mitigation methods for such attacks are:
1. Ingress filtering in the IPv4 Internet to prevent packets with 1. Ingress filtering in the IPv4 Internet to prevent packets with
spoofed IPv4 source being transmitted. As the relay checks that spoofed IPv4 source being transmitted. As the relay checks that
the 6to4 address embeds the IPv4 address, no spoofing can be the 6to4 address embeds the IPv4 address, no spoofing can be
achieved done unless IPv4 addresses can be spoofed. achieved done unless IPv4 addresses can be spoofed. However,
this would probably be an unfeasible requirement.
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 6to4 nodes, or IPv4 nodes) that has non-6to4 traffic (from 6to4 nodes, or IPv4 nodes) that has non-6to4
addresses as source address, or where the source IPv4 address addresses as source address, or where the source IPv4 address
does not match the address embebdded in the source IPv6 address. does not match the address embebdded in the source IPv6 address.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
Compared to Section 4.1.2, which is more serious, this threat appears Compared to Section 4.1.2, which is more serious, this threat appears
to be slightly more manageable. If the relays perform proper to be slightly more manageable. If the relays perform proper
skipping to change at page 23, line 22 skipping to change at page 24, line 4
from a 6to4/IPv4 node, the traffic goes through a relay only after from a 6to4/IPv4 node, the traffic goes through a relay only after
the reflection. the reflection.
EXTENSIONS EXTENSIONS
A distributed Reflection DoS can be performed if a large number of A distributed Reflection DoS can be performed if a large number of
native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed
traffic with the same source IPv6 address. traffic with the same source IPv6 address.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
Some of the mitigation methods for such attacks are: Some of the mitigation methods for such attacks are:
1. Attacks from the native IPv6 nodes could be stopped by 1. Attacks from the native IPv6 nodes could be stopped by
implementing ingress filtering in the IPv6 Internet. implementing ingress filtering in the IPv6 Internet; hopefully
this will become commonplace, but past experience of IPv4 ingress
filtering deployment (or lack thereof) does not promise much.
2. Two measures are needed to stop or mitigate the attacks from IPv4 2. Two measures are needed to stop or mitigate the attacks from IPv4
nodes: 1) Implementing ingress filtering in the IPv4 internet, nodes: 1) Implementing ingress filtering in the IPv4 internet,
and 2) logging IPv4 source address in the 6to4 router. and 2) logging IPv4 source address in the 6to4 router.
3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4 3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4
router in those sites implements egress filtering. router in those sites implements egress filtering. This could be
done by those sites, but the sites who are most likely to be
abused are typically also most likely to be neglecting to
installing appropriate filtering at their edges.
4. The traffic passes through one or two relays, and traffic rate 4. The traffic passes through one or two relays, and traffic rate
limiting in the 6to4 relays might help tone down the reflection limiting in the 6to4 relays might help tone down the reflection
attack. attack.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
Even thought there are means to mitigate the attack, it is still Even thought there are means to mitigate the attack, it is still
rather efficient, especially when used by native IPv6 nodes with rather efficient, especially when used by native IPv6 nodes with
spoofed addresses. Using 6to4 relays and routers could easily take spoofed addresses. Using 6to4 relays and routers could easily take
skipping to change at page 25, line 49 skipping to change at page 26, line 35
1. Usage of access lists in the relay to limit access. 1. Usage of access lists in the relay to limit access.
2. Filtering out the packets with a routing header (may have other 2. Filtering out the packets with a routing header (may have other
implications). implications).
3. Monitoring the source addresses going through the relay, to 3. Monitoring the source addresses going through the relay, to
detect e.g. peers setting up static routes. detect e.g. peers setting up static routes.
Routing Header is not specific to 6to4, the main things one could do 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 here with it would be to select the relay; some generic threats about
Routing Header use are described in [10]. Routing Header use are described in [11].
As this threat does not have implications on other than the As this threat does not have implications on other than the
organization providing 6to4 relay, it is not analyzed any further. organization providing 6to4 relay, it is not analyzed any further.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
These threats are specific to 6to4 relays (or in general, anycast These threats are specific to 6to4 relays (or in general, anycast
services), and do not exist in networks without 6to4. services), and do not exist in networks without 6to4.
4.2.6 Relay Operators Seen as Source of Abuse 4.2.6 Relay Operators Seen as Source of Abuse
skipping to change at page 26, line 51 skipping to change at page 27, line 37
None. None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 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. problems to the other operations.
Further, when someone is filing complaints to the owner of Further, when someone is filing complaints to the owner of
192.88.99.0/24, they notice multiple WHOIS records and see a pointer 192.88.99.0/24, depending on which registry they are querying, they
to [3], and may learn that the 6to4 relay is in fact innocent. Of might get, for example:
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 o Knowledge that this is a special IANA address block, with no real
incident. contact person,
o Knowledge that this is a special address block for RFC 3068, or
o Knowledge that this is a special address block for RFC 3068, and
that there are multiple entries in the database by relay
operators.
Any of these, at least when processed by a human, should make one
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.
However, the wide-spread usage of 192.88.99.1 as the source address However, the wide-spread usage of 192.88.99.1 as the source address
may make it more difficult to disambiguate the relays, which might be may make it more difficult to disambiguate the relays, which might be
a useful feature for debugging purposes. a useful feature for debugging purposes.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
This threat is caused by 6to4 deployment, but can be avoided, at This threat is caused by 6to4 deployment, but can be avoided, at
least in the short-term, by using the use of 192.88.99.1 as the least in the short-term, by using the use of 192.88.99.1 as the
source address. source address.
skipping to change at page 31, line 31 skipping to change at page 32, line 31
5.3 IPv4 and IPv6 Sanity Checks 5.3 IPv4 and IPv6 Sanity Checks
The encapsulation and decapsulation checks included certain sanity The encapsulation and decapsulation checks included certain sanity
checks for both IPv4 and IPv6. These are described here in detail. checks for both IPv4 and IPv6. These are described here in detail.
5.3.1 IPv4 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 [13], and others widely used and known not to be global. These in [14], and others widely used and known not to be global. 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)
skipping to change at page 33, line 26 skipping to change at page 34, 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] [15] and Automatic Tunneling using Compatible Addresses [4]
(currently removed [9] but typically still supported). All of these (currently removed [10] but typically still supported). All of these
use IP-IP (protocol 41) [15] IPv4 encapsulation with, more or less, a use IP-IP (protocol 41) [16] IPv4 encapsulation with, more or less, a
pseudo-interface. 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
skipping to change at page 35, line 44 skipping to change at page 36, line 44
These are analyzed in detail in Threat Analysis, in Section 4. These are analyzed in detail in Threat Analysis, in Section 4.
8. IANA Considerations 8. IANA Considerations
This memo makes no requet to IANA. (RFC-editor note: please remove This memo makes no requet to IANA. (RFC-editor note: please remove
this section on publication.) this section on publication.)
9. Acknowledgments 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 [17], 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
about 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
skipping to change at page 36, line 37 skipping to change at page 37, line 37
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.
10.2 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] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[6] 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 [7] 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., Kempf, J. and E. Nordmark, "IPv6 Neighbor [8] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[8] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, [9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05
(work in progress), April 2004. (work in progress), April 2004.
[9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for [10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in
progress), June 2004. progress), June 2004.
[10] Savola, P., "Security of IPv6 Routing Header and Home Address [11] 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: [12] 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 [13] 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, [14] 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 [15] 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-22 (work in progress), May 2004. draft-ietf-ngtrans-isatap-22 (work in progress), May 2004.
[15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[16] Hagino, J., "Possible abuse against IPv6 transition [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.
Authors' Addresses Authors' Addresses
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo Espoo
Finland Finland
skipping to change at page 38, line 11 skipping to change at page 39, line 20
Phone: +91-98452-88078 Phone: +91-98452-88078
EMail: chirayu@chirayu.org EMail: chirayu@chirayu.org
URI: http://www.chirayu.org URI: http://www.chirayu.org
Appendix A. Some Trivial Attack Scenarios Outlined 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 [1] 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:
examples of global IPv4 addresses):
src_v6 = 2002:0800:0001::aaaa src_v6 = 2002:0800:0001::aaaa
dst_v6 = 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_v6 and dst_v6 remain, as originally decapsulated so that only src_v6 and dst_v6 remain, as originally
sent by RA: sent by RA:
skipping to change at page 39, line 11 skipping to change at page 40, line 20
src_v6/dst_v6 = ... 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 Appendix B. Change Log
[[ RFC-EDITOR note: to be removed before publication ]] [[ RFC-EDITOR note: to be removed before publication ]]
Changes from -03 to -04
1. Some editorial fixes; resolve IESG evaluation comments.
Changes from -02 to -03 Changes from -02 to -03
1. Only rather minor editorial changes. 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
 End of changes. 

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