own 6to4 relay. (This assumes that IPv6-only is so far away that
6to4 would be retired by that point.) That is, there would not be
third-party relays, and 2002::/16 and 192.88.99.0/24 routes would
not need to be advertised globally.
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
policies). This is something that the sites and ISPs should
already be familiar with already.
However, this presents a number of problems:
This model would shift most of the burden of supporting 6to4 to IPv6
sites that don’t employ or use 6to4 at all, i.e., "those who deploy
proper native dual-stack." It could be argued that the deployment
pain should be borne by 6to4 users, not by the others.
The main advantage of 6to4 is easy deployment and free relays. This
would require that everyone the 6to4 sites wish to communicate with
implement these measures.
The model would not fix the "relay spoofing problem", unless
everybody also deployed 6to4 addresses on the nodes (alongside with
native addresses, if necessary), which would in turn change 6to4 to
operate without relays completely.
7. Security Considerations
This document discusses security considerations of 6to4.
Even if proper checks are implemented, there are a large number of
different security threats; these threats are analyzed in Section 4.
There are mainly four classes of potential problem sources:
1. 6to4 routers not being able to identify whether relays are
legitimate
2. Wrong or impartially implemented 6to4 router or relay security
checks
3. 6to4 architecture used to participate in DoS or reflected DoS
attacks or made to participate in "packet laundering", i.e.,
making another attack harder to trace
4. 6to4 relays being subject to "administrative abuse" e.g., theft
of service or being seen as a source of abuse.
The first is the toughest problem, still under research. The second
can be fixed by ensuring the correctness of implementations; this is
important. The third is also a very difficult problem, impossible to
solve completely; therefore it is important to be able to analyze
whether this results in a significant increase of threats. The
fourth problem seems to have feasible solutions.
These are analyzed in detail in "Threat Analysis", in Section 4.
8. Acknowledgments
Some issues were first brought up by Itojun Hagino in [17], and Alain
Durand introduced one specific problem at IETF51 in August 2001
(though there was some discussion on the list prior to that); these
two gave the authors the push to start looking into the details of
securing 6to4.
Alexey Kuznetsov brought up the implementation problem with IPv6
martian checks. Christian Huitema formulated the rules that rely on
6to4 relays using only anycast. Keith Moore brought up the point
about reduced flexibility. Brian Carpenter, Tony Hain, and Vladislav
Yasevich are acknowledged for lengthy discussions. Alain Durand
reminded the authors about relay spoofing problems. Brian Carpenter
reminded the authors about the BGP-based 6to4 router model.
Christian Huitema gave a push for a more complete threat analysis.
Itojun Hagino spelled out the operators’ fears about 6to4 relay
abuse. Rob Austein brought up the idea of a different 6to4
deployment model.
In the latter phase, discussions with Christian Huitema, Brian
Carpenter, and Alain Durand were helpful when improving the document.
David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on
the document.
9. References
9.1. Normative References
[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
3068, June 2001.
9.2. Informative References
[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000.
[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.
[7] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[8] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", Work in Progress, July 2004.
[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", Work in Progress, September 2004.
[11] Savola, P., "Security of IPv6 Routing Header and Home Address
Options", Work in Progress, March 2002.
[12] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000.
[13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback
Messages", Work in Progress, February 2003.
[14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[15] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", Work in
Progress, May 2004.
[16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[17] Hagino, J., "Possible abuse against IPv6 transition
technologies", Work in Progress, July 2000.
Appendix A. Some Trivial Attack Scenarios Outlined
Here, a few trivial attack scenarios are outlined -- ones that are
prevented by implementing checks listed in [1] or in section 6.
When two 6to4 routers send traffic to each others’ domains, the
packet sent by RA to RB resembles the following:
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (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
decapsulated so that only src_v6 and dst_v6 remain, as originally
sent by RA:
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb
As every other node is just one hop away (IPv6-wise) and the
link-layer (IPv4) addresses are lost, this may open many
possibilities for misuse.
As an example, unidirectional IPv6 spoofing is made trivial because
nobody can check (without delving into IP-IP packets) whether the
encapsulated IPv6 addresses were authentic. (With native IPv6, this
can be done by, e.g., RPF-like mechanisms or access lists in upstream
routers.)
src_v6 = 2002:1234:5678::aaaa (forged)
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
A similar attack with "src" being the native address is made
possible, even with the security checks, by having the sender node
pretend to be a 6to4 relay router.
More worries come into the picture if, e.g.,
src_v6 = ::ffff:[some trusted IPv4 in a private network]
src_v6/dst_v6 = ::ffff:127.0.0.1
src_v6/dst_v6 = ::1
src_v6/dst_v6 = ...
Some implementations might have been careful enough to design the
stack so as to avoid the incoming (or reply) packets going to IPv4
packet processing through special addresses (e.g., IPv4-mapped
addresses), but who can say for all ...
Authors’ Addresses
Pekka Savola
CSC/FUNET
Espoo
Finland
EMail: psavola@funet.fi
Chirayu Patel
All Play, No Work
185, Defence Colony
Bangalore, Karnataka 560038
India
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
URI: http://www.chirayu.org
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.