idnits 2.17.1 draft-hoagland-v6ops-teredosecconcerns-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 969. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 325: '... Teredo is NOT RECOMMENDED as a solu...' RFC 2119 keyword, line 420: '... RECOMMENDED as a transition solutio...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2007) is 6131 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) == Missing Reference: 'RFC3947' is mentioned on line 824, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 4214 (Obsoleted by RFC 5214) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group J. Hoagland 3 Internet-Draft Symantec 4 Expires: January 9, 2008 S. Krishnan 5 Ericsson 6 July 8, 2007 8 Teredo Security Concerns Beyond What Is In RFC 4380 9 draft-hoagland-v6ops-teredosecconcerns-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 9, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Additional security concerns with Teredo are documented, beyond what 43 is in RFC 4380. This is based on an independent analysis of Teredo's 44 security implications. The primary intent of this document is to 45 provide information and recommendations to the IETF that can be used 46 in any updated Teredo specification. The second intended audience is 47 anyone that can help improve security in Teredo as deployed, so they 48 will be aware of these concerns. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Teredo Bypasses Security . . . . . . . . . . . . . . . . . . . 3 54 2.1. Teredo Bypasses Network Security . . . . . . . . . . . . . 3 55 2.2. IPv6 Ingress and Egress Filtering Bypass . . . . . . . . . 5 56 2.3. Source Routing After the Teredo Client . . . . . . . . . . 6 57 3. Challenges in Inspecting and Filtering Content of Teredo 58 Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1. Inefficiency of Selective Network Filtering of All 60 Teredo Packets . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2. Problems with deep packet inspection of Teredo data 62 packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4. Increased Exposure Due to Teredo . . . . . . . . . . . . . . . 10 64 4.1. Teredo NAT Holes Increase Attack Surface . . . . . . . . . 10 65 4.2. Unusually High Exposure of a NAT Hole . . . . . . . . . . 11 66 4.3. Teredo Bubble Facility Widens Hole in Restricted NAT . . . 12 67 5. Teredo Address Concerns . . . . . . . . . . . . . . . . . . . 13 68 5.1. Feasibility of Guessing Teredo Addresses . . . . . . . . . 13 69 5.2. Profiling Targets Based on Teredo Address . . . . . . . . 14 70 6. Additional Security Concerns . . . . . . . . . . . . . . . . . 16 71 6.1. Attacks Facilitated By Changing Teredo Server Setting . . 16 72 6.2. RFC 4380 Implies That Teredo Improves Security . . . . . . 18 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 79 Intellectual Property and Copyright Statements . . . . . . . . . . 21 81 1. Introduction 83 An independent analysis of Teredo's security implications was 84 conducted by Symantec[TTPTPNSOSI], based on the Teredo specification 85 ([RFC4380]). This analysis uncovered some security concerns 86 associated with Teredo which are not documented in the Teredo 87 specification. This document discloses these additional concerns and 88 includes any recommendations where relevant. This Internet Draft is 89 also influenced to an extent by an examination of the Teredo 90 implementation on Microsoft Windows Vista [WVNASA]. 92 The primary intent of this document is to provide information so that 93 can be used in any updated Teredo specification. Secondarily, this 94 document can help improve security in Teredo as deployed (including 95 those that implement Teredo, security providers, and network security 96 administrators) become aware of any valid security concerns. 98 2. Teredo Bypasses Security 100 2.1. Teredo Bypasses Network Security 102 2.1.1. Problem 104 IPv6 traffic tunneled with Teredo will not receive the intended level 105 of inspection or policy application by network-based security 106 devices, unless the devices are specifically Teredo aware and 107 capable. This reduces defense in depth and may cause security gaps. 108 This applies to all network-located devices and to end-host based 109 firewalls whose existing hooking mechanism(s) would not show them the 110 IP packet stream after the Teredo client does decapsulation. 112 2.1.2. Discussion 114 Evasion by tunneling is often a problem for network-based security 115 devices such as firewalls, intrusion detection and prevention 116 systems, and router controls. The vendor of such devices must add 117 support for detunneling for each new protocol. There is typically a 118 significant lag between when the vendor recognizes that a tunnel will 119 be used (or will be remotely usable) to a significant degree and when 120 the detunneling can be implemented in a product update, the update 121 tested and released, and the customer begins using the update. Late 122 changes in the protocol specification or in the way it is implemented 123 can cause additional delays. This becomes a significant security 124 concern when a delay in applied coverage is occurring frequently. 126 Specifically for Teredo, a Teredo-unaware network security device 127 would inspect or regulate the IPv4 and the IPv4-based UDP layer as 128 normal for IPv4, but it would not recognize that there is an 129 additional IP layer contained inside the UDP payload that it needs to 130 apply the same controls as it would to a native packet. (Of course, 131 if device discards the packet due to something in the IPv4 or UDP 132 header, such as referring to an unknown protocol, the Teredo packet 133 is no longer a concern.) Teredo also only recently reached RFC 134 status (February 2006), is widely applicable, requires no support 135 from the local or organizational network, and looks ready to be 136 widely used. Furthermore the tunnel created by the Teredo client is 137 open-ended and allows bidirectional traffic. 139 Network security controls being not applied must be a concern to 140 those that set them up, since those controls are supposed to 141 adequately regulate all traffic. If network controls are being 142 bypassed due to the use of IPv6 via Teredo, the burden of controls 143 shifts to the Teredo client host. Since security administrators may 144 not have full control over all the nodes on their network, they 145 sometimes prefer to implement security controls on the network. 147 One implication of the security control bypass is that defense in 148 depth has been reduced, perhaps down to zero unless a 'local 149 firewall' is in use, as recommended as a mitigation in RFC 4380. 150 However, even if there are host-based security controls that 151 recognize Teredo, security administrators may not have configured 152 them with full security control parity, even if all controls that 153 were maintained by the network are available on the host. Thus there 154 may be gaps in desired coverage. 156 Compounding this is that, unlike what would be the case for native 157 IPv6, some network administrators will not even be aware that their 158 hosts are globally addressable; for example, they may not be 159 expecting this for hosts with RFC-1918 [RFC1918] addresses behind a 160 NAT. In addition, Section 3.2 discusses how it may not be efficient 161 to find all Teredo traffic for network devices to examine. 163 2.1.3. Recommendations 165 Of course security administrators should disable Teredo functionality 166 unless their network-based security controls adequately recognize the 167 tunneled traffic (unless they consider it an acceptable risk). 168 However, there may be an awareness gap. Thus, due to the possible 169 negative security consequences, we recommend that explicit user 170 action be required to enable a Teredo client for the first time, at 171 least for the time being. When Teredo is being enabled or when it is 172 going to be used for the first time, perhaps there should be a 173 descriptive warning about the possible evasion that will occur. In 174 addition, Teredo client functionality should be easy to disable on 175 the host and through a central management facility if one is 176 provided. 178 RFC 4380 requires that Teredo be an IPv6 provider of last resort. To 179 minimize security exposure due to Teredo, we recommend that Teredo 180 also be an IP provider of last resort. Specifically, we suggest that 181 when both IPv4- and IPv6-based access to a remote host is available, 182 that the IPv4-based access be used in preference to IPv6 access that 183 needs to use Teredo. This should also promote greater efficiency and 184 reliability. 186 We specifically note that we could find no pre-existing mechanism for 187 Teredo to use that could automate its functionality being disabled 188 unless all network-based security controls were aware of it. A 189 separate type of consent request packet would be needed. (Such a 190 consent request service could have application beyond Teredo.) 192 2.2. IPv6 Ingress and Egress Filtering Bypass 194 2.2.1. Problem 196 IPv6 addresses inside Teredo tunnels are not subject ingress and 197 egress filtering, unless extraordinary measures are taken. 199 2.2.2. Discussion 201 Ingress filtering (sanity-checking incoming destination addresses) 202 and egress filtering (sanity-checking outgoing source addresses) are 203 done to mitigate attacks and to make it easier to identify the source 204 of a packet and are considered to be a good practice. This is most 205 naturally (and in the general case, by requirement) done at network 206 boundaries. Teredo-tunneled IPv6 traffic bypassing this network 207 control is a specific case of Section Section 2.1, but is 208 illustrative. 210 2.2.3. Recommendations 212 The recommendations in Section 2.1.3 can help here. For this problem 213 specifically, there are two locations in which ingress and egress 214 filtering could be restored. 216 Network based: network-based devices (e.g. routers) could be updated 217 to find all Teredo packets and to apply ingress and egress 218 controls equally to Teredo tunneled IPv6-addresses. 220 Teredo client based: Teredo clients could make an effort to conduct 221 ingress and egress filtering. However, there are at least two 222 problems inherent in attempting to do address filtering from this 223 vantage point: knowing the network addresses to filter (drop the 224 packets of) and knowing whether a peer is from the same network. 226 The network addresses to filter could be approximated from 227 enumerating the addresses on the network interface the Teredo 228 client is using; at least the /64 of global unicast addresses can 229 be assumed to be in use on the network. Router Solicitations 230 [RFC2461] could also be made. 232 Peers known to be local due to the Teredo local discovery 233 procedure can be excluded from filtering, but the scope of that 234 knowledge is limited to a broadcast domain, whereas ingress and 235 egress filtering generally applies to a larger scope. 237 2.3. Source Routing After the Teredo Client 239 2.3.1. Problem 241 If the encapsulated IPv6 packet specifies source routing beyond the 242 recipient Teredo client, the host may forward the IPv6 packet to the 243 specified next hop. This may be unexpected and contrary to 244 administrator wishes and may have bypassed network-based source 245 routing controls. 247 2.3.2. Discussion 249 IPv6 source routing, while provided for in RFC 2460 [RFC2460] and 250 required in some cases such as mobile IPv6, is often not needed or 251 desired in a given network. Thus it is often blocked, at least for 252 certain types of source routing. The danger is that source routing, 253 by providing a reflection point, violates assumptions made in network 254 security decisions. In addition there is often no compelling case 255 for why it would be needed. 257 Consider the case where a Teredo packet reaches a Teredo client (and 258 is accepted) and the encapsulated IPv6 packet contains a Routing 259 header. The Routing header indicates that this is not the intended 260 destination (just a hop in a source route). Unless the Teredo client 261 has source routing disabled, it would pass the IPv6 packet on to the 262 next hop. One way to use this for an attack is to have the next hop 263 be a node internal to the network the client is on. Another is to 264 pass the packet back outside, using the Teredo node as a reflection 265 point. 267 This behavior is not specific to Teredo packets; it works in the same 268 way for all IPv6 packets. However, with native IPv6 packets, a 269 gateway prohibition of source routed packets would have prevented the 270 packet from even reaching the internal host. With Teredo active, the 271 burden is placed upon the end hosts, at least those running Teredo. 273 Source routing post-Teredo may also be a surprising possibility 274 (packets on an end-to-end tunnel not stopping at the end) that might 275 not have been anticipated in network controls, especially given that 276 a NAT was traversed in the process. RFC 4380 made no mention of 277 source routing. 279 2.3.3. Recommendations 281 Teredo clients should by default discard tunneled IPv6 packets that 282 specify additional routing, though they may also allow the user to 283 configure what source routing types are allowed. All pre-existing 284 source routing controls should be upgraded to apply these controls to 285 Teredo tunneled IPv6 packets as well. 287 3. Challenges in Inspecting and Filtering Content of Teredo Data 288 Packets 290 3.1. Inefficiency of Selective Network Filtering of All Teredo Packets 292 3.1.1. Problem 294 There is no mechanism to both efficiently and immediately filter all 295 Teredo packets. This limits the ability to prevent Teredo use on a 296 network. 298 3.1.2. Discussion 300 Given concerns about Teredo security or a network's lack of 301 preparedness for Teredo, a network administrator may wish to simply 302 block all Teredo use. He or she may wish to do so using network 303 controls; this could be either due to not having confidence in the 304 ability to disable it on all hosts attached to the network or due to 305 wanting an extra layer of prevention. 307 One simple method to do that is easy to employ is to block outbound 308 packets to UDP port 3544. This prevents a Teredo client from 309 connecting to its server and completing qualification. Thus it can 310 be assured that a host trying to establish a new Teredo address will 311 be prevented from using Teredo tunneling. However, existing Teredo 312 clients will not be affected, at least not immediately. In addition, 313 if the blocking is applied on the outside of client's NAT, the NAT 314 will retain the port mapping for the client and the client may or may 315 not continue to use its Teredo address. It is not known if blocking 316 all outbound port 3544 will interfere with non-Teredo traffic. 318 The other approach is to find all packets to block in the same way as 319 would be done for inspecting all packets (Section 3.2). However, 320 this faces the difficulties in terms of efficient as was present 321 there. 323 3.1.3. Recommendations 325 Teredo is NOT RECOMMENDED as a solution for managed networks. 326 Administrators of such networks may wish to filter all Teredo traffic 327 at the boundaries of their networks. It is sufficient to filter out 328 the Teredo connection requests to stop further Teredo traffic. The 329 easiest mechanism for this would be to filter out incoming traffic 330 with source port 3544 and outgoing traffic with destination port 331 3544. 333 3.2. Problems with deep packet inspection of Teredo data packets 335 3.2.1. Problem 337 There is no efficient mechanism for network-based devices to inspect 338 the contents of Teredo data packets, the way they can for native IPv6 339 packets. This makes it difficult to apply the same controls as they 340 do to native IPv6. 342 3.2.2. Discussion 344 The only well known port that Teredo traffic uses is UDP 3544 and RFC 345 4380 only requires that to be used for the Teredo server service 346 port. The client and relay components can use any port they wish. 348 The implication of this is that network-based devices that wish to 349 passively inspect (and perhaps selectively apply policy to) all 350 encapsulated Teredo-based traffic must inspect all UDP packets (or at 351 least all UDP packets not part of session that is known not to be 352 Teredo). This is inefficient (more so that say 6to4), especially 353 considering that a heuristic must then be applied to determine if a 354 packet is indeed Teredo. This may be too slow to make use of in 355 practice, especially if it means that all UDP packets must be taken 356 off of the device's "fast path". 358 One heuristic that can be used on UDP packets to determine if they 359 are Teredo-related or not is as follows: 361 1. The packet is not Teredo if it is not UDP over IPv4. 363 2. Set T to the UDP payload offset. 365 3. Set E to the end of the packet plus one. 367 4. If E-T < 40 (the length of an IPv6 base header), the packet is 368 not Teredo. 370 5. If the octets starting with T are 0x0001 (an indication of 371 authentication data), T= T+13 plus the lengths of the client 372 identifier and the authentication value, assuming T is the start 373 of authentication data. 375 6. If E-T < 40, the packet is not Teredo. 377 7. If the octets starting with T are 0x0000 (an indication of 378 origin encapsulation), T= T+8. 380 8. If E-T < 40, the packet is not Teredo. 382 9. If the octets starting with T is 0x0000 or 0x0001, loop back to 383 step 5. 385 10. If the most significant nibble of the octet at T is not 6, the 386 packet is not Teredo. 388 11. Assuming T is the start of an IPv6 header, set L to value of the 389 payload length field, S to the start of the source address, and 390 D to the start of the destination address. 392 12. If E-T != L+40, the packet is not Teredo. 394 13. If neither S nor D start with 0x20010000 (the Teredo prefix), 395 the packet is not Teredo. 397 14. The packet is assumed to be Teredo, with the IPv6 header 398 starting at T. 400 This is similar to the packet reception checks in [RFC4380]. The 401 loop is present due to the possibility that some Teredo component 402 will accept a Teredo packet even if the authentication and origin 403 encapsulation are reversed or repeated and that either an attacker or 404 an evasive user will use that to evade inspection. It is possible 405 that non-Teredo packets will match as Teredo using this heuristic (in 406 which case additional heuristics can be added), but Teredo packets 407 should not escape inspection, absent implementation bugs. 409 It is not possible to monitor Teredo setup on specific ports to know 410 to expect that Teredo traffic will appear on certain ports later 411 since in some cases there are no Teredo setup packets (e.g., when a 412 Teredo client is sending a packet to another Teredo client that is 413 not behind a restricted NAT). 415 3.2.3. Recommendations 417 As illustrated above, it is very clear that inspecting the contents 418 of Teredo data packets is highly complex and impractical. For this 419 reason, if a network wishes to monitor IPv6 traffic, Teredo is NOT 420 RECOMMENDED as a transition solution. As an alternative, the network 421 may provide native IPv6 connectivity or a managed network solution 422 like ISATAP [RFC4214] 424 4. Increased Exposure Due to Teredo 426 4.1. Teredo NAT Holes Increase Attack Surface 428 4.1.1. Problem 430 The opening created in a NAT due to a Teredo client increases its 431 Internet attack surface area. If vulnerabilities are present, this 432 increased exposure can be used by attackers and their programs. 434 4.1.2. Discussion 436 When a Teredo client is active, a mapped port is maintained on the 437 NAT through which Internet hosts can send packets and perhaps 438 establish connections. The following sequence is intended to sketch 439 out the processing on the Teredo client host that can be reached 440 through this; the actual processing for a given host may be somewhat 441 different. 443 1. IPv4 host firewall processing 445 2. IPv4 processing by stack 447 3. UDP processing by stack 449 4. Teredo client processing 451 5. IPv6 host firewall processing 453 6. IPv6 processing by stack 455 7. various upper layer processing may follow 457 The firewall (and other security) processing may or may not be 458 present, but if it is, some of the IPv6 processing may be filtered. 459 (By the virtue of the Teredo client being active, we can infer that 460 the IPv4 firewall is unlikely to do any filtering for this.) Any of 461 this processing may expose vulnerabilities an attacker can exploit; 462 similarly these may expose information to an attacker. Thus, even if 463 firewall filtering is in place (as is prudent) and filters all 464 incoming packets, the exposed area is non-trivial. 466 The exposed area is even larger than if a native IPv6 Internet 467 connection was in place, due to the processing that takes place 468 before IPv6 is reached. It is also larger than for a native IPv4 469 connection due to the UDP, Teredo, and IPv6 processing. 471 One possibility is that a layer 3 targeted worm makes use of a 472 vulnerability in the exposed processing. While the main benefit to 473 worms from Teredo is targeting at layer 3 reaching the end host, even 474 a throughly firewalled host could be subject to a worm that spreads 475 with a single UDP packet if the right remote code vulnerability is 476 present; such worms can spread quickly as evidenced by Slammer. 478 4.1.3. Recommendations 480 This problem seems inherent in Teredo being active on a host, so the 481 solution seems to be to minimize Teredo use. 483 For example, it can be active only when it is really needed and only 484 for as long as needed. So, the Teredo interface can be initially not 485 configured and only used when it is entirely the last resort. The 486 interface should then be deactivated again as soon as possible. Note 487 however that the hole will remain in the NAT for some amount of time 488 after this, so some processing of incoming packets is inevitable 489 (unless the client's IPv4 address is changed). 491 4.2. Unusually High Exposure of a NAT Hole 493 4.2.1. Problem 495 Attackers are more likely to know about a Teredo client's NAT hole 496 than a typical hole in the NAT. If they know about the hole, they 497 could try to use it. 499 4.2.2. Discussion 501 There are at least three reasons whey an attacker is more likely to 502 learn of the Teredo client's exposed port than a typical NAT exposed 503 port: 505 1. The NAT mapping is typically held open longer and kept more 506 stable than would otherwise be the case. This increases the 507 chance of it being discovered. 509 2. The external IP address and port is contained in the client's 510 Teredo address. While the Teredo protocol itself only 511 distributes this address on packets, peers and even network 512 components such as Teredo relays may record the Teredo address 513 in, for example, log files; the address may even make its way 514 onto, for example, peer-to-peer host advertisements. 516 3. The Teredo protocol contains more messages that are exchanged and 517 with more parties than is typical, offering more chance for 518 visibility into the port and address in use. All Teredo protocol 519 packets contain the client's external address and port. 521 4.2.3. Recommendations 523 The recommendations from Section 4.1 seem to apply here as well: 524 minimize Teredo use. 526 4.3. Teredo Bubble Facility Widens Hole in Restricted NAT 528 4.3.1. Problem 530 The bubble facility offered by clients and their servers to relays 531 essentially turns a restricted NAT into an unrestricted one, for all 532 Teredo client service ports. This eliminates NAT filtering for such 533 ports and may eliminate the need for an attacker to spoof an address. 535 4.3.2. Discussion 537 Restricted NATs and port restricted NATs [RFC3489] limit the source 538 of incoming packets to just those that are a previous destination. 539 This poses a problem for Teredo, so [RFC4380] provides a facility for 540 relays, upon request, to become a previous destination. This works 541 by a "bubble" packet sent to the server, passed to the client, and 542 then sent by the client (through the NAT) to the originator. 543 However, any host on the Internet can use this facility, not just 544 relays, since any host can serve as a host-only relay. 546 This removes any NAT-based barrier to attackers sending packets in 547 through the client's service port. In particular, an attacker would 548 no longer need to either be an actual previous destination or to 549 forge its addresses as a previous destination. When forging, the 550 attacker would have had to learn of a previous destination and then 551 would face more challenges in seeing any returned traffic. 553 There may be equivalent functionality in other protocols to provide 554 this service. 556 4.3.3. Recommendations 558 This facility is necessary for Teredo to operate, at least in its 559 current form. Minimizing Teredo use (see Section 4.1.3) would lower 560 the attacker opportunity related to this exposure. 562 5. Teredo Address Concerns 564 5.1. Feasibility of Guessing Teredo Addresses 566 5.1.1. Problem 568 It may be feasible guess Teredo addresses, either when looking for a 569 specific Teredo client or when looking for an arbitrary Teredo 570 client. This is in contrast to native IPv6 address in general. 572 5.1.2. Discussion 574 Teredo addresses are structured and some of the fields contained them 575 are fairly predictable. This can be used to better predict the 576 address. 578 Teredo prefix: This field is 32 bits and has a single IANA assigned 579 value 581 Server: This field is 32 bits and is set to the server in use. The 582 server to use is usually statically configured on the client; this 583 may resolve to one or a small number of IPv4 addresses for the 584 server. Certain static configurations can be reasonably expected 585 to be common (e.g., those that are the default with a Teredo 586 client implementation). This suggests that overall entropy of the 587 server field will be low, i.e., that the server will not be hard 588 to predict. Attackers could confine their guessing to the most 589 popular server IP addresses. 591 Flags: The flags field is 16 bits in length, but RFC 4380 provides 592 for only one of these bits (the cone bit) to vary. 594 Client port: This 16 bit field corresponds to the external port 595 number assigned to the client's Teredo service port. Thus the 596 value of this field depends on two factors (the chosen Teredo 597 service port and the NAT port assignment behavior) and therefore 598 it is harder to predict the entropy this field will have. If 599 clients tend to use a predictable port number and NATs are often 600 port-preserving ([RFC4787]), then the port number can be rather 601 predictable. 603 Client IPv4 address: This 32 bit field corresponds to the external 604 IPv4 address the NAT has assigned for the client port. In 605 principle, this can be any address in the assigned part of the 606 IPv4 unicast address space. However, if an attacker is looking 607 for the address of a specific Teredo client, they will have to 608 have the external IPv4 address pretty well narrowed down. Certain 609 IPv4 address ranges could also become well known for having a 610 higher concentration of Teredo clients, making it easier to find 611 an arbitrary Teredo client. These addresses could correspond to 612 large organizations that allows Teredo such as a university or 613 enterprise or to Internet Service Providers that only provide 614 their customers with RFC 1918 addresses. 616 Optimizations in scanning can also reduce the number addresses that 617 need to be checked. For example, for addresses behind a cone NAT, it 618 would likely be easy to probe if a specific port number is open on a 619 IPv4 address, prior to trying to form a Teredo address for that 620 address and port. 622 Most of this is elaborated on more in [TTPTPNSOSI]. 624 5.1.3. Recommendations 626 The Microsoft web site [MSTO] indicates that Windows Vista and 627 Longhorn make additional use of the flags field, beyond what the RFC 628 specifies. 12 bits (the "A" bits in "CRAAAAUG AAAAAAAA") are chosen 629 at random by the client at the end of qualification. Assuming there 630 is no bias in those bit settings, then this adds 12 additional bits 631 of entropy (4096 times as many addresses). We recommend this be 632 formally added to the next version of the Teredo specification. 634 The other thing we can recommend is that the client chose the Teredo 635 service port in as random manner as feasible, in case the NAT port 636 assignment behavior is based on the internal port number. 638 5.2. Profiling Targets Based on Teredo Address 640 5.2.1. Problem 642 An attacker encountering a Teredo address has the opportunity to 643 infer certain relevant pieces of information that can be used to 644 profile the host before sending any packets. This can reduce the 645 attacker's footprint and increase the attacker's efficiency. 647 5.2.2. Discussion 649 The Teredo address reveals some information about the nature of the 650 client. The information is reasonably reliable, even if some of it 651 is not tied to the Teredo protocol specification. 653 o That a host has a Teredo address at all means that there is a 654 Teredo client implementation available for that platform. It 655 probably also means that it was installed by default and also that 656 the hosts default rules for using it made it susceptible to being 657 in use. For example, as of this writing, seeing a Teredo address 658 strongly suggests that the host it is on is running Windows Vista. 660 o The server field in the Teredo address also suggests some 661 information. Teredo client software most often get to the end 662 user, installed, and configured using some degree of automation. 663 It seems likely that the majority of the time the Teredo server 664 that results from the initial configuration will go unchanged from 665 the initial setting. Moreover, the server that is configured for 666 use may be associated with particular means of installation, which 667 often suggests the platform. For example, if the server field in 668 the Teredo address is one of the IPv4 addressees that 669 teredo.ipv6.microsoft.com resolves to, that suggests that the host 670 is running Windows. 672 o The external IPv4 address in a Teredo address can of course be 673 readily associated with a particular organization or at least an 674 ISP. 676 o It is also possible that external client port numbers may be more 677 often associated with particular client software or the operating 678 system it is running on. The usefulness of this is reduced by the 679 different NAT port number assignment behaviors, though the net 680 result of this composition can not be determined without study. 682 The platform, Teredo client software, or organization information can 683 be used by an attacker to target attacks more carefully. For 684 example, an attacker may decide to use an address if it corresponds 685 to an organization they want to penetrate. (That example would not 686 be unique to Teredo addresses, but shows that Teredo reveals the same 687 information.) An attacker or worm might also decide to use a Teredo 688 address only if it looks to be associated with Windows or a certain 689 version of Windows. (This does not seem to have a strong analogue in 690 native IPv4 or IPv6 addresses.) 692 The cone bit tells the attacker whether a bubble is needed to proceed 693 a connection. It may also have some value in terms of profiling to 694 the extent that it reveals the security posture of the network. If 695 the cone bit is set, the attacker may decide it is fruitful to port 696 scan the embedded external IPv4 address and others associated with 697 the same organization, looking for open ports. 699 5.2.3. Recommendations 701 Deprecating the cone bit would prevent the a priori revelation of the 702 security posture of the NAT and would not reduce the functionality of 703 the Teredo protocol. 705 If installation programs randomized the server setting, that would 706 reduce the extent to which they can be profiled. Similarly, 707 administrators can chose to change the default setting to reduce the 708 degree to which they can be profiled ahead of time. 710 Randomizing the Teredo client port in use would mitigate any 711 profiling that can be done based on the external port, especially if 712 multiple different Teredo clients did this. 714 6. Additional Security Concerns 716 6.1. Attacks Facilitated By Changing Teredo Server Setting 718 6.1.1. Problem 720 Malware or a malicious user could change a Teredo client's server 721 setting. This would allow them to at least monitor peer IPv6 722 addresses and at worst pretend to represent the remote peer. 724 6.1.2. Discussion 726 [RFC4380] documents that the Teredo server must be a trusted entity. 727 However, it may be possible for malware or a malicious user to 728 quietly change the Teredo client's server setting and have the user 729 be unaware their trust has been misplaced for an indefinite period of 730 time. 732 A client's server is involved in the Direct IPv6 Connectivity Test 733 and in the bubble procedure, so it has good visibility into the 734 client's IPv6 peers. If the server were switched to one that records 735 this information and makes it available to third parties (e.g., 736 advertisers, competitors, spouses, etc.) then sensitive information 737 is being disclosed, especially if the client's host prefers Teredo 738 over native IPv4. This is not technically difficult to set up, 739 especially given the availability of open source Teredo server 740 implementations. Assuming the server provides good service, the user 741 would not have reason to suspect the change. 743 Full interception of IPv6 traffic could also be arranged (including 744 pharming) which would allow any number of deception or monitoring 745 attacks including phishing. We illustrate this with an example 746 phishing attack scenario. 748 1. A phisher stands up a malicious Teredo server (or tampers with a 749 legitimate one). This server, for the most part, provides 750 correct service. 752 2. Some malware reaches a victim host by some means and switches the 753 host's Teredo server setting to reference the above server 754 (either by IPv4 address or by hostname). 756 3. A user on the victim host types their bank's URL into his/her 757 browser. 759 4. The bank's hostname resolves to both IPv6 and IPv4 addresses and 760 the IPv6 address is selected for the socket connection. 761 (Alternately, it just resolves to IPv6.) 763 5. The host is behind an IPv4 NAT so no native IPv6 or ISTAP 764 connection is possible, so the Teredo interface is used. 766 6. The Teredo client uses the server for help in connecting to the 767 the bank's IPv6 address. It asks the server to pass along an 768 IPv6 ping so it can determine what Teredo relay to use in sending 769 packets to the bank's IPv6 address and so it knows what relay to 770 trust packets from for the peer. 772 7. The malicious server recognizes the IPv6 address as belonging to 773 a bank that it wants to phish against, so it sends an 774 encapsulated ping reply to the client. This is made to look like 775 a legitimate reply sent via a Teredo relay; however the relay it 776 is supposedly returned from is actually a phishing site. This 777 site could even be on the same host as the malicious Teredo 778 server. 780 8. The rest works pretty much like any normal phishing transaction, 781 except that the phishing host acts as local Teredo relay, since 782 the victim host thinks it is communicating via a Teredo relay 783 with the bank's IPv6 address. 785 This pharming type attack is not entirely novel, switching DNS server 786 settings to a malicious DNS server could have similar effect. 788 6.1.3. Recommendations 790 The scope of the attack can be reduced by limiting Teredo use in 791 general but especially in preferring native IPv4 to Teredo-tunneled 792 IPv6; this is because it is reasonable to expect that banks and 793 similar web sites will continue to be accessible over IPv4 for as 794 long as a significant fraction of their customers are still behind 795 IPv4 NATs. 797 In general, anti-phishing and anti-fraud provisions should help with 798 aspects of this, as well as software that specifically monitors for 799 Teredo server changes. 801 On the host, it should require an appropriate level of privilege in 802 order to change the Teredo server setting and we recommend that the 803 user be prompted when the Teredo server setting has been changed. 804 Making it easy to see the current Teredo server setting (e.g., not 805 requiring privilege for this) should help detection of changes. 807 6.2. RFC 4380 Implies That Teredo Improves Security 809 6.2.1. Problem 811 The Security Considerations section of RFC 4380 states that it can 812 argued that Teredo improves security. The above sections argue to 813 the contrary. This misleading or inaccurate claim can be taken out 814 of context and used to downplay Teredo security implications. 816 6.2.2. Discussion 818 The "Security Considerations" section of [RFC4380] begins with: 820 "The main objective of Teredo is to provide nodes located behind a 821 NAT with a globally routable IPv6 address. The Teredo nodes can 822 use IP security (IPsec) services ... without the configuration 823 restrictions still present in 'Negotiation of NAT-Traversal in the 824 IKE' [RFC3947]. As such, we can argue that the service has a 825 positive effect on network security. However, the security 826 analysis must also envisage the negative effects of the Teredo 827 services..." 829 We agree that Teredo improves the ability to use IPsec in traversing 830 a NAT and the security properties that it provides are a benefit in 831 certain cases, specifically when the alternate session directly 832 involves NAT translation, IPsec is desired to be used, and 833 circumstances allow IPsec to be used. In this case the nice security 834 properties IPsec can provide have been allowed by Teredo. However, 835 IPsec does not solve all security problems. 837 It is hoped that by this point the reader will agree that Teredo 838 introduces security risk and does not improve security overall. 839 Hence we feel the sentence that "the service has a positive effect on 840 network security" goes to far in stating its point, even considering 841 the following sentence which may somewhat reduce the pointedness of 842 the claim. Someone may not recognize the full security impact of 843 Teredo after reading the sentence. 845 6.2.3. Recommendations 847 We recommend that no claims regarding a positive security impact from 848 Teredo be made, unless the scope of such a claim is immediately 849 clear. We also recommend that the security concerns identified in 850 this document be included in an updated Teredo standard document, 851 except to the extent that the Teredo protocol has been improved to 852 mitigate them. 854 7. Security Considerations 856 This document identified security concerns with Teredo that were not 857 included in RFC 4380. 859 8. IANA Considerations 861 There are no IANA considerations from this document. 863 9. References 865 9.1. Normative References 867 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 868 E. Lear, "Address Allocation for Private Internets", 869 BCP 5, RFC 1918, February 1996. 871 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 872 (IPv6) Specification", RFC 2460, December 1998. 874 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 875 Discovery for IP Version 6 (IPv6)", RFC 2461, 876 December 1998. 878 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 879 "STUN - Simple Traversal of User Datagram Protocol (UDP) 880 Through Network Address Translators (NATs)", RFC 3489, 881 March 2003. 883 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 884 "Intra-Site Automatic Tunnel Addressing Protocol 885 (ISATAP)", RFC 4214, October 2005. 887 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 888 Network Address Translations (NATs)", RFC 4380, 889 February 2006. 891 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 892 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 893 RFC 4787, January 2007. 895 9.2. Informative References 897 [MSTO] Microsoft, "Teredo Overview", . 900 [TTPTPNSOSI] 901 Hoagland, J., "The Teredo Protocol: Tunneling Past Network 902 Security and Other Security Implications", November 2006, 903 . 906 [WVNASA] Hoagland, J., Conover, M., Newsham, T., and O. Whitehouse, 907 "Windows Vista Network Surface Analysis", March 2007, 908 . 911 Authors' Addresses 913 James Hoagland 914 Symantec Corporation 915 350 Ellis St. 916 Mountain View, CA 94043 917 US 919 Email: Jim_Hoagland@symantec.com 920 URI: http://symantec.com/ 922 Suresh Krishnan 923 Ericsson 924 8400 Decarie Blvd. 925 Town of Mount Royal, QC 926 Canada 928 Phone: +1 514 345 7900 x42871 929 Email: suresh.krishnan@ericsson.com 931 Full Copyright Statement 933 Copyright (C) The IETF Trust (2007). 935 This document is subject to the rights, licenses and restrictions 936 contained in BCP 78, and except as set forth therein, the authors 937 retain all their rights. 939 This document and the information contained herein are provided on an 940 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 941 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 942 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 943 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 944 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 945 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 947 Intellectual Property 949 The IETF takes no position regarding the validity or scope of any 950 Intellectual Property Rights or other rights that might be claimed to 951 pertain to the implementation or use of the technology described in 952 this document or the extent to which any license under such rights 953 might or might not be available; nor does it represent that it has 954 made any independent effort to identify any such rights. Information 955 on the procedures with respect to rights in RFC documents can be 956 found in BCP 78 and BCP 79. 958 Copies of IPR disclosures made to the IETF Secretariat and any 959 assurances of licenses to be made available, or the result of an 960 attempt made to obtain a general license or permission for the use of 961 such proprietary rights by implementers or users of this 962 specification can be obtained from the IETF on-line IPR repository at 963 http://www.ietf.org/ipr. 965 The IETF invites any interested party to bring to its attention any 966 copyrights, patents or patent applications, or other proprietary 967 rights that may cover technology that may be required to implement 968 this standard. Please address the information to the IETF at 969 ietf-ipr@ietf.org. 971 Acknowledgment 973 Funding for the RFC Editor function is provided by the IETF 974 Administrative Support Activity (IASA).