idnits 2.17.1 draft-ietf-v6ops-tunnel-security-concerns-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (March 8, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-06 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 1 error (**), 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 J. Hoagland 3 Internet-Draft Symantec 4 Intended status: Informational S. Krishnan 5 Expires: September 9, 2010 Ericsson 6 D. Thaler 7 Microsoft 8 March 8, 2010 10 Security Concerns With IP Tunneling 11 draft-ietf-v6ops-tunnel-security-concerns-02 13 Abstract 15 A number of security concerns with IP tunnels are documented in this 16 memo. The intended audience of this document includes network 17 administrators and future protocol developers. The primary intent of 18 this document is to raise the awareness regarding the security issues 19 with IP tunnels as deployed today. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 9, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Tunnels May Bypass Security . . . . . . . . . . . . . . . . . 3 75 2.1. Network Security Bypass . . . . . . . . . . . . . . . . . 3 76 2.2. IP Ingress and Egress Filtering Bypass . . . . . . . . . . 5 77 2.3. Source Routing After the Tunnel Client . . . . . . . . . . 6 78 3. Challenges in Inspecting and Filtering Content of Tunneled 79 Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.1. Inefficiency of Selective Network Filtering of All 81 Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7 82 3.2. Problems with deep packet inspection of tunneled data 83 packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 4. Increased Exposure Due to Tunneling . . . . . . . . . . . . . 9 85 4.1. NAT Holes Increase Attack Surface . . . . . . . . . . . . 9 86 4.2. Exposure of a NAT Hole . . . . . . . . . . . . . . . . . . 11 87 4.3. Public Tunnels Widen Holes in Restricted NATs . . . . . . 12 88 5. Tunnel Address Concerns . . . . . . . . . . . . . . . . . . . 12 89 5.1. Feasibility of Guessing Tunnel Addresses . . . . . . . . . 12 90 5.2. Profiling Targets Based on Tunnel Address . . . . . . . . 13 91 6. Additional Security Concerns . . . . . . . . . . . . . . . . . 15 92 6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 15 93 7. Mechanisms to secure the use of tunnels . . . . . . . . . . . 17 94 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 97 11. Informative References . . . . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 With NAT devices becoming increasingly more prevalent, there have 103 recently been many tunneling protocols developed that go through NAT 104 devices or firewalls by tunneling over UDP or TCP. For example, 105 Teredo [RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel 106 IP packets over UDP. Similarly, many SSL VPN solutions that tunnel 107 IP packets over HTTP (and hence over TCP) are deployed today. 109 This document discusses security concerns with tunneling IP packets, 110 and includes recommendations where relevant. 112 The primary intent of this document is to provide information that 113 can be used in any new or updated tunnel protocol specification. 114 Secondarily, this document can help improve security deployments 115 using tunnel protocols. The intended audience of this document 116 includes network administrators and future protocol developers. 118 2. Tunnels May Bypass Security 120 2.1. Network Security Bypass 122 2.1.1. Problem 124 Tunneled IP traffic may not receive the intended level of inspection 125 or policy application by network-based security devices unless such 126 devices are specifically tunnel-aware. This reduces defense in depth 127 and may cause security gaps. This applies to all network-located 128 devices and to any end-host based firewalls whose existing hooking 129 mechanism(s) would not show them the IP packet stream after the 130 tunnel client does decapsulation. 132 2.1.2. Discussion 134 Evasion by tunneling is often a problem for network-based security 135 devices such as network firewalls, intrusion detection and prevention 136 systems, and router controls. To provide such functionality in the 137 presence of tunnels, the developer of such devices must add support 138 for detunneling for each new protocol. There is typically a 139 significant lag between when the security developer recognizes that a 140 tunnel will be used (or will be remotely usable) to a significant 141 degree and when the detunneling can be implemented in a product 142 update, the update tested and released, and customers begin using the 143 update. Late changes in the protocol specification or in the way it 144 is implemented can cause additional delays. This becomes a 145 significant security concern when a delay in applied coverage is 146 occurring frequently. 148 For example, for L2TP or Teredo, an unaware network security device 149 would inspect or regulate the outer IP and the IP-based UDP layer as 150 normal, but it would not recognize that there is an additional IP 151 layer contained inside the UDP payload that it needs to apply the 152 same controls as it would to a native packet. (Of course, if the 153 device discards the packet due to something in the IP or UDP header, 154 such as referring to an unknown protocol, the embedded packet is no 155 longer a concern.) In addition, if the tunnel does encryption, the 156 network-based security device may not be able to do much, just as if 157 IPsec end-to-end encryption were used without tunneling. 159 Network security controls being not applied must be a concern to 160 those that set them up, since those controls are supposed to 161 adequately regulate all traffic. If network controls are being 162 bypassed due to the use of tunneling, the burden of controls shifts 163 to the tunnel client host. Since security administrators may not 164 have full control over all the nodes on their network, they sometimes 165 prefer to implement security controls on the network. 167 One implication of the security control bypass is that defense in 168 depth has been reduced, perhaps down to zero unless a 'local 169 firewall' is in use as recommended in [RFC4380]. However, even if 170 there are host-based security controls that recognize tunnels, 171 security administrators may not have configured them with full 172 security control parity, even if all controls that were maintained by 173 the network are available on the host. Thus there may be gaps in 174 desired coverage. 176 Compounding this is that, unlike what would be the case for native 177 IP, some network administrators will not even be aware that their 178 hosts are globally reachable, if the tunnel provides connectivity to/ 179 from the Internet; for example, they may not be expecting this for 180 hosts with [RFC1918] addresses behind a NAT device. In addition, 181 Section 3.2 discusses how it may not be efficient to find all 182 tunneled traffic for network devices to examine. 184 2.1.3. Recommendations 186 Security administrators who do not consider tunneling an acceptable 187 risk should disable tunnel functionality either on the end-nodes 188 (hosts) or on the network nodes. However, there may be an awareness 189 gap. Thus, due to the possible negative security consequences, we 190 recommend that explicit user action be required to enable tunneling, 191 at least for the first time. 193 For example, when Teredo is being enabled or when it is going to be 194 used for the first time, there could be a descriptive warning about 195 the possible reduction of defense in depth that will occur. In 196 addition, Teredo client functionality should be easy to disable on 197 the host and through a central management facility if one is 198 provided. (We could find no pre-existing mechanism for tunneling 199 protocols to use that could automate their functionality being 200 disabled unless all network-based security controls were aware of it. 201 A separate type of consent request packet would be needed.) 203 To minimize security exposure due to tunnels, we recommend that a 204 tunnel be an interface of last resort, independent of IP version. 205 Specifically, we suggest that when both native and tunneled access to 206 a remote host is available, that the native access be used in 207 preference to tunneled access except when the tunnel endpoint is 208 known to not bypass security (e.g., an IPsec tunnel to a gateway 209 provided by the security administrator of the network). This should 210 also promote greater efficiency and reliability. 212 Note that although Rule 7 of [RFC3484] section 6 will prefer native 213 connectivity over tunnels, this rule is only a tie-breaker when a 214 choice is not made by earlier rules; hence tunneling mechanisms that 215 are tied to a particular range of IP address space will be decided 216 based on the prefix precedence. For example, using the prefix policy 217 mechanism of [RFC3484] section 2.1, Teredo might have a precedence of 218 5 so that native IPv4 is preferred over Teredo. 220 2.2. IP Ingress and Egress Filtering Bypass 222 2.2.1. Problem 224 IP addresses inside tunnels are not subject to ingress and egress 225 filtering in the network they tunnel over, unless extraordinary 226 measures are taken. Only the tunnel endpoints can do such filtering. 228 2.2.2. Discussion 230 Ingress filtering (sanity-checking incoming destination addresses) 231 and egress filtering (sanity-checking outgoing source addresses) are 232 done to mitigate attacks and to make it easier to identify the source 233 of a packet and are considered to be a good practice. This is most 234 naturally (and in the general case, by requirement) done at network 235 boundaries. Tunneled IP traffic bypassing this network control is a 236 specific case of Section 2.1, but is illustrative. 238 2.2.3. Recommendations 240 The recommendations in Section 2.1.3 can help here. For this problem 241 specifically, there are three locations in which ingress and egress 242 filtering can be done. 244 Network based: Network-based devices (e.g., routers) could be 245 updated to find all tunneled packets and to apply ingress and 246 egress controls equally to tunneled IP addresses. 248 Tunnel server based: Tunnel servers can apply ingress and egress 249 controls to tunneled IP addresses passing through them to and from 250 tunnel clients. 252 Host based: Tunnel clients could make an effort to conduct ingress 253 and egress filtering. 255 Implementations of protocols that embed an IPv4 address in a 256 tunneled IPv6 address directly between peers often do filtering 257 based on checking the correspondence. 259 Implementations of protocols that accept tunneled packets directly 260 from a server or relay do filtering the same way as it would be 261 done on a native link with traffic from a router. 263 Some protocols such as 6to4 [RFC3056], Teredo, ISATAP [RFC5214], 264 and 6over4 [RFC2529] allow both other hosts and a router over a 265 common tunnel. To perform host-based filtering with such 266 protocols a host would need to know the outer IP address of each 267 router from which it could receive traffic, so that packets from 268 hosts beyond the router will be accepted even though the source 269 address would not embed the router's IP address. Router addresses 270 might be learned via Secure Neighbor Discovery (SEND) [RFC3971] or 271 some other mechanism (e.g., [RFC5214] section 8.3.2). 273 2.3. Source Routing After the Tunnel Client 275 2.3.1. Problem 277 If the encapsulated IP packet specifies source routing beyond the 278 recipient tunnel client, the host may forward the IP packet to the 279 specified next hop. This may be unexpected and contrary to 280 administrator wishes and may have bypassed network-based source 281 routing controls. 283 2.3.2. Discussion 285 A detailed discussion of issues related to source routing can be 286 found in [RFC5095]. 288 2.3.3. Recommendations 290 Tunnel clients should by default discard tunneled IP packets that 291 specify additional routing, as recommended in [RFC5095], though they 292 may also allow the user to configure what source routing types are 293 allowed. All pre-existing source routing controls should be upgraded 294 to apply these controls to tunneled IP packets as well. 296 3. Challenges in Inspecting and Filtering Content of Tunneled Data 297 Packets 299 3.1. Inefficiency of Selective Network Filtering of All Tunneled 300 Packets 302 3.1.1. Problem 304 There is no mechanism to both efficiently and immediately filter all 305 tunneled packets. This limits the ability to prevent tunnel use on a 306 network. 308 3.1.2. Discussion 310 Given concerns about tunnel security or a network's lack of 311 preparedness for tunnels, a network administrator may wish to simply 312 block all use of tunnels that subvert security. He or she may wish 313 to do so using network controls; this could be either due to not 314 having confidence in the ability to disable it on all hosts attached 315 to the network or due to wanting an extra layer of prevention. 317 One simple method to do that is easy to employ for many tunnel 318 protocols is to block outbound packets to the UDP or TCP port used 319 (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for 320 L2TP, etc.). This prevents a tunnel client from establishing a new 321 tunnel. However, existing tunnels will not necessarily be affected 322 if the blocked port is used only for initial setup. In addition, if 323 the blocking is applied on the outside of the client's NAT device, 324 the NAT device will retain the port mapping for the client and the 325 client may or may not continue to use the IP address assigned to its 326 tunnel. In some cases, however, blocking all traffic to a given 327 outbound port (e.g., port 80) may interfere with non-tunneled traffic 328 so this should be used with caution. 330 Another simple alternative, if the tunnel server addresses are well- 331 known, is to filter out all traffic to/from such addresses. 333 The other approach is to find all packets to block in the same way as 334 would be done for inspecting all packets (Section 3.2). However, 335 this faces the difficulties in terms of efficiency of filtering as 336 was present there. 338 3.1.3. Recommendations 340 Tunneling over UDP or TCP (including HTTP) to reach the Internet is 341 not recommended as a solution for networks that wish to enforce 342 security polcies on the user traffic. (Windows, for example, 343 disables Teredo by default if it detects that it is within an 344 enterprise network that contains a Windows domain controller.) 346 Administrators of such networks may wish to filter all tunneled 347 traffic at the boundaries of their networks. It is sufficient to 348 filter out the tunneled connection requests (if they can be 349 identified) to stop further tunneled traffic. The easiest mechanism 350 for this would be to filter out outgoing traffic sent to the 351 destination port defined by the tunneling protocol, and incoming 352 traffic with that source port. 354 3.2. Problems with deep packet inspection of tunneled data packets 356 3.2.1. Problem 358 There is no efficient mechanism for network-based devices to inspect 359 the contents of all tunneled data packets, the way they can for 360 native packets. This makes it difficult to apply the same controls 361 as they do to native IP. 363 3.2.2. Discussion 365 Some tunnel protocols are easy to identify, such as if all data 366 packets are encapsulated using a well-known UDP or TCP port that is 367 unique to the protocol. 369 Other protocols, however, either use dynamic ports for data traffic, 370 or else share ports with other protocols (e.g., tunnels over HTTP). 372 The implication of this is that network-based devices that wish to 373 passively inspect (and perhaps selectively apply policy to) all 374 encapsulated traffic must inspect all TCP or UDP packets (or at least 375 all packets not part of a session that is known not to be a tunnel). 376 This is imperfect since a heuristic must then be applied to determine 377 if a packet is indeed part of a tunnel. This may be too slow to make 378 use of in practice, especially if it means that all TCP or UDP 379 packets must be taken off of the device's "fast path". 381 One heuristic that can be used on packets to determine if they are 382 tunnel-related or not is as follows. For each known tunnel protocol, 383 attempt parsing the packet as if it were a packet of that protocol, 384 destined to the local host (i.e., where the local host has the 385 destination address in the inner IP header, if any). If all syntax 386 checks pass, up to and including the inner IP header (if the tunnel 387 doesn't use encryption), then treat the packet as if it is a tunneled 388 packet of that protocol. 390 It is possible that non-tunnel packets will match as tunneled using 391 this heuristic, but tunneled packets (of the known types of tunnels) 392 should not escape inspection, absent implementation bugs. 394 For some protocols, it may be possible to monitor setup exchanges to 395 know to expect that data will be exchanged on certain ports later. 396 (Note that this does not necessarily apply to Teredo, for example, 397 since communicating with another Teredo client behind a cone NAT 398 device does not require such signaling. However, deprecation of the 399 cone bit as discussed in [RFC4380] means this technique may indeed 400 work with Teredo.) 402 3.2.3. Recommendations 404 As illustrated above, it should be clear that inspecting the contents 405 of tunneled data packets is highly complex and often impractical. 406 For this reason, if a network wishes to monitor IP traffic, tunneling 407 is not recommended. For example, to provide an IPv6 transition 408 solution, the network should provide native IPv6 connectivity or a 409 tunnel solution (e.g., ISATAP or 6over4) that encapsulates data 410 packets between hosts and a router within the network. 412 4. Increased Exposure Due to Tunneling 414 4.1. NAT Holes Increase Attack Surface 416 4.1.1. Problem 418 If the tunnel allows inbound access from the public Internet, the 419 opening created in a NAT device due to a tunnel client increases its 420 Internet attack surface area. If vulnerabilities are present, this 421 increased exposure can be used by attackers and their programs. 423 If the tunnel allows inbound access only from a private network 424 (e.g., a remote network to which one has VPN'ed), the opening created 425 in the NAT device still increases its attack surface area, although 426 not as much as in the public Internet case. 428 4.1.2. Discussion 430 When a tunnel is active, a mapped port is maintained on the NAT 431 device through which remote hosts can send packets and perhaps 432 establish connections. The following sequence is intended to sketch 433 out the processing on the tunnel client host that can be reached 434 through this; the actual processing for a given host may be somewhat 435 different. 437 1. Link-layer protocol processing 439 2. (Outer) IP host firewall processing 441 3. (Outer) IP processing by stack 443 4. UDP/TCP processing by stack 445 5. Tunnel client processing 447 6. (Inner) IP host firewall processing 449 7. (Inner) IP processing by stack 451 8. Various upper layer processing may follow 453 The inner firewall (and other security) processing may or may not be 454 present, but if it is, some of the inner IP processing may be 455 filtered. (For example, [RFC4380] section 7.1 recommends that an 456 IPv6 host firewall be used on all Teredo clients.) 458 (By the virtue of the tunnel being active, we can infer that the 459 firewall is unlikely to do any filtering based on the outer IP.) Any 460 of this processing may expose vulnerabilities an attacker can 461 exploit; similarly these may expose information to an attacker. 462 Thus, even if firewall filtering is in place (as is prudent) and 463 filters all incoming packets, the exposed area is larger than if a 464 native IP Internet connection were in place, due to the processing 465 that takes place before the inner IP is reached (specifically, the 466 UDP/TCP processing, the tunnel client processing, and additional IP 467 processing, especially if one is IPv4 and the other is IPv6). 469 One possibility is that a layer 3 targeted worm makes use of a 470 vulnerability in the exposed processing. While the main benefit to 471 worms from tunneling is targeting at layer 3 reaching the end host, 472 even a thoroughly firewalled host could be subject to a worm that 473 spreads with a single UDP packet if the right remote code 474 vulnerability is present. 476 4.1.3. Recommendations 478 This problem seems inherent in tunneling being active on a host, so 479 the solution seems to be to minimize tunneling use. 481 For example, it can be active only when it is really needed and only 482 for as long as needed. So, the tunnel interface can be initially not 483 configured and only used when it is entirely the last resort. The 484 interface should then be deactivated (ideally, automatically) again 485 as soon as possible. Note however that the hole will remain in the 486 NAT device for some amount of time after this, so some processing of 487 incoming packets is inevitable (unless the client's native IP address 488 behind the NAT device is changed). 490 4.2. Exposure of a NAT Hole 492 4.2.1. Problem 494 Attackers are more likely to know about a tunnel client's NAT hole 495 than a typical hole in the NAT device. If they know about the hole, 496 they could try to use it. 498 4.2.2. Discussion 500 There are at least three reasons why an attacker may be more likely 501 to learn of the tunnel client's exposed port than a typical NAT 502 exposed port: 504 1. The NAT mapping for a tunnel is typically held open for a 505 significant period of time, and kept stable. This increases the 506 chance of it being discovered. 508 2. In some protocols (e.g., Teredo), the external IP address and 509 port are contained in the client's address that is used end-to- 510 end and possibly even advertised in a name resolution system. 511 While the tunnel protocol itself might only distribute this 512 address in IP headers, peers, routers, and other on-path nodes 513 still see the client's IP address. Although this point does not 514 apply directly to protocols (e.g., L2TP) that do not construct 515 the inner IP address based on the outer IP address, the inner IP 516 address is still known to peers, routers, etc. and can still be 517 reached by attackers without knowing the external IP address or 518 port. 520 3. The tunnel protocol contains more messages that are exchanged and 521 with more parties (e.g., due to a longer path length) than 522 without using the tunnel, offering more chance for visibility 523 into the port and address in use. 525 4.2.3. Recommendations 527 The recommendations from Section 4.1 seem to apply here as well: 528 minimize tunnel use. 530 4.3. Public Tunnels Widen Holes in Restricted NATs 532 4.3.1. Problem 534 Tunnels that allow inbound connectivity from the Internet (e.g., 535 Teredo, tunnel brokers, etc) essentially turn a restricted or 536 symmetric NAT into an unrestricted one, for all tunnel client ports. 537 This eliminates NAT devices filtering for such ports and may 538 eliminate the need for an attacker to spoof an address. 540 4.3.2. Discussion 542 Restricted, port restricted, and symmetric NAT devices [RFC3489] 543 limit the source of incoming packets to just those that are a 544 previous destination. This poses a problem for tunnels that intend 545 to allow inbound connectivity from the Internet. 547 Various protocols (e.g., Teredo, STUN [RFC3489], etc.) provide a 548 facility for peers, upon request, to become a previous destination. 549 This works by sending a "bubble" packet via a server, which is passed 550 to the client, and then sent by the client (through the NAT) to the 551 originator. 553 This removes any NAT-based barrier to attackers sending packets in 554 through the client's service port. In particular, an attacker would 555 no longer need to either be an actual previous destination or to 556 forge its addresses as a previous destination. When forging, the 557 attacker would have had to learn of a previous destination and then 558 would face more challenges in seeing any returned traffic. 560 4.3.3. Recommendations 562 Minimizing public tunnel use (see Section 4.1.3) would lower the 563 attack opportunity related to this exposure. 565 5. Tunnel Address Concerns 567 5.1. Feasibility of Guessing Tunnel Addresses 568 5.1.1. Problem 570 For some types of tunneling protocols, it may be feasible to guess IP 571 addresses assigned to tunnels, either when looking for a specific 572 client or when looking for an arbitrary client. This is in contrast 573 to native IPv6 addresses in general, but is no worse than for native 574 IPv4 addresses today. 576 For example, some protocols (e.g., 6to4 and Teredo) use well-defined 577 address ranges. As another example, using well-known public servers 578 for Teredo or tunnel brokers also implies using a well known address 579 range. 581 5.2. Profiling Targets Based on Tunnel Address 583 5.2.1. Problem 585 An attacker encountering an address associated with a particular 586 tunneling protocol or well-known tunnel server has the opportunity to 587 infer certain relevant pieces of information that can be used to 588 profile the host before sending any packets. This can reduce the 589 attacker's footprint and increase the attacker's efficiency. 591 5.2.2. Discussion 593 The tunnel address reveals some information about the nature of the 594 client. 596 o That a host has a tunnel address associated with a given protocol 597 means that the client is running on some platform for which there 598 exists a tunnel client implementation of that protocol. In 599 addition, if some platforms have that protocol installed by 600 default and where the host's default rules for using it make it 601 susceptible to being in use, then it is more likely to be running 602 on such a platform than on one where it is not used by default. 603 For example, as of this writing, seeing a Teredo address suggests 604 that the host it is on is running Windows Vista. 606 o Similarly, the use of an address associated with a particular 607 tunnel server also suggests some information. Tunnel client 608 software is often deployed, installed, and/or configured using 609 some degree of automation. It seems likely that the majority of 610 the time the tunnel server that results from the initial 611 configuration will go unchanged from the initial setting. 612 Moreover, the server that is configured for use may be associated 613 with a particular means of installation, which often suggests the 614 platform. For example, if the server field in a Teredo address is 615 one of the IPv4 addressees to which teredo.ipv6.microsoft.com 616 resolves, it suggests that the host is running Windows. 618 o The external IPv4 address of a NAT device can of course be readily 619 associated with a particular organization or at least an ISP, and 620 hence putting this address in an IPv6 address reveals this 621 information. However, this is no different than using a native IP 622 address, and hence is not new with tunneling. 624 o It is also possible that external client port numbers may be more 625 often associated with particular client software or the platform 626 on which it is running. The usefulness of this for platform 627 determination is, however, reduced by the different NAT port 628 number assignment behaviors. In addition, the same observations 629 would apply to use of UDP or TCP over native IP as well, and hence 630 this is not new with tunneling. 632 The platform, tunnel client software, or organization information can 633 be used by an attacker to target attacks more carefully. For 634 example, an attacker may decide to attack an address only if it is 635 likely to be associated with a particular platform or tunnel client 636 software with a known vulnerability. (This is similar to the ability 637 to guess some platforms based on the OUI in the EUI-64 portion of an 638 IPv6 address generated from a MAC address, since some platforms are 639 commonly used with interface cards from particular vendors.) 641 In Teredo as defined in [RFC4380], the cone bit tells the attacker 642 whether a bubble is needed to proceed a connection. It may also have 643 some value in terms of profiling to the extent that it reveals the 644 security posture of the network. If the cone bit is set, the 645 attacker may decide it is fruitful to port scan the embedded external 646 IPv4 address and others associated with the same organization, 647 looking for open ports. As such, this cone bit is deprecated in 648 Windows Vista. 650 5.2.3. Recommendations 652 If installation programs randomized the server setting, that would 653 reduce the extent to which they can be profiled. Similarly, 654 administrators can choose to change the default setting to reduce the 655 degree to which they can be profiled ahead of time. 657 Randomizing the tunnel client port in use would mitigate any 658 profiling that can be done based on the external port, especially if 659 multiple different Teredo clients did this. Further discussion on 660 randomizing ports can be found at 661 [I-D.ietf-tsvwg-port-randomization]. 663 It is recommended that tunnel protocols minimize the propagation 664 knowledge about whether the NAT is a cone NAT. For example, the cone 665 bit for Teredo should be deprecated. 667 6. Additional Security Concerns 669 6.1. Attacks Facilitated By Changing Tunnel Server Setting 671 6.1.1. Problem 673 If an attacker could either change a tunnel client's server setting 674 or change the IP addresses to which a configured host name resolves 675 (e.g., by intercepting DNS queries), it would let them become a man 676 in the middle. This will allow them to at least monitor peer 677 communication and at worst pretend to represent the remote peer. 679 6.1.2. Discussion 681 A client's server has good visibility into the client's communication 682 with IP peers. If the server were switched to one that records this 683 information and makes it available to third parties (e.g., 684 advertisers, competitors, spouses, etc.) then sensitive information 685 is being disclosed, especially if the client's host prefers the 686 tunnel over native IP. Assuming the server provides good service, 687 the user would not have reason to suspect the change. 689 Full interception of IP traffic could also be arranged (including 690 pharming) which would allow any number of deception or monitoring 691 attacks including phishing. We illustrate this with an example 692 phishing attack scenario. 694 It is often assumed that the tunnel server is a trusted entity. It 695 may be possible for malware or a malicious user to quietly change the 696 Teredo client's server setting and have the user be unaware their 697 trust has been misplaced for an indefinite period of time. However, 698 malware or a malicious user can do much worse than this, so this is 699 not a significant concern. Hence it is only important that an 700 attacker on the network cannot change the client's server setting. 702 1. A phisher sets up a malicious tunnel server (or tampers with a 703 legitimate one). This server, for the most part, provides 704 correct service. 706 2. An attacker, by some means, switches the host's tunnel server 707 setting, or spoofs a DNS reply, to point to the above server. If 708 neither DNS nor the tunnel setup is secured (i.e., if the client 709 does not authenticate the information), then the attacker's 710 tunnel server is seen as legitimate. 712 3. A user on the victim host types their bank's URL into his/her 713 browser. 715 4. The bank's hostname resolves to one or more IP addresses and the 716 tunnel is selected for socket connection for whatever reason 717 (e.g., the tunnel provides IPv6 connectivity and the bank has an 718 IPv6 address). 720 5. The tunnel client uses the server for help in connecting to the 721 bank's IP address. Some tunneling protocols use a separate 722 channel for signaling vs data, but this still allows the server 723 to place itself in the data path by an appropriate signal to the 724 client. For example, in Teredo, the client sends a ping request 725 through a server which is expected to come back through a data 726 relay, and a malicious server can simply send it back itself to 727 indicate that is a data relay for the communication. 729 6. The rest works pretty much like any normal phishing transaction, 730 except that the attacker acts as a tunnel server (or data relay, 731 for protocols such as Teredo) and a host with the bank's IP 732 address. 734 This pharming type attack is not unique to tunneling. Switching DNS 735 server settings to a malicious DNS server or DNS cache poisoning in a 736 recursive DNS resolver could have a similar effect. 738 6.1.3. Recommendations 740 In general, anti-phishing and anti-fraud provisions should help with 741 aspects of this, as well as software that specifically monitors for 742 tunnel server changes. 744 Perhaps the best way to mitigate tunnel-specific attacks is to have 745 the client either authenticate the tunnel server, or at least the 746 means by which the tunnel server's IP address is determined. For 747 example, SSL VPNs use https URLs and hence authenticate the server as 748 being the expected one. Another mechanism, when IPv6 Router 749 Advertisements are sent over the tunnel (e.g., in Teredo), is to use 750 SEcure Neighbor Discovery (SEND) to verify that the client trusts the 751 server. 753 On the host, it should require an appropriate level of privilege in 754 order to change the tunnel server setting (as well as other non- 755 tunnel-specific settings such as the DNS server setting, etc.). 756 Making it easy to see the current tunnel server setting (e.g., not 757 requiring privilege for this) should help detection of changes. 759 The scope of the attack can also be reduced by limiting tunneling use 760 in general but especially in preferring native IPv4 to tunneled IPv6; 761 this is because it is reasonable to expect that banks and similar web 762 sites will continue to be accessible over IPv4 for as long as a 763 significant fraction of their customers are still IPv4-only. 765 7. Mechanisms to secure the use of tunnels 767 This document described several security issues with tunnels. This 768 does not mean that tunnels need to be avoided at any cost. On the 769 contrary, tunnels can be very useful if deployed, operated and used 770 properly. The threats against IP tunnels are documented here. If 771 the threats can be mitigated, network administrators can efficiently 772 and securely use tunnels in their network. Several measures can be 773 taken in order to secure the operation of IPv6 tunnels. 775 o Operating on-premise tunnel servers/relays so that the tunneled 776 traffic does not cross border routers. 778 o Setting up internal routing to steer traffic to these servers/ 779 relays 781 o Setting up of firewalls to allow known and controllable tunneling 782 mechanisms and disallow unknown tunnels. 784 8. Acknowledgments 786 The authors would like to thank Remi Denis-Courmont, Fred Templin, 787 Jordi Palet Martinez, James Woodyatt, Christian Huitema, Brian 788 Carpenter, Nathan Ward and Kurt Zeilenga for reviewing earlier 789 versions of the document and providing comments to make this document 790 better. The authors would also like to thank Alfred Hoenes for a 791 careful review of the document. 793 9. Security Considerations 795 This entire document discusses security concerns with tunnels. 797 10. IANA Considerations 799 There are no actions for IANA in this document. 801 11. Informative References 803 [I-D.ietf-tsvwg-port-randomization] 804 Larsen, M. and F. Gont, "Transport Protocol Port 805 Randomization Recommendations", 806 draft-ietf-tsvwg-port-randomization-06 (work in progress), 807 February 2010. 809 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 810 E. Lear, "Address Allocation for Private Internets", 811 BCP 5, RFC 1918, February 1996. 813 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 814 Domains without Explicit Tunnels", RFC 2529, March 1999. 816 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 817 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 818 RFC 2661, August 1999. 820 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 821 via IPv4 Clouds", RFC 3056, February 2001. 823 [RFC3484] Draves, R., "Default Address Selection for Internet 824 Protocol version 6 (IPv6)", RFC 3484, February 2003. 826 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 827 "STUN - Simple Traversal of User Datagram Protocol (UDP) 828 Through Network Address Translators (NATs)", RFC 3489, 829 March 2003. 831 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 832 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 834 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 835 Neighbor Discovery (SEND)", RFC 3971, March 2005. 837 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 838 Network Address Translations (NATs)", RFC 4380, 839 February 2006. 841 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 842 of Type 0 Routing Headers in IPv6", RFC 5095, 843 December 2007. 845 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 846 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 847 March 2008. 849 Authors' Addresses 851 James Hoagland 852 Symantec Corporation 853 350 Ellis St. 854 Mountain View, CA 94043 855 US 857 Email: Jim_Hoagland@symantec.com 858 URI: http://symantec.com/ 860 Suresh Krishnan 861 Ericsson 862 8400 Decarie Blvd. 863 Town of Mount Royal, QC 864 Canada 866 Phone: +1 514 345 7900 x42871 867 Email: suresh.krishnan@ericsson.com 869 Dave Thaler 870 Microsoft Corporation 871 One Microsoft Way 872 Redmond, WA 98052 873 USA 875 Phone: +1 425 703 8835 876 Email: dthaler@microsoft.com