From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5991.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc5991.txt (limited to 'doc/rfc/rfc5991.txt') diff --git a/doc/rfc/rfc5991.txt b/doc/rfc/rfc5991.txt new file mode 100644 index 0000000..1d1a946 --- /dev/null +++ b/doc/rfc/rfc5991.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Thaler +Request for Comments: 5991 Microsoft +Updates: 4380 S. Krishnan +Category: Standards Track Ericsson +ISSN: 2070-1721 J. Hoagland + Symantec + September 2010 + + + Teredo Security Updates + +Abstract + + The Teredo protocol defines a set of flags that are embedded in every + Teredo IPv6 address. This document specifies a set of security + updates that modify the use of this flags field, but are backward + compatible. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5991. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Thaler, et al. Standards Track [Page 1] + +RFC 5991 Teredo Security Updates September 2010 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Specification ...................................................4 + 3.1. Random Address Flags .......................................4 + 3.2. Deprecation of Cone Bit ....................................6 + 4. Security Considerations .........................................7 + 5. Acknowledgments .................................................7 + 6. References ......................................................8 + 6.1. Normative References .......................................8 + 6.2. Informative References .....................................8 + Appendix A. Implementation Status .................................9 + Appendix B. Resistance to Address Prediction ......................9 + +1. Introduction + + Teredo [RFC4380] defines a set of flags that are embedded in every + Teredo IPv6 address. This document specifies a set of security + updates that modify the use of this flags field, but are backwards + compatible. This document updates RFC 4380. + + The Flags field in a Teredo IPv6 address has 13 unused bits out of a + total of 16 bits. To guard against address-scanning risks [RFC5157] + from malicious users, this update randomizes 12 of the 13 unused bits + when configuring the Teredo IPv6 address. Even if an attacker were + able to determine the external (mapped) IPv4 address and port + assigned by a NAT to the Teredo client, the attacker would still need + to attack a range of 4,096 IPv6 addresses to determine the actual + Teredo IPv6 address of the client. + + The cone bit in a Teredo IPv6 address indicates whether a peer needs + to send Teredo control messages before communicating with a Teredo + IPv6 address. Unfortunately, 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, an attacker may decide it is + + + +Thaler, et al. Standards Track [Page 2] + +RFC 5991 Teredo Security Updates September 2010 + + + fruitful to port-scan the embedded external IPv4 address and others + associated with the same organization, looking for open ports. + Deprecating the cone bit prevents the a priori revelation of the + security posture of the NAT. + +2. Terminology + + This document uses the following terminology, for consistency with + [RFC4380]. + + Cone NAT: A NAT that maps all requests from the same internal IP + address and port to the same external IP address and port. + Furthermore, any external host can send a packet to the internal + host by sending a packet to the mapped external address and port. + + Indirect Bubble: A Teredo control message that is sent to another + Teredo client via the destination's Teredo server, as specified in + [RFC4380], Section 5.2.4. + + Local Address/Port: The IPv4 address and UDP port from which a Teredo + client sends Teredo packets. The local port is referred to as the + Teredo service port in [RFC4380]. The local address of a node may + or may not be globally routable because the node can be located + behind one or more NATs. + + Mapped Address/Port: A global IPv4 address and a UDP port that + results from the translation of a node's own local address/port by + one or more NATs. The node learns these values through the Teredo + protocol specified in [RFC4380]. The mapped address/port can be + different for every peer with which a node tries to communicate. + + Network Address Translation (NAT): The process of converting between + IP addresses used within an intranet or other private network and + Internet IP addresses. + + Peer: A Teredo client with which another Teredo client needs to + communicate. + + Port-Preserving NAT: A NAT that translates a local address/port to a + mapped address/port such that the mapped port has the same value + as the local port, as long as that same mapped address/port has + not already been used for a different local address/port. + + Public Address: An external global address used by a NAT. + + Restricted NAT: A NAT where all requests from the same internal IP + address and port are mapped to the same external IP address and + port. Unlike the cone NAT, an external host can send packets to + + + +Thaler, et al. Standards Track [Page 3] + +RFC 5991 Teredo Security Updates September 2010 + + + an internal host (by sending a packet to the external mapped + address and port) only if the internal host has first sent a + packet to the external host. + + Teredo Client: A node that implements the client parts of [RFC4380], + has access to the IPv4 Internet, and wants to gain access to the + IPv6 Internet. + + Teredo IPv6 Address: An IPv6 address that starts with the prefix + 2001:0000:/32 and is formed as specified in Section 4 of + [RFC4380]. + + Teredo Server: A node that has a globally routable address on the + IPv4 Internet, and is used as a helper to provide IPv6 + connectivity to Teredo clients. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +3. Specification + +3.1. Random Address Flags + + Teredo addresses are structured, and some of the fields contained in + them are fairly predictable. This makes the addresses themselves + easier to predict and opens up a vulnerability. + + 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 generally 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 [RFC4380] 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 + + + + + + + +Thaler, et al. Standards Track [Page 4] + +RFC 5991 Teredo Security Updates September 2010 + + + service port and the NAT port assignment behavior), and it + therefore 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, 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 allow 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 of 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 an IPv4 address, prior to trying to form a Teredo address for + that address and port. + + Hence, the Flags field specified in [RFC4380], Section 4 is updated + as follows: + + 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |C|z|Random1|U|G| Random2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + C: This flag is specified in [RFC4380], and its use is modified in + Section 3.2 below. + + z: This flag is reserved. It MUST be set to zero when the address is + constructed, as specified in [RFC4380]. + + Random1: MUST be set to a random value. + + U: This flag is specified in [RFC4380]. + + G: This flag is specified in [RFC4380]. + + Random2: MUST be set to a random value. + + + + +Thaler, et al. Standards Track [Page 5] + +RFC 5991 Teredo Security Updates September 2010 + + +3.2. Deprecation of Cone Bit + + The qualification procedure is specified in [RFC4380], Section 5.2.1, + and is modified as follows. Teredo clients SHOULD completely skip + the first phase of the qualification procedure and implement only the + second phase where it uses the Teredo link-local address with the + cone bit set to zero. Consequently, a distinction between cone and + restricted NATs can no longer be made. Teredo communication will + still succeed, but at the expense of forcing peers to skip case 4 of + the sending details specified in [RFC4380], Section 5.2.4. This will + result in the same number of indirect bubbles being sent as if the + other end were a peer behind a restricted NAT. Even though the peer + behind the cone NAT does not need these indirect bubbles, it replies + to these indirect bubbles just like it would to any other indirect + bubbles. Skipping case 4 is already allowed for reliability reasons + (as also specified in [RFC4380], Section 5.2.4), and hence this does + not break interoperability, but the result of skipping the first + phase of qualification is to force that behavior (which is less + efficient, but potentially more reliable) to be taken by peers. + + In addition, clients and relays SHOULD ignore the cone bit in the + address of a Teredo peer and treat it as if it were always clear, as + specified in [RFC4380], Section 5.2.4 (last paragraph). + + Teredo servers MUST NOT ignore the cone bit for the following + reasons. + + o The cone bit in the IPv6 source address of a Router Solicitation + (RS) from a client controls what IPv4 source address the server + should use when sending a Router Advertisement (RA). If this + behavior is not preserved, legacy clients will conclude that they + are behind a cone NAT even when they are not (because the client + WILL receive the RA where previously it would not, since a cone + bit set to 1 requires the server to respond from another IP + address). They will then set their cone bit and lose + connectivity. + + o When the Teredo server sends RAs (or bubbles if it's also a + relay), the cone bit in its own Teredo address is set, indicating + that it doesn't require bubbles to reach it. + + + + + + + + + + + +Thaler, et al. Standards Track [Page 6] + +RFC 5991 Teredo Security Updates September 2010 + + +4. Security Considerations + + The basic threat model for Teredo is described in detail in + [RFC4380], Section 7, but briefly, the goal is that a Teredo client + should be as secure as if a host were directly attached to an + untrusted Internet link. This document specifies updates to + [RFC4380] that improve the security of the base Teredo mechanism + regarding specific threats. + + IPv6 address scanning [RFC5157] by off-path attackers: The Teredo + IPv6 Address format defined in [RFC4380], Section 4 makes it + relatively easy for a malicious user to conduct an address-scan to + determine IPv6 addresses by guessing the external (mapped) IPv4 + address and port assigned to the Teredo client. The random address + bits guard against address-scanning risks by providing a range of + 4,096 IPv6 addresses per external IPv4 address/port. As a result, + even if a malicious user were able to determine the external (mapped) + IPv4 address and port assigned to the Teredo client, the malicious + user would still need to attack a range of 4,096 IPv6 addresses to + determine the actual Teredo IPv6 address of the client. Appendix B + compares the address prediction resistance of a Teredo address + following this specification to that of an address formed using + standard IPv6 stateless address autoconfiguration [RFC4862]. + + In order to prevent adversaries from easily guessing the values of + the random bits and hence the address, the Random1 and Random2 bits + in the Teredo Flags field MUST be constructed following the + recommendations for random number generation as specified in + [NIST-RANDOM] and [RFC4086]. + + Opening a hole in an enterprise firewall [TUNNEL-SEC]: Teredo is NOT + RECOMMENDED as a solution for networks that wish to implement strict + controls for what traffic passes to and from the Internet. + Administrators of such networks may wish to filter all Teredo traffic + at the boundaries of their networks. + +5. Acknowledgments + + The authors would like to thank Remi Denis-Courmont, Fred Templin, + Jordi Palet Martinez, James Woodyatt, Christian Huitema, Tom Yu, Jari + Arkko, David Black, Tim Polk, and Sean Turner for reviewing earlier + versions of this document and providing comments to make this + document better. The authors would also like to thank Alfred Hoenes + for a careful review of this document. + + + + + + + +Thaler, et al. Standards Track [Page 7] + +RFC 5991 Teredo Security Updates September 2010 + + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + February 2006. + +6.2. Informative References + + [NIST-RANDOM] "NIST SP 800-90, Recommendation for Random Number + Generation Using Deterministic Random Bit Generators", + March 2007, . + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, + RFC 4086, June 2005. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 + Stateless Address Autoconfiguration", RFC 4862, + September 2007. + + [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", + RFC 5157, March 2008. + + [TUNNEL-SEC] Hoagland, J., Krishnan, S., and D. Thaler, "Security + Concerns With IP Tunneling", Work in Progress, March + 2010. + + + + + + + + + + + + + + + + + + + +Thaler, et al. Standards Track [Page 8] + +RFC 5991 Teredo Security Updates September 2010 + + +Appendix A. Implementation Status + + Deprecation of the cone bit as specified in this document is + implemented in Windows Vista and Windows Server 2008. + + The random flags specified in this document are implemented in + Windows Vista SP1 and Windows Server 2008. + + All Windows implementations automatically disable Teredo if they + detect that they are on a managed network with a domain controller. + +Appendix B. Resistance to Address Prediction + + This section compares the address prediction resistance of a Teredo + address as compared to an address formed using IPv6 stateless address + autoconfiguration (SLAAC) [RFC4862]. + + Let's assume that the attacker knows a Teredo client's external IPv4 + address and Ethernet card's vendor. Since the attacker knows the + client's external IPv4 address, he does not have to search this + space. The attacker does not know the external port (16 bits) and + the value of the random bits (12 bits), and he has to search this + space. This gives the attacker a total search space of 28 bits + (16+12). This compares very favorably with the 24 bits of search + space required to find an address configured using SLAAC (when the + Ethernet card's vendor is known) as described in Section 2.3 of + [RFC5157]. Without the 12 random bits, the search space is limited + to only 16 bits, and this is significantly worse than the 24 bits of + search space provided by SLAAC. + + As the knowledge of the attacker decreases, the number of bits of + search space in both cases is likely to increase in a relatively + similar fashion. The predictability of Teredo addresses will stay + comparable to that of SLAAC addresses with the added 12 bits of + search space, but will be significantly worse without the random + bits. + + + + + + + + + + + + + + + +Thaler, et al. Standards Track [Page 9] + +RFC 5991 Teredo Security Updates September 2010 + + +Authors' Addresses + + Dave Thaler + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + + 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 + USA + + EMail: Jim_Hoagland@symantec.com + URI: http://symantec.com/ + + + + + + + + + + + + + + + + + + + + + +Thaler, et al. Standards Track [Page 10] + -- cgit v1.2.3