idnits 2.17.1 draft-krishnan-v6ops-teredo-update-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4380, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC4380, updated by this document, for RFC5378 checks: 2003-06-09) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 3, 2010) is 5070 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-02 -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group D. Thaler 3 Internet-Draft Microsoft 4 Updates: 4380 (if approved) S. Krishnan 5 Intended status: Standards Track Ericsson 6 Expires: December 5, 2010 J. Hoagland 7 Symantec 8 June 3, 2010 10 Teredo Security Updates 11 draft-krishnan-v6ops-teredo-update-10 13 Abstract 15 The Teredo protocol defines a set of flags that are embedded in every 16 Teredo IPv6 address. This document specifies a set of security 17 updates that modify the use of this flags field, but are backward 18 compatible. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 5, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Random Address Flags . . . . . . . . . . . . . . . . . . . 6 70 3.2. Deprecation of Cone Bit . . . . . . . . . . . . . . . . . 7 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Appendix A. Implementation Status . . . . . . . . . . . . . . . . 13 78 Appendix B. Resistance to address prediction . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Teredo [RFC4380] defines a set of flags that are embedded in every 84 Teredo IPv6 address. This document specifies a set of security 85 updates that modify the use of this flags field, but are backwards 86 compatible. 88 The flags field in a Teredo IPv6 address has 13 unused bits out of a 89 total of 16 bits. To guard against address-scanning risks [RFC5157] 90 from malicious users, this update randomizes 12 of the 13 unused bits 91 when configuring the Teredo IPv6 address. Even if an attacker were 92 able to determine the external (mapped) IPv4 address and port 93 assigned by a NAT to the Teredo client, the attacker would still need 94 to attack a range of 4,096 IPv6 addresses to determine the actual 95 Teredo IPv6 address of the client. 97 The cone bit in a Teredo IPv6 address indicates whether a peer needs 98 to send Teredo control messages before communicating with a Teredo 99 IPv6 address. Unfortunately, it may also have some value in terms of 100 profiling to the extent that it reveals the security posture of the 101 network. If the cone bit is set, an attacker may decide it is 102 fruitful to port scan the embedded external IPv4 address and others 103 associated with the same organization, looking for open ports. 104 Deprecating the cone bit prevents the a priori revelation of the 105 security posture of the NAT. 107 2. Terminology 109 This document uses the following terminology, for consistency with 110 [RFC4380]. 112 Cone NAT: A NAT that maps all requests from the same internal IP 113 address and port to the same external IP address and port. 114 Furthermore, any external host can send a packet to the internal host 115 by sending a packet to the mapped external address and port. 117 Indirect Bubble: A Teredo control message that is sent to another 118 Teredo client via the destination's Teredo server, as specified in 119 [RFC4380] section 5.2.4. 121 Local Address/Port: The IPv4 address and UDP port from which a Teredo 122 client sends Teredo packets. The local port is referred to as the 123 Teredo service port in [RFC4380]. The local address of a node may or 124 may not be globally routable because the node can be located behind 125 one or more NATs. 127 Mapped Address/Port: A global IPv4 address and a UDP port that 128 results from the translation of a node's own local address/port by 129 one or more NATs. The node learns these values through the Teredo 130 protocol specified in [RFC4380]. the mapped address/port can be 131 different for every peer that a node tries to communicate with. 133 Network Address Translation (NAT): The process of converting between 134 IP addresses used within an intranet or other private network and 135 Internet IP addresses. 137 Peer: A Teredo client with which another Teredo Client needs to 138 communicate. 140 Port-Preserving NAT: A NAT that translates a local address/port to a 141 mapped address/port such that the mapped port has the same value as 142 the local port, as long as that same mapped address/port has not 143 already been used for a different local address/port. 145 Public Address: An external global address used by a NAT. 147 Restricted NAT: A NAT where all requests from the same internal IP 148 address and port are mapped to the same external IP address and port. 149 Unlike the cone NAT, an external host can send packets to an internal 150 host (by sending a packet to the external mapped address and port) 151 only if the internal host has first sent a packet to the external 152 host. 154 Teredo Client: A node that implements the client parts of [RFC4380], 155 has access to the IPv4 Internet and wants to gain access to the IPv6 156 Internet. 158 Teredo IPv6 Address: An IPv6 address that starts with the prefix 159 2001:0000:/32 and is formed as specified in Section 4 of [RFC4380]. 161 Teredo Server: A node that has a globally routable address on the 162 IPv4 Internet, and is used as a helper to provide IPv6 connectivity 163 to Teredo clients. 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 3. Specification 171 3.1. Random Address Flags 173 Teredo addresses are structured and some of the fields contained in 174 them are fairly predictable. This makes the addresses themselves 175 easier to predict and opens up a vulnerability. 177 Teredo prefix: This field is 32 bits and has a single IANA assigned 178 value 180 Server: This field is 32 bits and is set to the server in use. The 181 server to use is usually statically configured on the client. 182 This means that overall entropy of the server field will be low, 183 i.e., that the server will not be hard to predict. Attackers 184 could confine their guessing to the most popular server IP 185 addresses. 187 Flags: The flags field is 16 bits in length, but [RFC4380] provides 188 for only one of these bits (the cone bit) to vary. 190 Client port: This 16 bit field corresponds to the external port 191 number assigned to the client's Teredo service port. Thus the 192 value of this field depends on two factors (the chosen Teredo 193 service port and the NAT port assignment behavior) and therefore 194 it is harder to predict the entropy this field will have. If 195 clients tend to use a predictable port number and NATs are often 196 port-preserving, then the port number can be rather predictable. 198 Client IPv4 address: This 32 bit field corresponds to the external 199 IPv4 address the NAT has assigned for the client port. In 200 principle, this can be any address in the assigned part of the 201 IPv4 unicast address space. However, if an attacker is looking 202 for the address of a specific Teredo client, they will have to 203 have the external IPv4 address pretty well narrowed down. Certain 204 IPv4 address ranges could also become well known for having a 205 higher concentration of Teredo clients, making it easier to find 206 an arbitrary Teredo client. These addresses could correspond to 207 large organizations that allow Teredo such as a university or 208 enterprise or to Internet Service Providers that only provide 209 their customers with RFC 1918 addresses. 211 Optimizations in scanning can also reduce the number of addresses 212 that need to be checked. For example, for addresses behind a cone 213 NAT, it would likely be easy to probe if a specific port number is 214 open on an IPv4 address, prior to trying to form a Teredo address for 215 that address and port. 217 Hence the Flags field specified in [RFC4380] section 4 is updated as 218 follows: 220 1 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |C|z|Random1|U|G| Random2 | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 C: This flag is specified in [RFC4380] and its use is modified in 227 Section 3.2 below. 229 z: This flag is reserved. It MUST be set to zero when the address is 230 constructed, as specified in [RFC4380]. 232 Random1: MUST be set to a random value. 234 U: This flag is specified in [RFC4380]. 236 G: This flag is specified in [RFC4380]. 238 Random2: MUST be set to a random value. 240 3.2. Deprecation of Cone Bit 242 The qualification procedure is specified in [RFC4380] section 5.2.1, 243 and is modified as follows. Teredo clients SHOULD completely skip 244 the first phase of the qualification procedure and implement only the 245 second phase where it uses the Teredo link local address with the 246 cone bit set to zero. Consequently, a distinction between cone and 247 restricted NATs can no longer be made. Teredo communication will 248 still succeed, but at the expense of forcing peers to skip step 4 of 249 the sending details specified in [RFC4380]. This will result in the 250 same number of indirect bubbles being sent as if the other end were a 251 peer behind a restricted NAT. Even though the peer behind the cone 252 NAT does not need these indirect bubbles, it replies to these 253 indirect bubbles just like it would to any other indirect bubbles. 254 Skipping step 4 is already allowed for reliability reasons (as 255 specified in [RFC4380] section 5.2.4), and hence this does not break 256 interoperability, but the result of skipping the first phase of 257 qualification is to force that behavior (which is less efficient, but 258 potentially more reliable) to be taken by peers. 260 In addition, clients and relays SHOULD ignore the cone bit in the 261 address of a Teredo peer and treat it as if it were always clear, as 262 specified in [RFC4380] section 5.2.4 (last paragraph). 264 Teredo servers MUST NOT ignore the cone bit for the following 265 reasons. 267 o The cone bit in the IPv6 source address of a Router Solicitation 268 (RS) from a client controls what IPv4 source address the server 269 should use when sending a Router Advertisement (RA). If this 270 behavior is not preserved, legacy clients will conclude that they 271 are behind a cone NAT even when they are not (because the client 272 WILL receive the RA where previously it would not, since cone bit 273 set to 1 requires the server to respond from another IP address). 274 They will then set their cone bit and lose connectivity. 276 o When the Teredo server sends RAs (or bubbles if it's also a relay) 277 the cone bit in its own teredo address is set, indicating that it 278 doesn't require bubbles to reach it. 280 4. Security Considerations 282 The basic threat model for Teredo is described in detail in [RFC4380] 283 section 7, but briefly the goal is that a Teredo client should be as 284 secure as if a host were directly attached to an untrusted Internet 285 link. This document specifies updates to [RFC4380] that improve the 286 security of the base Teredo mechanism regarding specific threats. 288 IPv6 address scanning [RFC5157] by off-path attackers: The Teredo 289 IPv6 Address format defined in [RFC4380] section 4 makes it 290 relatively easy for a malicious user to conduct an address-scan to 291 determine IPv6 addresses by guessing the external (mapped) IPv4 292 address and port assigned to the Teredo client. The random address 293 bits guard against address-scanning risks by providing a range of 294 4096 IPv6 addresses per external IPv4 address/port. As a result, 295 even if a malicious user were able to determine the external (mapped) 296 IPv4 address and port assigned to the Teredo client, the malicious 297 user would still need to attack a range of 4,096 IPv6 addresses to 298 determine the actual Teredo IPv6 address of the client. Appendix B 299 compares the address prediction resistance of a Teredo address 300 following this specification to that of an address formed using 301 standard IPv6 Stateless Address Auto-configuration [RFC4862]. 303 In order to prevent adversaries from easily guessing the values of 304 the random bits and hence the address, the Random1 and Random2 bits 305 in the Teredo Flags field MUST be constructed following the 306 recommendations for Random number generation as specified in 307 [NIST-RANDOM] and [RFC4086]. 309 Opening a hole in an enterprise firewall 310 [I-D.ietf-v6ops-tunnel-security-concerns]: Teredo is NOT RECOMMENDED 311 as a solution for networks that wish to implement strict controls for 312 what traffic passes to and from the Internet. Administrators of such 313 networks may wish to filter all Teredo traffic at the boundaries of 314 their networks. 316 5. IANA Considerations 318 [RFC Editor: please remove this section prior to publication.] 320 This document has no IANA Actions. 322 6. Acknowledgments 324 The authors would like to thank Remi Denis-Courmont, Fred Templin, 325 Jordi Palet Martinez, James Woodyatt, Christian Huitema, Tom Yu, Jari 326 Arkko, David Black, Tim Polk and Sean Turner for reviewing earlier 327 versions of the document and providing comments to make this document 328 better. The authors would also like to thank Alfred Hoenes for a 329 careful review of the document. 331 7. References 333 7.1. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 339 Network Address Translations (NATs)", RFC 4380, 340 February 2006. 342 7.2. Informative References 344 [I-D.ietf-v6ops-tunnel-security-concerns] 345 Hoagland, J., Krishnan, S., and D. Thaler, "Security 346 Concerns With IP Tunneling", 347 draft-ietf-v6ops-tunnel-security-concerns-02 (work in 348 progress), March 2010. 350 [NIST-RANDOM] 351 "NIST SP 800-90, Recommendation for Random Number 352 Generation Using Deterministic Random Bit Generators", 353 March 2007, . 356 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 357 Requirements for Security", BCP 106, RFC 4086, June 2005. 359 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 360 Address Autoconfiguration", RFC 4862, September 2007. 362 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 363 RFC 5157, March 2008. 365 Appendix A. Implementation Status 367 Deprecation of the cone bit as specified in this document is 368 implemented in Windows Vista and Windows Server 2008. 370 The random flags specified in this document are implemented in 371 Windows Vista SP1 and Windows Server 2008. 373 All Windows implementations automatically disable Teredo if they 374 detect that they are on a managed network with a domain controller. 376 Appendix B. Resistance to address prediction 378 This section compares the address prediction resistance of a Teredo 379 address as compared to an address formed using IPv6 stateless address 380 auto-configuration (SLAAC) [RFC4862]. 382 Let's assume that the attacker knows Teredo Client's external IPv4 383 address and Ethernet card's vendor. Since the attacker knows the 384 Client's external IPv4 address he does not have to search this space. 385 The attacker does not know the external port (16 bits) and the value 386 of the random bits (12 bits) and he has to search this space. This 387 gives the attacker a total search space of 28 bits (16+12). This 388 compares very favorably with the 24 bits of search space required to 389 find an address configured using SLAAC (when the Ethernet card's 390 vendor is known) as described in Section 2.3 of [RFC5157]. Without 391 the 12 random bits the search space is limited to only 16 bits and 392 this is significantly worse than the 24 bits of search space provided 393 by SLAAC. 395 As the knowledge of the attacker decreases the number of bits of 396 search space in both the cases is likely to increase in a relatively 397 similar fashion. The predictability of Teredo addresses will stay 398 comparable to that of SLAAC addresses with the added 12 bits of 399 search space, but will be significantly worse without the random 400 bits. 402 Authors' Addresses 404 Dave Thaler 405 Microsoft Corporation 406 One Microsoft Way 407 Redmond, WA 98052 408 USA 410 Phone: +1 425 703 8835 411 Email: dthaler@microsoft.com 413 Suresh Krishnan 414 Ericsson 415 8400 Decarie Blvd. 416 Town of Mount Royal, QC 417 Canada 419 Phone: +1 514 345 7900 x42871 420 Email: suresh.krishnan@ericsson.com 422 James Hoagland 423 Symantec Corporation 424 350 Ellis St. 425 Mountain View, CA 94043 426 US 428 Email: Jim_Hoagland@symantec.com 429 URI: http://symantec.com/