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", . [TEREDOSEC] Hoagland, J., "The Teredo Protocol: Tunneling Past Network Security and Other Security Implications", November 2006, . [WVNASA] Hoagland, J., Conover, M., Newsham, T., and O. Whitehouse, "Windows Vista Network Surface Analysis", March 2007, . 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]