IPv6 Operations Working Group S. Krishnan
Internet-Draft Ericsson
Expires: August 28, 2008 J. Hoagland
Symantec
February 25, 2008
Teredo Security Updates
draft-krishnan-v6ops-teredo-update-02
Status of this Memo
By submitting this Internet-Draft, each 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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Additional security concerns with Teredo are documented, beyond what
is in RFC 4380. This is based on an independent analysis of Teredo's
security implications. The primary intent of this document is to
describe the updates required to update the Teredo specification.
Krishnan & Hoagland Expires August 28, 2008 [Page 1]
Internet-Draft Teredo Security Updates February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Randomize flags . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deprecate cone bit . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed changes . . . . . . . . . . . . . . . . . . . . . . . 4
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Krishnan & Hoagland Expires August 28, 2008 [Page 2]
Internet-Draft Teredo Security Updates February 2008
1. Introduction
An independent analysis of Teredo's security implications was
conducted by Symantec[TEREDOSEC], based on the Teredo specification
([RFC4380]). This analysis uncovered some security concerns
associated with Teredo which are not documented in the Teredo
specification. This document discloses these additional concerns
proposes the updates required to Teredo in order to address these
concerns. This Internet Draft is also influenced to an extent by an
examination of the Teredo implementation on Microsoft Windows Vista
[WVNASA]. This draft recommeds two changes to Teredo in order to
make it more secure.
2. Randomize flags
Teredo addresses are structured and some of the fields contained in
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 means 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
Krishnan & Hoagland Expires August 28, 2008 [Page 3]
Internet-Draft Teredo Security Updates February 2008
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 [TEREDOSEC].
3. Deprecate cone bit
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
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
scan the embedded external IPv4 address and others associated with
the same organization, looking for open ports. 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. The qualification procedure described in section 5.2.1 of
[RFC4380] will also be affected by this change.
4. Proposed changes
The Flags field defined in section 4 of [RFC4380] is redefined as
follows.
0 0 0 1
|0 7 8 5
+----+----+----+----+
|zzrr|rrUG|rrrr|rrrr|
+----+----+----+----+
Figure 1: Flags format
o The bits "UG" should be set to the value "00", indicating a non-
global unicast identifier.
Krishnan & Hoagland Expires August 28, 2008 [Page 4]
Internet-Draft Teredo Security Updates February 2008
o The bits marked"z" SHOULD be set to 0. This bit was earlier
defined as the Cone bit to indicate if the client was behind a
cone NAT.
o The bits marked with "r" SHOULD be chosen at random by the client.
Assuming there is no bias in those bit settings, then this adds 12
additional bits of entropy (4096 times as many addresses). This
makes it harder for an attacker to guess Teredo addresses.
5. Backward Compatibility
The Microsoft web site [MSTO] indicates that Windows Vista already
randomizes the bits as suggested in this document. Other
implementations need to be updated to perform this. All client
implementations need to be modified to always set the cone bit to 0,
in order to be compliant with this document. But in either case,
there are no functional interoperability issues and Teredo components
updated as suggested in this specification are fully compatible with
implementations that follow RFC 4380.
6. Acknowledgments
The authors would like to thank Remi Denis-Courmont, Dave Thaler,
Fred Templin, Jordi Palet Martinez, James Woodyatt and Christian
Huitema for reviewing earlier versions of the document and providing
comments to make this document better.
7. Security Considerations
This document describes some updates to RFC4380 in order to improve
the security of the base Teredo mechanism. Teredo is NOT RECOMMENDED
as a solution for managed networks. Administrators of such networks
may wish to filter all Teredo traffic at the boundaries of their
networks.
8. IANA Considerations
There are no IANA considerations resulting from this document.
9. References
Krishnan & Hoagland Expires August 28, 2008 [Page 5]
Internet-Draft Teredo Security Updates February 2008
9.1. Normative References
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
9.2. Informative References
[MSTO] Microsoft, "Teredo Overview", <http://www.microsoft.com/
technet/prodtechnol/winxppro/maintain/teredo.mspx>.
[TEREDOSEC]
Hoagland, J., "The Teredo Protocol: Tunneling Past Network
Security and Other Security Implications", November 2006,
<http://www.symantec.com/avcenter/reference/
Teredo_Security.pdf>.
[WVNASA] Hoagland, J., Conover, M., Newsham, T., and O. Whitehouse,
"Windows Vista Network Surface Analysis", March 2007,
<http://www.symantec.com/avcenter/reference/
Vista_Network_Attack_Surface_RTM.pdf>.
Authors' Addresses
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
James Hoagland
Symantec Corporation
350 Ellis St.
Mountain View, CA 94043
US
Email: Jim_Hoagland@symantec.com
URI: http://symantec.com/
Krishnan & Hoagland Expires August 28, 2008 [Page 6]
Internet-Draft Teredo Security Updates February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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 procedures with respect to rights in RFC 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Krishnan & Hoagland Expires August 28, 2008 [Page 7]
