idnits 2.17.1 draft-ietf-v6ops-tunnel-security-concerns-04.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 : ---------------------------------------------------------------------------- == 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 (October 25, 2010) is 4904 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1918' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'RFC2529' is defined on line 792, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-07) exists of draft-ietf-opsec-ip-security-03 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-tunnel-loops-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Informational D. Thaler 5 Expires: April 28, 2011 Microsoft 6 J. Hoagland 7 Symantec 8 October 25, 2010 10 Security Concerns With IP Tunneling 11 draft-ietf-v6ops-tunnel-security-concerns-04 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 level regarding the security 19 issues with IP tunnels as deployed today. 21 Status of this Memo 23 This Internet-Draft is submitted 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). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 28, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Tunnels May Bypass Security . . . . . . . . . . . . . . . . . 3 69 2.1. Network Security Bypass . . . . . . . . . . . . . . . . . 3 70 2.2. IP Ingress and Egress Filtering Bypass . . . . . . . . . . 5 71 2.3. Source Routing After the Tunnel Client . . . . . . . . . . 6 72 3. Challenges in Inspecting and Filtering Content of Tunneled 73 Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1. Inefficiency of Selective Network Filtering of All 75 Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7 76 3.2. Problems with deep packet inspection of tunneled data 77 packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4. Increased Exposure Due to Tunneling . . . . . . . . . . . . . 9 79 4.1. NAT Holes Increase Attack Surface . . . . . . . . . . . . 9 80 4.2. Exposure of a NAT Hole . . . . . . . . . . . . . . . . . . 11 81 4.3. Public Tunnels Widen Holes in Restricted NATs . . . . . . 12 82 5. Tunnel Address Concerns . . . . . . . . . . . . . . . . . . . 12 83 5.1. Feasibility of Guessing Tunnel Addresses . . . . . . . . . 12 84 5.2. Profiling Targets Based on Tunnel Address . . . . . . . . 13 85 6. Additional Security Concerns . . . . . . . . . . . . . . . . . 14 86 6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 14 87 7. Mechanisms to secure the use of tunnels . . . . . . . . . . . 16 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 11. Informative References . . . . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 With NAT devices becoming increasingly more prevalent, there have 97 recently been many tunneling protocols developed that go through NAT 98 devices or firewalls by tunneling over UDP or TCP. For example, 99 Teredo [RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel 100 IP packets over UDP. Similarly, many SSL VPN solutions that tunnel 101 IP packets over HTTP (and hence over TCP) are deployed today. 103 This document discusses security concerns with tunneling IP packets, 104 and includes recommendations where relevant. 106 The primary intent of this document is to help improve security 107 deployments using tunnel protocols. In addition, the document aims 108 to provide information that can be used in any new or updated tunnel 109 protocol specification. The intended audience of this document 110 includes network administrators and future protocol developers. 112 2. Tunnels May Bypass Security 114 2.1. Network Security Bypass 116 2.1.1. Problem 118 Tunneled IP traffic may not receive the intended level of inspection 119 or policy application by network-based security devices unless such 120 devices are specifically tunnel-aware. This reduces defense in depth 121 and may cause security gaps. This applies to all network-located 122 devices and to any end-host based firewalls whose existing hooking 123 mechanism(s) would not show them the IP packet stream after the 124 tunnel client does decapsulation or before it does encapsulation. 126 2.1.2. Discussion 128 Evasion by tunneling is often a problem for network-based security 129 devices such as network firewalls, intrusion detection and prevention 130 systems, and router controls. To provide such functionality in the 131 presence of tunnels, the developer of such devices must add support 132 for parsing each new protocol. There is typically a significant lag 133 between when the security developer recognizes that a tunnel will be 134 used (or will be remotely usable) to a significant degree and when 135 the parsing can be implemented in a product update, the update tested 136 and released, and customers begin using the update. Late changes in 137 the protocol specification or in the way it is implemented can cause 138 additional delays. This becomes a significant security concern when 139 a delay in applied coverage is occurring frequently. One way to cut 140 down on this lag is for security developers to follow the progress of 141 new IETF protocols but this will still not account for any new 142 proprietary protocols. 144 For example, for L2TP or Teredo, an unaware network security device 145 would inspect or regulate the outer IP and the IP-based UDP layer as 146 normal, but it would not recognize that there is an additional IP 147 layer contained inside the UDP payload to which it needs to apply the 148 same controls as it would to a native packet. (Of course, if the 149 device discards the packet due to something in the IP or UDP header, 150 such as referring to an unknown protocol, the embedded packet is no 151 longer a concern.) In addition, if the tunnel does encryption, the 152 network-based security device may not be able to do much, just as if 153 IPsec end-to-end encryption were used without tunneling. 155 Network security controls being not applied must be a concern to 156 those that set them up, since those controls are supposed to provide 157 an additional layer of defense against external attackers. If 158 network controls are being bypassed due to the use of tunneling, the 159 strength of the defense (i.e. the number of layers of defense) is 160 reduced. Since security administrators may have a significantly 161 reduced level of confidence without this layer, this becomes a 162 concern to them. 164 One implication of the security control bypass is that defense in 165 depth has been reduced, perhaps down to zero unless a local firewall 166 is in use as recommended in [RFC4380]. However, even if there are 167 host-based security controls that recognize tunnels, security 168 administrators may not have configured them with full security 169 control parity, even if all controls that were maintained by the 170 network are available on the host. Thus there may be gaps in desired 171 coverage. 173 Compounding this is that, unlike what would be the case for native 174 IP, some network administrators will not even be aware that their 175 hosts are globally reachable, if the tunnel provides connectivity to/ 176 from the Internet; for example, they may not be expecting this for 177 hosts behind a stateful firewall. In addition, Section 3.2 discusses 178 how it may not be efficient to find all tunneled traffic for network 179 devices to examine. 181 2.1.3. Recommendations 183 Security administrators who do not consider tunneling an acceptable 184 risk should disable tunnel functionality either on the end-nodes 185 (hosts) or on the network nodes at the perimeter of their network. 186 However, there may be an awareness gap. Thus, due to the possible 187 negative security consequences, tunneling functionality should be 188 easy to disable on the host and through a central management facility 189 if one is provided. 191 To minimize security exposure due to tunnels, we recommend that a 192 tunnel be an interface of last resort, independent of IP version. 193 Specifically, we suggest that when both native and tunneled access to 194 a remote host is available, that the native access be used in 195 preference to tunneled access except when the tunnel endpoint is 196 known to not bypass security (e.g., an IPsec tunnel to a gateway 197 provided by the security administrator of the network). This should 198 also promote greater efficiency and reliability. 200 Note that although Rule 7 of [RFC3484] section 6 will prefer native 201 connectivity over tunnels, this rule is only a tie-breaker when a 202 choice is not made by earlier rules; hence tunneling mechanisms that 203 are tied to a particular range of IP address space will be decided 204 based on the prefix precedence. For example, using the prefix policy 205 mechanism of [RFC3484] section 2.1, Teredo might have a precedence of 206 5 so that native IPv4 is preferred over Teredo. 208 2.2. IP Ingress and Egress Filtering Bypass 210 2.2.1. Problem 212 IP addresses inside tunnels are not subject to ingress and egress 213 filtering in the network they tunnel over, unless extraordinary 214 measures are taken. Only the tunnel endpoints can do such filtering. 216 2.2.2. Discussion 218 Ingress filtering (sanity-checking incoming destination addresses) 219 and egress filtering (sanity-checking outgoing source addresses) are 220 done to mitigate attacks and to make it easier to identify the source 221 of a packet and are considered to be a good practice. e.g. ingress 222 filtering at the network perimeter should not allow packets with a 223 source address that belongs to the network to enter the network from 224 the outside the network. This function is most naturally (and in the 225 general case, by requirement) done at network boundaries. Tunneled 226 IP traffic bypassing this network control is a specific case of 227 Section 2.1, but is illustrative. 229 2.2.3. Recommendations 231 Tunnel servers can apply ingress and egress controls to tunneled IP 232 addresses passing through them to and from tunnel clients. 234 Tunnel clients could make an effort to conduct ingress and egress 235 filtering. 237 Implementations of protocols that embed an IPv4 address in a tunneled 238 IPv6 address directly between peers should perform filtering based on 239 checking the correspondence. 241 Implementations of protocols that accept tunneled packets directly 242 from a server, relay or protocol peer do filtering the same way as it 243 would be done on a native link with traffic from a router. 245 Some protocols such as 6to4 [RFC3056], Teredo, and ISATAP [RFC5214] 246 allow both other hosts and a router over a common tunnel. To perform 247 host-based filtering with such protocols a host would need to know 248 the outer IP address of each router from which it could receive 249 traffic, so that packets from hosts beyond the router will be 250 accepted even though the source address would not embed the router's 251 IP address. Router addresses might be learned via Secure Neighbor 252 Discovery (SEND) [RFC3971] or some other mechanism (e.g., [RFC5214] 253 section 8.3.2). 255 2.3. Source Routing After the Tunnel Client 257 2.3.1. Problem 259 If the encapsulated IP packet specifies source routing beyond the 260 recipient tunnel client, the host may forward the IP packet to the 261 specified next hop. This may be unexpected and contrary to 262 administrator wishes and may have bypassed network-based source 263 routing controls. 265 2.3.2. Discussion 267 A detailed discussion of issues related to source routing can be 268 found in [RFC5095] and [SECA-IP]. 270 2.3.3. Recommendations 272 Tunnel clients should by default discard tunneled IP packets that 273 specify additional routing, as recommended in [RFC5095] and 274 [SECA-IP], though they may also allow the user to configure what 275 source routing types are allowed. All pre-existing source routing 276 controls should be upgraded to apply these controls to tunneled IP 277 packets as well. 279 3. Challenges in Inspecting and Filtering Content of Tunneled Data 280 Packets 282 3.1. Inefficiency of Selective Network Filtering of All Tunneled 283 Packets 285 3.1.1. Problem 287 There is no mechanism to both efficiently and immediately filter all 288 tunneled packets (other than the obviously faulty method of filtering 289 all packets). This limits the ability to prevent tunnel use on a 290 network. 292 3.1.2. Discussion 294 Given concerns about tunnel security or a network's lack of 295 preparedness for tunnels, a network administrator may wish to simply 296 block all use of tunnels that bypass security policies. He or she 297 may wish to do so using network controls; this could be either due to 298 not having the capability to disable tunneling on all hosts attached 299 to the network or due to wanting an extra layer of prevention. 301 One simple method of doing this easily for many tunnel protocols is 302 to block outbound packets to the UDP or TCP port used (e.g., 303 destination UDP port is 3544 for Teredo, UDP port 1701 for L2TP, 304 etc.). This prevents a tunnel client from establishing a new tunnel. 305 However, existing tunnels will not necessarily be affected if the 306 blocked port is used only for initial setup. In addition, if the 307 blocking is applied on the outside of the client's NAT device, the 308 NAT device will retain the port mapping for the client. In some 309 cases, however, blocking all traffic to a given outbound port (e.g., 310 port 80) may interfere with non-tunneled traffic so this should be 311 used with caution. 313 Another simple alternative, if the tunnel server addresses are well- 314 known, is to filter out all traffic to/from such addresses. 316 The other approach is to find all packets to block in the same way as 317 would be done for inspecting all packets (Section 3.2). However; 318 this faces the difficulties in terms of efficiency of filtering, as 319 is discussed there. 321 3.1.3. Recommendations 323 Developers of protocols that tunnel over UDP or TCP (including HTTP) 324 to reach the Internet should disable their protocols in networks that 325 wish to enforce security policies on the user traffic. (Windows, for 326 example, disables Teredo by default if it detects that it is within 327 an enterprise network that contains a Windows domain controller.) 329 Administrators of such networks may wish to filter all tunneled 330 traffic at the boundaries of their networks. It is sufficient to 331 filter out the tunneled connection requests (if they can be 332 identified) to stop further tunneled traffic. The easiest mechanism 333 for this would be to filter out outgoing traffic sent to the 334 destination port defined by the tunneling protocol, and incoming 335 traffic with that source port. Similarly, in certain cases, it is 336 also possible to use the IP protocol field to identify and filter 337 tunneled packets. e.g. 6to4 [RFC3056] is a tunneling mechanism that 338 uses the IPv4 packets to carry encapsulated IPv6 packets, and can be 339 identified by the IPv4 protocol type 41. 341 3.2. Problems with deep packet inspection of tunneled data packets 343 3.2.1. Problem 345 There is no efficient mechanism for network-based devices, which are 346 not the tunnel endpoint, to inspect the contents of all tunneled data 347 packets, the way they can for native packets. This makes it 348 difficult to apply the same controls as they do to native IP. 350 3.2.2. Discussion 352 Some tunnel protocols are easy to identify, such as if all data 353 packets are encapsulated using a well-known UDP or TCP port that is 354 unique to the protocol. 356 Other protocols, however, either use dynamic ports for data traffic, 357 or else share ports with other protocols (e.g., tunnels over HTTP). 359 The implication of this is that network-based devices that wish to 360 passively inspect (and perhaps selectively apply policy to) all 361 encapsulated traffic must inspect all TCP or UDP packets (or at least 362 all packets not part of a session that is known not to be a tunnel). 363 This is imperfect since a heuristic must then be applied to determine 364 if a packet is indeed part of a tunnel. This may be too slow to make 365 use of in practice, especially if it means that all TCP or UDP 366 packets must be taken off of the device's "fast path". 368 One heuristic that can be used on packets to determine if they are 369 tunnel-related or not is as follows. For each known tunnel protocol, 370 attempt parsing the packet as if it were a packet of that protocol, 371 destined to the local host (i.e., where the local host has the 372 destination address in the inner IP header, if any). If all syntax 373 checks pass, up to and including the inner IP header (if the tunnel 374 doesn't use encryption), then treat the packet as if it is a tunneled 375 packet of that protocol. 377 It is possible that non-tunnel packets will match as tunneled using 378 this heuristic, but tunneled packets (of the known types of tunnels) 379 should not escape inspection, absent implementation bugs. 381 For some protocols, it may be possible to monitor setup exchanges to 382 know to expect that data will be exchanged on certain ports later. 383 (Note that this does not necessarily apply to Teredo, for example, 384 since communicating with another Teredo client behind a cone NAT 385 [RFC5389] device does not require such signaling. In such cases this 386 control will not work. However, deprecation of the cone bit as 387 discussed in [RFC5991] means this technique may indeed work with 388 updated Teredo implementations.) 390 3.2.3. Recommendations 392 As illustrated above, it should be clear that inspecting the contents 393 of tunneled data packets is highly complex and often impractical. 394 For this reason, if a network wishes to monitor IP traffic, tunneling 395 across, as opposed to tunneling to, the security boundary is not 396 recommended. For example, to provide an IPv6 transition solution, 397 the network should provide native IPv6 connectivity or a tunnel 398 solution (e.g., ISATAP or 6over4) that encapsulates data packets 399 between hosts and a router within the network. 401 4. Increased Exposure Due to Tunneling 403 4.1. NAT Holes Increase Attack Surface 405 4.1.1. Problem 407 If the tunnel allows inbound access from the public Internet, the 408 opening created in a NAT device due to a tunnel client increases its 409 Internet attack surface area. If vulnerabilities are present, this 410 increased exposure can be used by attackers and their programs. 412 If the tunnel allows inbound access only from a private network 413 (e.g., a remote network to which one has VPN'ed), the opening created 414 in the NAT device still increases its attack surface area, although 415 not as much as in the public Internet case. 417 4.1.2. Discussion 419 When a tunnel is active, a mapped port is maintained on the NAT 420 device through which remote hosts can send packets and perhaps 421 establish connections. The following sequence is intended to sketch 422 out the processing on the tunnel client host that can be reached 423 through this mapped port; the actual processing for a given host may 424 be somewhat different. 426 1. Link-layer protocol processing 428 2. (Outer) IP host firewall processing 430 3. (Outer) IP processing by stack 432 4. UDP/TCP processing by stack 434 5. Tunnel client processing 436 6. (Inner) IP host firewall processing 438 7. (Inner) IP processing by stack 440 8. Various upper layer processing may follow 442 The inner firewall (and other security) processing may or may not be 443 present, but if it is, some of the inner IP processing may be 444 filtered. (For example, [RFC4380] section 7.1 recommends that an 445 IPv6 host firewall be used on all Teredo clients.) 447 (By the virtue of the tunnel being active, we can infer that the 448 inner host firewall is unlikely to do any filtering based on the 449 outer IP.) Any of this processing may expose vulnerabilities an 450 attacker can exploit; similarly these may expose information to an 451 attacker. Thus, even if firewall filtering is in place (as is 452 prudent) and filters all incoming packets, the exposed area is larger 453 than if a native IP Internet connection were in place, due to the 454 processing that takes place before the inner IP is reached 455 (specifically, the UDP/TCP processing, the tunnel client processing, 456 and additional IP processing, especially if one is IPv4 and the other 457 is IPv6). 459 One possibility is that a layer 3 targeted worm makes use of a 460 vulnerability in the exposed processing. The main benefit tunneling 461 provides to worms is enabling L3 reachability to the end host. Even 462 a thoroughly firewalled host could be subject to a worm that spreads 463 with a single UDP packet if the right remote code vulnerability is 464 present. 466 4.1.3. Recommendations 468 This problem seems inherent in tunneling being active on a host, so 469 the solution seems to be to minimize tunneling use. 471 For example, it can be active only when it is really needed and only 472 for as long as needed. So, the tunnel interface can be initially not 473 configured and only used when it is entirely the last resort. The 474 interface should then be deactivated (ideally, automatically) again 475 as soon as possible. Note however that the hole will remain in the 476 NAT device for some amount of time after this, so some processing of 477 incoming packets is inevitable unless the client's native IP address 478 behind the NAT device is changed. 480 4.2. Exposure of a NAT Hole 482 4.2.1. Problem 484 Attackers are more likely to know about a tunnel client's NAT hole 485 than a typical hole in the NAT device. If they know about the hole, 486 they could try to use it. 488 4.2.2. Discussion 490 There are at least three reasons why an attacker may be more likely 491 to learn of the tunnel client's exposed port than a typical NAT 492 exposed port: 494 1. The NAT mapping for a tunnel is typically held open for a 495 significant period of time, and kept stable. This increases the 496 chance of it being discovered. 498 2. In some protocols (e.g., Teredo), the external IP address and 499 port are contained in the client's address that is used end-to- 500 end and possibly even advertised in a name resolution system. 501 While the tunnel protocol itself might only distribute this 502 address in IP headers, peers, routers, and other on-path nodes 503 still see the client's IP address. Although this point does not 504 apply directly to protocols (e.g., L2TP) that do not construct 505 the inner IP address based on the outer IP address, the inner IP 506 address is still known to peers, routers, etc. and can still be 507 reached by attackers without knowing the external IP address or 508 port. 510 3. The tunnel protocol often contains more messages that are 511 exchanged and with more parties (e.g., due to a longer path 512 length) than without using the tunnel, offering more chance for 513 visibility into the port and address in use. 515 4.2.3. Recommendations 517 The recommendations from Section 4.1 seem to apply here as well: 518 minimize tunnel use. 520 4.3. Public Tunnels Widen Holes in Restricted NATs 522 4.3.1. Problem 524 Tunnels that allow inbound connectivity from the Internet (e.g., 525 Teredo, tunnel brokers, etc) essentially disable the filtering 526 behavior of the NAT for all tunnel client ports. This eliminates NAT 527 devices filtering for such ports and may eliminate the need for an 528 attacker to spoof an address. 530 4.3.2. Discussion 532 NATs that implement Address-Dependent or Address and Port-Dependent 533 Filtering [RFC4787] limit the source of incoming packets to just 534 those that are a previous destination. This poses a problem for 535 tunnels that intend to allow inbound connectivity from the Internet. 537 Various protocols (e.g., Teredo, STUN [RFC5389], etc.) provide a 538 facility for peers, upon request, to become a previous destination. 539 This works by sending a "bubble" packet via a server, which is passed 540 to the client, and then sent by the client (through the NAT) to the 541 originator. 543 This removes any NAT-based barrier to attackers sending packets in 544 through the client's service port. In particular, an attacker would 545 no longer need to either be an actual previous destination or to 546 forge its addresses as a previous destination. When forging, the 547 attacker would have had to learn of a previous destination and then 548 would face more challenges in seeing any returned traffic. 550 4.3.3. Recommendations 552 If the tunnel can provide connectivity to the Internet, the tunnel 553 client should run a host firewall on the tunnel interface. Also, 554 minimizing public tunnel use (see Section 4.1.3) would lower the 555 attack opportunity related to this exposure. 557 5. Tunnel Address Concerns 559 5.1. Feasibility of Guessing Tunnel Addresses 561 5.1.1. Problem 563 For some types of tunneling protocols, it may be feasible to guess IP 564 addresses assigned to tunnels, either when looking for a specific 565 client or when looking for an arbitrary client. This is in contrast 566 to native IPv6 addresses in general, but is no worse than for native 567 IPv4 addresses today. 569 For example, some protocols (e.g., 6to4 and Teredo) use well-defined 570 address ranges. As another example, using well-known public servers 571 for Teredo or tunnel brokers also implies using a well known address 572 range. 574 5.2. Profiling Targets Based on Tunnel Address 576 5.2.1. Problem 578 An attacker encountering an address associated with a particular 579 tunneling protocol or well-known tunnel server has the opportunity to 580 infer certain relevant pieces of information that can be used to 581 profile the host before sending any packets. This can reduce the 582 attacker's footprint and increase the attacker's efficiency. 584 5.2.2. Discussion 586 The tunnel address reveals some information about the nature of the 587 client. 589 o That a host has a tunnel address associated with a given protocol 590 means that the client is running on some platform for which there 591 exists a tunnel client implementation of that protocol. In 592 addition, if some platforms have that protocol installed by 593 default and where the host's default rules for using it make it 594 susceptible to being in use, then it is more likely to be running 595 on such a platform than on one where it is not used by default. 596 For example, as of this writing, seeing a Teredo address suggests 597 that the host it is on is probably running Windows. 599 o Similarly, the use of an address associated with a particular 600 tunnel server also suggests some information. Tunnel client 601 software is often deployed, installed, and/or configured using 602 some degree of automation. It seems likely that the majority of 603 the time the tunnel server that results from the initial 604 configuration will go unchanged from the initial setting. 605 Moreover, the server that is configured for use may be associated 606 with a particular means of installation, which often suggests the 607 platform. For example, if the server field in a Teredo address is 608 one of the IPv4 addressees to which teredo.ipv6.microsoft.com 609 resolves, it suggests that the host is running Windows. 611 o The external IPv4 address of a NAT device can of course be readily 612 associated with a particular organization or at least an ISP, and 613 hence putting this address in an IPv6 address reveals this 614 information. However, this is no different than using a native IP 615 address, and hence is not new with tunneling. 617 o It is also possible that external client port numbers may be more 618 often associated with particular client software or the platform 619 on which it is running. The usefulness of this for platform 620 determination is, however, reduced by the different NAT port 621 number assignment behaviors. In addition, the same observations 622 would apply to use of UDP or TCP over native IP as well, and hence 623 this is not new with tunneling. 625 The platform, tunnel client software, or organization information can 626 be used by an attacker to target attacks more carefully. For 627 example, an attacker may decide to attack an address only if it is 628 likely to be associated with a particular platform or tunnel client 629 software with a known vulnerability. (This is similar to the ability 630 to guess some platforms based on the OUI in the EUI-64 portion of an 631 IPv6 address generated from a MAC address, since some platforms are 632 commonly used with interface cards from particular vendors.) 634 5.2.3. Recommendations 636 If installation programs randomized the server setting, that would 637 reduce the extent to which they can be profiled. Similarly, 638 administrators can choose to change the default setting to reduce the 639 degree to which they can be profiled ahead of time. 641 Randomizing the tunnel client port in use would mitigate any 642 profiling that can be done based on the external port, especially if 643 multiple different tunnel clients did this. Further discussion on 644 randomizing ports can be found at [TSV-PORT]. 646 It is recommended that tunnel protocols minimize the propagation of 647 knowledge about whether the NAT is a cone NAT. 649 6. Additional Security Concerns 651 6.1. Attacks Facilitated By Changing Tunnel Server Setting 653 6.1.1. Problem 655 If an attacker could either change a tunnel client's server setting 656 or change the IP addresses to which a configured host name resolves 657 (e.g., by intercepting DNS queries) AND the tunnel is not 658 authenticated, it would let the attacker become a man in the middle. 659 This would allow them to at least monitor peer communication and at 660 worst to impersonate the remote peer. 662 6.1.2. Discussion 664 A client's server has good visibility into the client's communication 665 with IP peers. If the server were switched to one that records this 666 information and makes it available to third parties (e.g., 667 advertisers, competitors, spouses, etc.) then sensitive information 668 would be disclosed, especially if the client's host prefers the 669 tunnel over native IP. Assuming the server provides good service, 670 the user would not have reason to suspect the change. 672 Full interception of IP traffic could also be arranged (including 673 pharming) which would allow any number of deception or monitoring 674 attacks including phishing. We illustrate this with an example 675 phishing attack scenario. 677 It is often assumed that the tunnel server is a trusted entity. It 678 may be possible for malware or a malicious user to quietly change the 679 client's tunnel server setting and have the user be unaware their 680 trust has been misplaced for an indefinite period of time. However, 681 malware or a malicious user can do much worse than this, so this is 682 not a significant concern. Hence it is only important that an 683 attacker on the network cannot change the client's server setting. 685 1. A phisher sets up a malicious tunnel server (or tampers with a 686 legitimate one). This server, for the most part, provides 687 correct service. 689 2. An attacker, by some means, switches the host's tunnel server 690 setting, or spoofs a DNS reply, to point to the above server. If 691 neither DNS nor the tunnel setup is secured (i.e., if the client 692 does not authenticate the information), then the attacker's 693 tunnel server is seen as legitimate. 695 3. A user on the victim host types their bank's URL into his/her 696 browser. 698 4. The bank's hostname resolves to one or more IP addresses and the 699 tunnel is selected for socket connection for whatever reason 700 (e.g., the tunnel provides IPv6 connectivity and the bank has an 701 IPv6 address). 703 5. The tunnel client uses the server for help in connecting to the 704 bank's IP address. Some tunneling protocols use a separate 705 channel for signaling vs data, but this still allows the server 706 to place itself in the data path by an appropriate signal to the 707 client. For example, in Teredo, the client sends a ping request 708 through a server which is expected to come back through a data 709 relay, and a malicious server can simply send it back itself to 710 indicate that is a data relay for the communication. 712 6. The rest works pretty much like any normal phishing transaction, 713 except that the attacker acts as a tunnel server (or data relay, 714 for protocols such as Teredo) and a host with the bank's IP 715 address. 717 This pharming type attack is not unique to tunneling. Switching DNS 718 server settings to a malicious DNS server or DNS cache poisoning in a 719 recursive DNS resolver could have a similar effect. 721 6.1.3. Recommendations 723 In general, anti-phishing and anti-fraud provisions should help with 724 aspects of this, as well as software that specifically monitors for 725 tunnel server changes. 727 Perhaps the best way to mitigate tunnel-specific attacks is to have 728 the client either authenticate the tunnel server, or at least the 729 means by which the tunnel server's IP address is determined. For 730 example, SSL VPNs use https URLs and hence authenticate the server as 731 being the expected one. Another mechanism, when IPv6 Router 732 Advertisements are sent over the tunnel is to use SEcure Neighbor 733 Discovery (SEND) [RFC3971] to verify that the client trusts the 734 server. 736 On the host, it should require an appropriate level of privilege in 737 order to change the tunnel server setting (as well as other non- 738 tunnel-specific settings such as the DNS server setting, etc.). 739 Making it easy to see the current tunnel server setting (e.g., not 740 requiring privilege for this) should help detection of changes. 742 The scope of the attack can also be reduced by limiting tunneling use 743 in general but especially in preferring native IPv4 to tunneled IPv6; 744 this is because it is reasonable to expect that banks and similar web 745 sites will continue to be accessible over IPv4 for as long as a 746 significant fraction of their customers are still IPv4-only. Please 747 refer to Section 3 of [TUNNEL-LOOPS] for a detailed description and 748 mitigation measures for a class of attacks based on IPv6 automatic 749 tunnels. 751 7. Mechanisms to secure the use of tunnels 753 This document described several security issues with tunnels. This 754 does not mean that tunnels need to be avoided at any cost. On the 755 contrary, tunnels can be very useful if deployed, operated and used 756 properly. The threats against IP tunnels are documented here. If 757 the threats can be mitigated, network administrators can efficiently 758 and securely use tunnels in their network. Several measures can be 759 taken in order to secure the operation of IPv6 tunnels: 761 o Operating on-premise tunnel servers/relays so that the tunneled 762 traffic does not cross border routers. 764 o Setting up internal routing to steer traffic to these servers/ 765 relays 767 o Setting up of firewalls [RFC2979] to allow known and controllable 768 tunneling mechanisms and disallow unknown tunnels. 770 8. Acknowledgments 772 The authors would like to thank Remi Denis-Courmont, Fred Templin, 773 Jordi Palet Martinez, James Woodyatt, Christian Huitema, Brian 774 Carpenter, Nathan Ward, Kurt Zeilenga, Joel Halpern, Erik Kline, 775 Alfred Hoenes and Fernando Gont for reviewing earlier versions of the 776 document and providing comments to make this document better. 778 9. Security Considerations 780 This entire document discusses security concerns with tunnels. 782 10. IANA Considerations 784 This document does not require any IANA action. 786 11. Informative References 788 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 789 E. Lear, "Address Allocation for Private Internets", 790 BCP 5, RFC 1918, February 1996. 792 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 793 Domains without Explicit Tunnels", RFC 2529, March 1999. 795 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 796 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 797 RFC 2661, August 1999. 799 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 800 Firewalls", RFC 2979, October 2000. 802 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 803 via IPv4 Clouds", RFC 3056, February 2001. 805 [RFC3484] Draves, R., "Default Address Selection for Internet 806 Protocol version 6 (IPv6)", RFC 3484, February 2003. 808 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 809 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 811 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 812 Neighbor Discovery (SEND)", RFC 3971, March 2005. 814 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 815 Network Address Translations (NATs)", RFC 4380, 816 February 2006. 818 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 819 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 820 RFC 4787, January 2007. 822 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 823 of Type 0 Routing Headers in IPv6", RFC 5095, 824 December 2007. 826 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 827 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 828 March 2008. 830 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 831 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 832 October 2008. 834 [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo 835 Security Updates", RFC 5991, September 2010. 837 [SECA-IP] Gont, F., "Security Assessment of the Internet Protocol 838 version 4", draft-ietf-opsec-ip-security-03 (work in 839 progress), April 2010. 841 [TSV-PORT] 842 Larsen, M. and F. Gont, "Transport Protocol Port 843 Randomization Recommendations", 844 draft-ietf-tsvwg-port-randomization-09 (work in progress), 845 August 2010. 847 [TUNNEL-LOOPS] 848 Nakibly, G. and F. Templin, "Routing Loop Attack using 849 IPv6 Automatic Tunnels: Problem Statement and Proposed 850 Mitigations", draft-ietf-v6ops-tunnel-loops-00 (work in 851 progress), September 2010. 853 Authors' Addresses 855 Suresh Krishnan 856 Ericsson 857 8400 Decarie Blvd. 858 Town of Mount Royal, QC 859 Canada 861 Phone: +1 514 345 7900 x42871 862 Email: suresh.krishnan@ericsson.com 864 Dave Thaler 865 Microsoft Corporation 866 One Microsoft Way 867 Redmond, WA 98052 868 USA 870 Phone: +1 425 703 8835 871 Email: dthaler@microsoft.com 873 James Hoagland 874 Symantec Corporation 875 350 Ellis St. 876 Mountain View, CA 94043 877 US 879 Email: Jim_Hoagland@symantec.com 880 URI: http://symantec.com/