draft-ietf-v6ops-teredo-security-concerns-00.txt   draft-ietf-v6ops-teredo-security-concerns-01.txt 
IPv6 Operations Working Group J. Hoagland IPv6 Operations Working Group J. Hoagland
Internet-Draft Symantec Internet-Draft Symantec
Expires: January 27, 2008 S. Krishnan Expires: May 19, 2008 S. Krishnan
Ericsson Ericsson
July 26, 2007 November 16, 2007
Teredo Security Concerns Teredo Security Concerns
draft-ietf-v6ops-teredo-security-concerns-00 draft-ietf-v6ops-teredo-security-concerns-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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://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 January 27, 2008. This Internet-Draft will expire on May 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Additional security concerns with Teredo are documented, beyond what Additional security concerns with Teredo are documented, beyond what
is in RFC 4380. This is based on an independent analysis of Teredo's is in RFC 4380. This is based on an independent analysis of Teredo's
security implications. The primary intent of this document is to security implications. The primary intent of this document is to
provide information and recommendations to the IETF that can be used raise the awareness regarding the security issues in Teredo as
in any updated Teredo specification. The second intended audience is deployed today.
anyone that can help improve security in Teredo as deployed, so they
will be aware of these concerns.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Teredo Bypasses Security . . . . . . . . . . . . . . . . . . . 3 2. Teredo Bypasses Security . . . . . . . . . . . . . . . . . . . 3
2.1. Teredo Bypasses Network Security . . . . . . . . . . . . . 3 2.1. Teredo Bypasses Network Security . . . . . . . . . . . . . 3
2.2. IPv6 Ingress and Egress Filtering Bypass . . . . . . . . . 5 2.2. IPv6 Ingress and Egress Filtering Bypass . . . . . . . . . 5
2.3. Source Routing After the Teredo Client . . . . . . . . . . 6 2.3. Source Routing After the Teredo Client . . . . . . . . . . 6
3. Challenges in Inspecting and Filtering Content of Teredo 3. Challenges in Inspecting and Filtering Content of Teredo
Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7 Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Inefficiency of Selective Network Filtering of All 3.1. Inefficiency of Selective Network Filtering of All
Teredo Packets . . . . . . . . . . . . . . . . . . . . . . 7 Teredo Packets . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Problems with deep packet inspection of Teredo data 3.2. Problems with deep packet inspection of Teredo data
packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 packets . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Increased Exposure Due to Teredo . . . . . . . . . . . . . . . 10 4. Increased Exposure Due to Teredo . . . . . . . . . . . . . . . 9
4.1. Teredo NAT Holes Increase Attack Surface . . . . . . . . . 10 4.1. Teredo NAT Holes Increase Attack Surface . . . . . . . . . 9
4.2. Unusually High Exposure of a NAT Hole . . . . . . . . . . 11 4.2. Unusually High Exposure of a NAT Hole . . . . . . . . . . 11
4.3. Teredo Bubble Facility Widens Hole in Restricted NAT . . . 12 4.3. Teredo Bubble Facility Widens Hole in Restricted NAT . . . 11
5. Teredo Address Concerns . . . . . . . . . . . . . . . . . . . 13 5. Teredo Address Concerns . . . . . . . . . . . . . . . . . . . 12
5.1. Feasibility of Guessing Teredo Addresses . . . . . . . . . 13 5.1. Feasibility of Guessing Teredo Addresses . . . . . . . . . 12
5.2. Profiling Targets Based on Teredo Address . . . . . . . . 14 5.2. Profiling Targets Based on Teredo Address . . . . . . . . 12
6. Additional Security Concerns . . . . . . . . . . . . . . . . . 16 6. Additional Security Concerns . . . . . . . . . . . . . . . . . 14
6.1. Attacks Facilitated By Changing Teredo Server Setting . . 16 6.1. Attacks Facilitated By Changing Teredo Server Setting . . 14
6.2. RFC 4380 Implies That Teredo Improves Security . . . . . . 18 6.2. RFC 4380 Implies That Teredo Improves Security . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
An independent analysis of Teredo's security implications was An independent analysis of Teredo's security implications was
conducted by Symantec[TTPTPNSOSI], based on the Teredo specification conducted by Symantec[TEREDOSEC], based on the Teredo specification
([RFC4380]). This analysis uncovered some security concerns ([RFC4380]). This analysis uncovered some security concerns
associated with Teredo which are not documented in the Teredo associated with Teredo which are not documented in the Teredo
specification. This document discloses these additional concerns and specification. This document discloses these additional concerns and
includes any recommendations where relevant. This Internet Draft is includes any recommendations where relevant. This Internet Draft is
also influenced to an extent by an examination of the Teredo also influenced to an extent by an examination of the Teredo
implementation on Microsoft Windows Vista [WVNASA]. implementation on Microsoft Windows Vista [WVNASA].
The primary intent of this document is to provide information so that The primary intent of this document is to provide information so that
can be used in any updated Teredo specification. Secondarily, this can be used in any updated Teredo specification. Secondarily, this
document can help improve security in Teredo as deployed (including document can help improve security in Teredo as deployed (including
skipping to change at page 6, line 29 skipping to change at page 6, line 29
2.3.1. Problem 2.3.1. Problem
If the encapsulated IPv6 packet specifies source routing beyond the If the encapsulated IPv6 packet specifies source routing beyond the
recipient Teredo client, the host may forward the IPv6 packet to the recipient Teredo client, the host may forward the IPv6 packet to the
specified next hop. This may be unexpected and contrary to specified next hop. This may be unexpected and contrary to
administrator wishes and may have bypassed network-based source administrator wishes and may have bypassed network-based source
routing controls. routing controls.
2.3.2. Discussion 2.3.2. Discussion
IPv6 source routing, while provided for in RFC 2460 [RFC2460] and A detailed discussion of issues related to source routing can be
required in some cases such as mobile IPv6, is often not needed or found in [RH0]
desired in a given network. Thus it is often blocked, at least for
certain types of source routing. The danger is that source routing,
by providing a reflection point, violates assumptions made in network
security decisions. In addition there is often no compelling case
for why it would be needed.
Consider the case where a Teredo packet reaches a Teredo client (and
is accepted) and the encapsulated IPv6 packet contains a Routing
header. The Routing header indicates that this is not the intended
destination (just a hop in a source route). Unless the Teredo client
has source routing disabled, it would pass the IPv6 packet on to the
next hop. One way to use this for an attack is to have the next hop
be a node internal to the network the client is on. Another is to
pass the packet back outside, using the Teredo node as a reflection
point.
This behavior is not specific to Teredo packets; it works in the same
way for all IPv6 packets. However, with native IPv6 packets, a
gateway prohibition of source routed packets would have prevented the
packet from even reaching the internal host. With Teredo active, the
burden is placed upon the end hosts, at least those running Teredo.
Source routing post-Teredo may also be a surprising possibility
(packets on an end-to-end tunnel not stopping at the end) that might
not have been anticipated in network controls, especially given that
a NAT was traversed in the process. RFC 4380 made no mention of
source routing.
2.3.3. Recommendations 2.3.3. Recommendations
Teredo clients should by default discard tunneled IPv6 packets that Teredo clients should by default discard tunneled IPv6 packets that
specify additional routing, though they may also allow the user to specify additional routing, though they may also allow the user to
configure what source routing types are allowed. All pre-existing configure what source routing types are allowed. All pre-existing
source routing controls should be upgraded to apply these controls to source routing controls should be upgraded to apply these controls to
Teredo tunneled IPv6 packets as well. Teredo tunneled IPv6 packets as well.
3. Challenges in Inspecting and Filtering Content of Teredo Data 3. Challenges in Inspecting and Filtering Content of Teredo Data
skipping to change at page 13, line 19 skipping to change at page 12, line 40
the attacker opportunity related to this exposure. the attacker opportunity related to this exposure.
5. Teredo Address Concerns 5. Teredo Address Concerns
5.1. Feasibility of Guessing Teredo Addresses 5.1. Feasibility of Guessing Teredo Addresses
5.1.1. Problem 5.1.1. Problem
It may be feasible guess Teredo addresses, either when looking for a It may be feasible guess Teredo addresses, either when looking for a
specific Teredo client or when looking for an arbitrary Teredo specific Teredo client or when looking for an arbitrary Teredo
client. This is in contrast to native IPv6 address in general. client. This is in contrast to native IPv6 address in general. A
companion document [TEREDOUP] provides a possible solution for this
5.1.2. Discussion problem.
Teredo addresses are structured and some of the fields contained them
are fairly predictable. This can be used to better predict the
address.
Teredo prefix: This field is 32 bits and has a single IANA assigned
value
Server: This field is 32 bits and is set to the server in use. The
server to use is usually statically configured on the client; this
may resolve to one or a small number of IPv4 addresses for the
server. Certain static configurations can be reasonably expected
to be common (e.g., those that are the default with a Teredo
client implementation). This suggests that overall entropy of the
server field will be low, i.e., that the server will not be hard
to predict. Attackers could confine their guessing to the most
popular server IP addresses.
Flags: The flags field is 16 bits in length, but RFC 4380 provides
for only one of these bits (the cone bit) to vary.
Client port: This 16 bit field corresponds to the external port
number assigned to the client's Teredo service port. Thus the
value of this field depends on two factors (the chosen Teredo
service port and the NAT port assignment behavior) and therefore
it is harder to predict the entropy this field will have. If
clients tend to use a predictable port number and NATs are often
port-preserving ([RFC4787]), then the port number can be rather
predictable.
Client IPv4 address: This 32 bit field corresponds to the external
IPv4 address the NAT has assigned for the client port. In
principle, this can be any address in the assigned part of the
IPv4 unicast address space. However, if an attacker is looking
for the address of a specific Teredo client, they will have to
have the external IPv4 address pretty well narrowed down. Certain
IPv4 address ranges could also become well known for having a
higher concentration of Teredo clients, making it easier to find
an arbitrary Teredo client. These addresses could correspond to
large organizations that allows Teredo such as a university or
enterprise or to Internet Service Providers that only provide
their customers with RFC 1918 addresses.
Optimizations in scanning can also reduce the number addresses that
need to be checked. For example, for addresses behind a cone NAT, it
would likely be easy to probe if a specific port number is open on a
IPv4 address, prior to trying to form a Teredo address for that
address and port.
Most of this is elaborated on more in [TTPTPNSOSI].
5.1.3. Recommendations
The Microsoft web site [MSTO] indicates that Windows Vista and
Longhorn make additional use of the flags field, beyond what the RFC
specifies. 12 bits (the "A" bits in "CRAAAAUG AAAAAAAA") are chosen
at random by the client at the end of qualification. Assuming there
is no bias in those bit settings, then this adds 12 additional bits
of entropy (4096 times as many addresses). We recommend this be
formally added to the next version of the Teredo specification.
The other thing we can recommend is that the client chose the Teredo
service port in as random manner as feasible, in case the NAT port
assignment behavior is based on the internal port number.
5.2. Profiling Targets Based on Teredo Address 5.2. Profiling Targets Based on Teredo Address
5.2.1. Problem 5.2.1. Problem
An attacker encountering a Teredo address has the opportunity to An attacker encountering a Teredo address has the opportunity to
infer certain relevant pieces of information that can be used to infer certain relevant pieces of information that can be used to
profile the host before sending any packets. This can reduce the profile the host before sending any packets. This can reduce the
attacker's footprint and increase the attacker's efficiency. attacker's footprint and increase the attacker's efficiency.
skipping to change at page 16, line 7 skipping to change at page 14, line 10
The cone bit tells the attacker whether a bubble is needed to proceed The cone bit tells the attacker whether a bubble is needed to proceed
a connection. It may also have some value in terms of profiling to a connection. It may also have some value in terms of profiling to
the extent that it reveals the security posture of the network. If the extent that it reveals the security posture of the network. If
the cone bit is set, the attacker may decide it is fruitful to port the cone bit is set, the attacker may decide it is fruitful to port
scan the embedded external IPv4 address and others associated with scan the embedded external IPv4 address and others associated with
the same organization, looking for open ports. the same organization, looking for open ports.
5.2.3. Recommendations 5.2.3. Recommendations
Deprecating the cone bit would prevent the a priori revelation of the
security posture of the NAT and would not reduce the functionality of
the Teredo protocol.
If installation programs randomized the server setting, that would If installation programs randomized the server setting, that would
reduce the extent to which they can be profiled. Similarly, reduce the extent to which they can be profiled. Similarly,
administrators can chose to change the default setting to reduce the administrators can chose to change the default setting to reduce the
degree to which they can be profiled ahead of time. degree to which they can be profiled ahead of time.
Randomizing the Teredo client port in use would mitigate any Randomizing the Teredo client port in use would mitigate any
profiling that can be done based on the external port, especially if profiling that can be done based on the external port, especially if
multiple different Teredo clients did this. multiple different Teredo clients did this.
A companion document [TEREDOUP] provides a possible solution for
avoiding the disclosure of the network's security posture
6. Additional Security Concerns 6. Additional Security Concerns
6.1. Attacks Facilitated By Changing Teredo Server Setting 6.1. Attacks Facilitated By Changing Teredo Server Setting
6.1.1. Problem 6.1.1. Problem
Malware or a malicious user could change a Teredo client's server Malware or a malicious user could change a Teredo client's server
setting. This would allow them to at least monitor peer IPv6 setting. This would allow them to at least monitor peer IPv6
addresses and at worst pretend to represent the remote peer. addresses and at worst pretend to represent the remote peer.
skipping to change at page 19, line 16 skipping to change at page 17, line 22
6.2.3. Recommendations 6.2.3. Recommendations
We recommend that no claims regarding a positive security impact from We recommend that no claims regarding a positive security impact from
Teredo be made, unless the scope of such a claim is immediately Teredo be made, unless the scope of such a claim is immediately
clear. We also recommend that the security concerns identified in clear. We also recommend that the security concerns identified in
this document be included in an updated Teredo standard document, this document be included in an updated Teredo standard document,
except to the extent that the Teredo protocol has been improved to except to the extent that the Teredo protocol has been improved to
mitigate them. mitigate them.
7. Security Considerations 7. Acknowledgments
The authors would like to thank Remi Denis-Courmont, Dave Thaler,
Fred Templin, Jori Palet Martinez, James Woodyatt and Christian
Huitema for reviewing earlier versions of the document and providing
comments to make this document better.
8. Security Considerations
This document identified security concerns with Teredo that were not This document identified security concerns with Teredo that were not
included in RFC 4380. included in RFC 4380.
8. IANA Considerations 9. IANA Considerations
There are no IANA considerations from this document. There are no IANA considerations from this document.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol "Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", RFC 4214, October 2005. (ISATAP)", RFC 4214, October 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation 10.2. Informative References
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
9.2. Informative References
[MSTO] Microsoft, "Teredo Overview", <http://www.microsoft.com/ [RH0] Abley, J., "Deprecation of Type 0 Routing Headers in
technet/prodtechnol/winxppro/maintain/teredo.mspx>. IPv6", draft-ietf-ipv6-deprecate-rh0-01 (work in
progress), June 2007.
[TTPTPNSOSI] [TEREDOSEC]
Hoagland, J., "The Teredo Protocol: Tunneling Past Network Hoagland, J., "The Teredo Protocol: Tunneling Past Network
Security and Other Security Implications", November 2006, Security and Other Security Implications", November 2006,
<http://www.symantec.com/avcenter/reference/ <http://www.symantec.com/avcenter/reference/
Teredo_Security.pdf>. Teredo_Security.pdf>.
[TEREDOUP]
Krishnan, S. and J. Hoagland, "Teredo Security Updates",
draft-krishnan-v6ops-teredo-update-00 (work in progress),
November 2007.
[WVNASA] Hoagland, J., Conover, M., Newsham, T., and O. Whitehouse, [WVNASA] Hoagland, J., Conover, M., Newsham, T., and O. Whitehouse,
"Windows Vista Network Surface Analysis", March 2007, <htt "Windows Vista Network Surface Analysis", March 2007,
p://www.symantec.com/avcenter/reference/ <http://www.symantec.com/avcenter/reference/
Vista_Network_Attack_Surface_RTM.pdf>. Vista_Network_Attack_Surface_RTM.pdf>.
Authors' Addresses Authors' Addresses
James Hoagland James Hoagland
Symantec Corporation Symantec Corporation
350 Ellis St. 350 Ellis St.
Mountain View, CA 94043 Mountain View, CA 94043
US US
 End of changes. 24 change blocks. 
145 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/