idnits 2.17.1 draft-ietf-v6ops-tunnel-security-concerns-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 856. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 863. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 869. 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. 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 7, 2008) is 5772 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) == Unused Reference: 'RFC4861' is defined on line 788, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 4214 (Obsoleted by RFC 5214) == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-01 Summary: 4 errors (**), 0 flaws (~~), 5 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 8, 2009 S. Krishnan 5 Ericsson 6 D. Thaler 7 Microsoft 8 July 7, 2008 10 Security Concerns With Tunneling 11 draft-ietf-v6ops-tunnel-security-concerns-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 8, 2009. 38 Abstract 40 A number of security concerns with tunnels are documented. The 41 primary intent of this document is to raise the awareness regarding 42 the security issues with tunnels as deployed today. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Tunnels May Bypass Security . . . . . . . . . . . . . . . . . 3 48 2.1. Network Security Bypass . . . . . . . . . . . . . . . . . 3 49 2.2. IP Ingress and Egress Filtering Bypass . . . . . . . . . . 5 50 2.3. Source Routing After the Tunnel Client . . . . . . . . . . 6 51 3. Challenges in Inspecting and Filtering Content of Tunneled 52 Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 3.1. Inefficiency of Selective Network Filtering of All 54 Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7 55 3.2. Problems with deep packet inspection of tunneled data 56 packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 4. Increased Exposure Due to Tunneling . . . . . . . . . . . . . 9 58 4.1. NAT Holes Increase Attack Surface . . . . . . . . . . . . 9 59 4.2. Exposure of a NAT Hole . . . . . . . . . . . . . . . . . . 11 60 4.3. Public Tunnels Widen Holes in Restricted NATs . . . . . . 12 61 5. Tunnel Address Concerns . . . . . . . . . . . . . . . . . . . 12 62 5.1. Feasibility of Guessing Tunnel Addresses . . . . . . . . . 12 63 5.2. Profiling Targets Based on Tunnel Address . . . . . . . . 13 64 6. Additional Security Concerns . . . . . . . . . . . . . . . . . 14 65 6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 15 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 73 Intellectual Property and Copyright Statements . . . . . . . . . . 20 75 1. Introduction 77 With NATs becoming increasingly more prevalent, there have recently 78 been many tunneling protocols developed that go through NATs or 79 firewalls by tunneling over UDP or TCP. For example, Teredo 80 [RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel IP 81 packets over UDP. Similarly, many SSL VPN solutions that tunnel IP 82 packets over HTTP (and hence over TCP) are deployed today. 84 This document discusses security concerns with tunneling IP packets, 85 and includes recommendations where relevant. 87 The primary intent of this document is to provide information that 88 can be used in any new or updated tunnel protocol specification. 89 Secondarily, this document can help improve security deployments 90 using tunnel protocols. 92 2. Tunnels May Bypass Security 94 2.1. Network Security Bypass 96 2.1.1. Problem 98 Tunneled IP traffic may not receive the intended level of inspection 99 or policy application by network-based security devices unless such 100 devices are specifically tunnel-aware. This reduces defense in depth 101 and may cause security gaps. This applies to all network-located 102 devices and to any end-host based firewalls whose existing hooking 103 mechanism(s) would not show them the IP packet stream after the 104 tunnel client does decapsulation. 106 2.1.2. Discussion 108 Evasion by tunneling is often a problem for network-based security 109 devices such as network firewalls, intrusion detection and prevention 110 systems, and router controls. To provide such functionality in the 111 presence of tunnels, the developer of such devices must add support 112 for detunneling for each new protocol. There is typically a 113 significant lag between when the security developer recognizes that a 114 tunnel will be used (or will be remotely usable) to a significant 115 degree and when the detunneling can be implemented in a product 116 update, the update tested and released, and customers begin using the 117 update. Late changes in the protocol specification or in the way it 118 is implemented can cause additional delays. This becomes a 119 significant security concern when a delay in applied coverage is 120 occurring frequently. 122 For example, for L2TP or Teredo, an unaware network security device 123 would inspect or regulate the outer IP and the IP-based UDP layer as 124 normal, but it would not recognize that there is an additional IP 125 layer contained inside the UDP payload that it needs to apply the 126 same controls as it would to a native packet. (Of course, if the 127 device discards the packet due to something in the IP or UDP header, 128 such as referring to an unknown protocol, the embedded packet is no 129 longer a concern.) In addition, if the tunnel does encryption, the 130 network-based security device may not be able to do much, just as if 131 IPsec end-to-end encryption were used without tunneling. 133 Network security controls being not applied must be a concern to 134 those that set them up, since those controls are supposed to 135 adequately regulate all traffic. If network controls are being 136 bypassed due to the use of tunneling, the burden of controls shifts 137 to the tunnel client host. Since security administrators may not 138 have full control over all the nodes on their network, they sometimes 139 prefer to implement security controls on the network. 141 One implication of the security control bypass is that defense in 142 depth has been reduced, perhaps down to zero unless a 'local 143 firewall' is in use as recommended in [RFC4380]. However, even if 144 there are host-based security controls that recognize tunnels, 145 security administrators may not have configured them with full 146 security control parity, even if all controls that were maintained by 147 the network are available on the host. Thus there may be gaps in 148 desired coverage. 150 Compounding this is that, unlike what would be the case for native 151 IP, some network administrators will not even be aware that their 152 hosts are globally reachable, if the tunnel provides connectivity to/ 153 from the Internet; for example, they may not be expecting this for 154 hosts with [RFC1918] addresses behind a NAT. In addition, 155 Section 3.2 discusses how it may not be efficient to find all 156 tunneled traffic for network devices to examine. 158 2.1.3. Recommendations 160 Security administrators who do not consider tunneling an acceptable 161 risk should disable tunnel functionality unless their network-based 162 security controls adequately recognize the tunneled traffic. 163 However, there may be an awareness gap. Thus, due to the possible 164 negative security consequences, we recommend that explicit user 165 action be required to enable tunneling, at least for the first time. 167 For example, when Teredo is being enabled or when it is going to be 168 used for the first time, there could be a descriptive warning about 169 the possible reduction of defense in depth that will occur. In 170 addition, Teredo client functionality should be easy to disable on 171 the host and through a central management facility if one is 172 provided. (We could find no pre-existing mechanism for tunneling 173 protocols to use that could automate their functionality being 174 disabled unless all network-based security controls were aware of it. 175 A separate type of consent request packet would be needed.) 177 To minimize security exposure due to tunnels, we recommend that a 178 tunnel be an interface of last resort, independent of IP version. 179 Specifically, we suggest that when both native and tunneled access to 180 a remote host is available, that the native-based access be used in 181 preference to tunneled access. This should also promote greater 182 efficiency and reliability. 184 Note that although Rule 7 of [RFC3484] section 6 will prefer native 185 connectivity over tunnels, this rule is only a tie-breaker when a 186 choice is not made by earlier rules; hence tunneling mechanisms that 187 are tied to a particular range of IP address space will be decided 188 based on the prefix precedence. For example, using the prefix policy 189 mechanism of [RFC3484] section 2.1, Teredo might have a precedence of 190 5 so that native IPv4 is preferred over Teredo. 192 2.2. IP Ingress and Egress Filtering Bypass 194 2.2.1. Problem 196 IP addresses inside tunnels are not subject to ingress and egress 197 filtering in the network they tunnel over, unless extraordinary 198 measures are taken. Only the tunnel endpoints can do such filtering. 200 2.2.2. Discussion 202 Ingress filtering (sanity-checking incoming destination addresses) 203 and egress filtering (sanity-checking outgoing source addresses) are 204 done to mitigate attacks and to make it easier to identify the source 205 of a packet and are considered to be a good practice. This is most 206 naturally (and in the general case, by requirement) done at network 207 boundaries. Tunneled IP traffic bypassing this network control is a 208 specific case of Section 2.1, but is illustrative. 210 2.2.3. Recommendations 212 The recommendations in Section 2.1.3 can help here. For this problem 213 specifically, there are three locations in which ingress and egress 214 filtering can be done. 216 Network based: Network-based devices (e.g., routers) could be 217 updated to find all tunneled packets and to apply ingress and 218 egress controls equally to tunneled IP addresses. 220 Tunnel server based: Tunnel servers can apply ingress and egress 221 controls to tunneled IP addresses passing through them to and from 222 tunnel clients. 224 Host based: Tunnel clients could make an effort to conduct ingress 225 and egress filtering. 227 Protocols that embed an IPv4 address in a tunneled IPv6 address 228 directly between peers often do filtering based on checking the 229 correpondence. 231 Protocols that accept tunneled packets directly from a server or 232 relay do filtering the same way as it would be done on a native 233 link with traffic from a router. 235 To do host-based filtering with protocols that allow both other 236 hosts and a router over a common tunnel (e.g., 6to4 [RFC3056], 237 Teredo, ISATAP [RFC4214], and 6over4 [RFC2529]), hosts would need 238 to be able to know the outer IP address of all routers from which 239 it could receive traffic. This might be learned via Secure 240 Neighbor Discovery (SEND) [RFC3971] or some other mechanism (e.g., 241 [RFC4214] section 8.3.2). 243 2.3. Source Routing After the Tunnel Client 245 2.3.1. Problem 247 If the encapsulated IP packet specifies source routing beyond the 248 recipient tunnel client, the host may forward the IP packet to the 249 specified next hop. This may be unexpected and contrary to 250 administrator wishes and may have bypassed network-based source 251 routing controls. 253 2.3.2. Discussion 255 A detailed discussion of issues related to source routing can be 256 found in [RFC5095]. 258 2.3.3. Recommendations 260 Tunnel clients should by default discard tunneled IP packets that 261 specify additional routing, as recommended in [RFC5095], though they 262 may also allow the user to configure what source routing types are 263 allowed. All pre-existing source routing controls should be upgraded 264 to apply these controls to tunneled IP packets as well. 266 3. Challenges in Inspecting and Filtering Content of Tunneled Data 267 Packets 269 3.1. Inefficiency of Selective Network Filtering of All Tunneled 270 Packets 272 3.1.1. Problem 274 There is no mechanism to both efficiently and immediately filter all 275 tunneled packets. This limits the ability to prevent tunnel use on a 276 network. 278 3.1.2. Discussion 280 Given concerns about tunnel security or a network's lack of 281 preparedness for tunnels, a network administrator may wish to simply 282 block all use of tunnels. He or she may wish to do so using network 283 controls; this could be either due to not having confidence in the 284 ability to disable it on all hosts attached to the network or due to 285 wanting an extra layer of prevention. 287 One simple method to do that is easy to employ for many tunnel 288 protocols is to block outbound packets to the UDP or TCP port used 289 (e.g., UDP port 3544 for Teredo, UDP port 1701 for L2TP, etc.). This 290 prevents a tunnel client from establishing a new tunnel. However, 291 existing tunnels will not necessarily be affected if the blocked port 292 is used only for initial setup. In addition, if the blocking is 293 applied on the outside of the client's NAT, the NAT will retain the 294 port mapping for the client and the client may or may not continue to 295 use the IP address assigned to its tunnel. It is not known if 296 blocking all traffic to a given outbound port will interfere with 297 non-tunneled traffic. 299 Another simple alternative, if the tunnel server addresses are well- 300 known, is to filter out all traffic to/from such addresses. 302 The other approach is to find all packets to block in the same way as 303 would be done for inspecting all packets (Section 3.2). However, 304 this faces the difficulties in terms of efficiency of filtering as 305 was present there. 307 3.1.3. Recommendations 309 Tunneling over UDP or TCP (including HTTP) to reach the Internet is 310 not recommended as a solution for managed networks. (Windows, for 311 example, disables Teredo by default if it detects that it is within a 312 managed network.) 314 Administrators of such networks may wish to filter all tunneled 315 traffic at the boundaries of their networks. It is sufficient to 316 filter out the tunneled connection requests (if they can be 317 identified) to stop further tunneled traffic. The easiest mechanism 318 for this would be to filter out outgoing traffic sent to the 319 destination port defined by the tunneling protocol, and incoming 320 traffic with that source port. 322 3.2. Problems with deep packet inspection of tunneled data packets 324 3.2.1. Problem 326 There is no efficient mechanism for network-based devices to inspect 327 the contents of all tunneled data packets, the way they can for 328 native packets. This makes it difficult to apply the same controls 329 as they do to native IP. 331 3.2.2. Discussion 333 Some tunnel protocols are easy to identify, such as if all data 334 packets are encapsulated using a well-known UDP or TCP port that is 335 unique to the protocol. 337 Other protocols, however, either use dynamic ports for data traffic, 338 or else share ports with other protocols (e.g., tunnels over HTTP). 340 The implication of this is that network-based devices that wish to 341 passively inspect (and perhaps selectively apply policy to) all 342 encapsulated traffic must inspect all TCP or UDP packets (or at least 343 all packets not part of a session that is known not to be a tunnel). 344 This is imperfect since a heuristic must then be applied to determine 345 if a packet is indeed part of a tunnel. This may be too slow to make 346 use of in practice, especially if it means that all TCP or UDP 347 packets must be taken off of the device's "fast path". 349 One heuristic that can be used on packets to determine if they are 350 tunnel-related or not is as follows. For each known tunnel protocol, 351 attempt parsing the packet as if it were a packet of that protocol, 352 destined to the local host (i.e., where the local host has the 353 destination address in the inner IP header, if any). If all syntax 354 checks pass, up to and including the inner IP header (if the tunnel 355 doesn't use encryption), then treat the packet as if it is a tunneled 356 packet of that protocol. 358 It is possible that non-tunnel packets will match as tunneled using 359 this heuristic, but tunneled packets (of the known types of tunnels) 360 should not escape inspection, absent implementation bugs. 362 For some protocols, it may be possible to monitor setup exchanges to 363 know to expect that data will be exchanged on certain ports later. 364 (Note that this does not necessarily apply to Teredo, for example, 365 since communicating with another Teredo client behind a cone NAT does 366 not require such signaling. However, deprecation of the cone bit as 367 discussed in [RFC4380] means this technique may indeed work with 368 Teredo.) 370 3.2.3. Recommendations 372 As illustrated above, it should be clear that inspecting the contents 373 of tunneled data packets is highly complex and often impractical. 374 For this reason, if a network wishes to monitor IP traffic, tunneling 375 is not recommended. For example, to provide an IPv6 transition 376 solution, the network should provide native IPv6 connectivity or a 377 tunnel solution (e.g., ISATAP or 6over4) that encapsulates data 378 packets between hosts and a router within the network. 380 4. Increased Exposure Due to Tunneling 382 4.1. NAT Holes Increase Attack Surface 384 4.1.1. Problem 386 If the tunnel allows inbound access from the public Internet, the 387 opening created in a NAT due to a tunnel client increases its 388 Internet attack surface area. If vulnerabilities are present, this 389 increased exposure can be used by attackers and their programs. 391 If the tunnel allows inbound access only from a private network 392 (e.g., a remote network to which one has VPN'ed), the opening created 393 in the NAT still increases its attack surface area, although not as 394 much as in the public Internet case. 396 4.1.2. Discussion 398 When a tunnel is active, a mapped port is maintained on the NAT 399 through which remote hosts can send packets and perhaps establish 400 connections. The following sequence is intended to sketch out the 401 processing on the tunnel client host that can be reached through 402 this; the actual processing for a given host may be somewhat 403 different. 405 1. Link-layer protocol processing 407 2. (Outer) IP host firewall processing 409 3. (Outer) IP processing by stack 411 4. UDP/TCP processing by stack 413 5. Tunnel client processing 415 6. (Inner) IP host firewall processing 417 7. (Inner) IP processing by stack 419 8. Various upper layer processing may follow 421 The inner firewall (and other security) processing may or may not be 422 present, but if it is, some of the inner IP processing may be 423 filtered. (For example, [RFC4380] section 7.1 recommends that an 424 IPv6 host firewall be used on all Teredo clients.) 426 (By the virtue of the tunnel being active, we can infer that the 427 firewall is unlikely to do any filtering based on the outer IP.) Any 428 of this processing may expose vulnerabilities an attacker can 429 exploit; similarly these may expose information to an attacker. 430 Thus, even if firewall filtering is in place (as is prudent) and 431 filters all incoming packets, the exposed area is larger than if a 432 native IP Internet connection were in place, due to the processing 433 that takes place before the inner IP is reached (specifically, the 434 UDP/TCP processing, the tunnel client processing, and additional IP 435 processing, especially if one is IPv4 and the other is IPv6). 437 One possibility is that a layer 3 targeted worm makes use of a 438 vulnerability in the exposed processing. While the main benefit to 439 worms from tunneling is targeting at layer 3 reaching the end host, 440 even a throughly firewalled host could be subject to a worm that 441 spreads with a single UDP packet if the right remote code 442 vulnerability is present. 444 4.1.3. Recommendations 446 This problem seems inherent in tunneling being active on a host, so 447 the solution seems to be to minimize tunneling use. 449 For example, it can be active only when it is really needed and only 450 for as long as needed. So, the tunnel interface can be initially not 451 configured and only used when it is entirely the last resort. The 452 interface should then be deactivated (ideally, automatically) again 453 as soon as possible. Note however that the hole will remain in the 454 NAT for some amount of time after this, so some processing of 455 incoming packets is inevitable (unless the client's native IP address 456 behind the NAT is changed). 458 4.2. Exposure of a NAT Hole 460 4.2.1. Problem 462 Attackers are more likely to know about a tunnel client's NAT hole 463 than a typical hole in the NAT. If they know about the hole, they 464 could try to use it. 466 4.2.2. Discussion 468 There are at least three reasons why an attacker may be more likely 469 to learn of the tunnel client's exposed port than a typical NAT 470 exposed port: 472 1. The NAT mapping for a tunnel is typically held open for a 473 significant period of time, and kept stable. This increases the 474 chance of it being discovered. 476 2. In some protocols (e.g., Teredo), the external IP address and 477 port are contained in the client's address that is used end-to- 478 end and possibly even advertised in a name resolution system. 479 While the tunnel protocol itself might only distribute this 480 address in IP headers, peers, routers, and other on-path nodes 481 still see the client's IP address. Although this point does not 482 apply directly to protocols (e.g., L2TP) that do not construct 483 the inner IP address based on the outer IP address, the inner IP 484 address is still known to peers, routers, etc. and can still be 485 reached by attackers without knowing the external IP address or 486 port. 488 3. The tunnel protocol contains more messages that are exchanged and 489 with more parties (e.g., due to a longer path length) than 490 without using the tunnel, offering more chance for visibility 491 into the port and address in use. 493 4.2.3. Recommendations 495 The recommendations from Section 4.1 seem to apply here as well: 496 minimize tunnel use. 498 4.3. Public Tunnels Widen Holes in Restricted NATs 500 4.3.1. Problem 502 Tunnels that allow inbound connectivity from the Internet (e.g., 503 Teredo, tunnel brokers, etc) essentially turn a restricted or 504 symmetric NAT into an unrestricted one, for all tunnel client ports. 505 This eliminates NAT filtering for such ports and may eliminate the 506 need for an attacker to spoof an address. 508 4.3.2. Discussion 510 Restricted, port restricted, and symmetric NATs [RFC3489] limit the 511 source of incoming packets to just those that are a previous 512 destination. This poses a problem for tunnels that intend to allow 513 inbound connectivity from the Internet. 515 Various protocols (e.g., Teredo, STUN [RFC3489], etc.) provide a 516 facility for peers, upon request, to become a previous destination. 517 This works by sending a "bubble" packet via a server, which is passed 518 to the client, and then sent by the client (through the NAT) to the 519 originator. 521 This removes any NAT-based barrier to attackers sending packets in 522 through the client's service port. In particular, an attacker would 523 no longer need to either be an actual previous destination or to 524 forge its addresses as a previous destination. When forging, the 525 attacker would have had to learn of a previous destination and then 526 would face more challenges in seeing any returned traffic. 528 4.3.3. Recommendations 530 Minimizing public tunnel use (see Section 4.1.3) would lower the 531 attack opportunity related to this exposure. 533 5. Tunnel Address Concerns 535 5.1. Feasibility of Guessing Tunnel Addresses 537 5.1.1. Problem 539 For some types of tunneling protocols, it may be feasible to guess IP 540 addresses assigned to tunnels, either when looking for a specific 541 client or when looking for an arbitrary client. This is in contrast 542 to native IPv6 addresses in general, but is no worse than for native 543 IPv4 addresses today. 545 For example, some protocols (e.g., 6to4 and Teredo) use well-defined 546 address ranges. As another example, using well-known public servers 547 for Teredo or tunnel brokers also implies using a well known address 548 range. 550 5.2. Profiling Targets Based on Tunnel Address 552 5.2.1. Problem 554 An attacker encountering an address associated with a particular 555 tunneling protocol or well-known tunnel server has the opportunity to 556 infer certain relevant pieces of information that can be used to 557 profile the host before sending any packets. This can reduce the 558 attacker's footprint and increase the attacker's efficiency. 560 5.2.2. Discussion 562 The tunnel address reveals some information about the nature of the 563 client. 565 o That a host has a tunnel address associated with a given proocol 566 means that the client is running on some platform for which there 567 exists a tunnel client implementation of that protocol. In 568 addition, if some platforms have that protocol installed by 569 default and where the host's default rules for using it make it 570 susceptible to being in use, then it is more likely to be running 571 on such a platform than on one where it is not used by default. 572 For example, as of this writing, seeing a Teredo address suggests 573 that the host it is on is running Windows Vista. 575 o Similarly, the use of an address associated with a particular 576 tunnel server also suggests some information. Tunnel client 577 software is often deployed, installed, and/or configured using 578 some degree of automation. It seems likely that the majority of 579 the time the tunnel server that results from the initial 580 configuration will go unchanged from the initial setting. 581 Moreover, the server that is configured for use may be associated 582 with a particular means of installation, which often suggests the 583 platform. For example, if the server field in a Teredo address is 584 one of the IPv4 addressees to which teredo.ipv6.microsoft.com 585 resolves, it suggests that the host is running Windows. 587 o The external IPv4 address of a NAT can of course be readily 588 associated with a particular organization or at least an ISP, and 589 hence putting this address in an IPv6 address reveals this 590 information. However, this is no different than using a native IP 591 address, and hence is not new with tunneling. 593 o It is also possible that external client port numbers may be more 594 often associated with particular client software or the platform 595 on which it is running. The usefulness of this for platform 596 determination is, however, reduced by the different NAT port 597 number assignment behaviors. In addition, the same observations 598 would apply to use of UDP or TCP over native IP as well, and hence 599 this is not new with tunneling. 601 The platform, tunnel client software, or organization information can 602 be used by an attacker to target attacks more carefully. For 603 example, an attacker may decide to attack an address only if it is 604 likely to be associated with a particular platform or tunnel client 605 software with a known vulnerability. (This is similar to the ability 606 to guess some platforms based on the OUI in the EUI-64 portion of an 607 IPv6 address generated from a MAC address, since some platforms are 608 commonly used with interface cards from particular vendors.) 610 In Teredo as defined in [RFC4380], the cone bit tells the attacker 611 whether a bubble is needed to proceed a connection. It may also have 612 some value in terms of profiling to the extent that it reveals the 613 security posture of the network. If the cone bit is set, the 614 attacker may decide it is fruitful to port scan the embedded external 615 IPv4 address and others associated with the same organization, 616 looking for open ports. As such, this cone bit is deprecated in 617 Windows Vista. 619 5.2.3. Recommendations 621 If installation programs randomized the server setting, that would 622 reduce the extent to which they can be profiled. Similarly, 623 administrators can choose to change the default setting to reduce the 624 degree to which they can be profiled ahead of time. 626 Randomizing the tunnel client port in use would mitigate any 627 profiling that can be done based on the external port, especially if 628 multiple different Teredo clients did this. Further discussion on 629 randomizing ports can be found at 630 [I-D.ietf-tsvwg-port-randomization]. 632 It is recommended that tunnel protocols minimize the propagation 633 knowledge about whether the NAT is a cone NAT. For example, the cone 634 bit for Teredo should be deprecated. 636 6. Additional Security Concerns 637 6.1. Attacks Facilitated By Changing Tunnel Server Setting 639 6.1.1. Problem 641 If an attacker could either change a tunnel client's server setting 642 or change the IP addresses to which a configured host name resolves 643 (e.g., by intercepting DNS queries), this would allow them to become 644 a man-in-the-middle at least monitor peer communication and at worst 645 pretend to represent the remote peer. 647 6.1.2. Discussion 649 A client's server has good visibility into the client's communication 650 with IP peers. If the server were switched to one that records this 651 information and makes it available to third parties (e.g., 652 advertisers, competitors, spouses, etc.) then sensitive information 653 is being disclosed, especially if the client's host prefers the 654 tunnel over native IP. Assuming the server provides good service, 655 the user would not have reason to suspect the change. 657 Full interception of IP traffic could also be arranged (including 658 pharming) which would allow any number of deception or monitoring 659 attacks including phishing. We illustrate this with an example 660 phishing attack scenario. 662 It is often assumed that the tunnel server is a trusted entity. It 663 may be possible for malware or a malicious user to quietly change the 664 Teredo client's server setting and have the user be unaware their 665 trust has been misplaced for an indefinite period of time. However, 666 malware or a malicious user can do much worse than this, so this is 667 not a significant concern. Hence it is only important that an 668 attacker on the network cannot change the client's server setting. 670 1. A phisher sets up a malicious tunnel server (or tampers with a 671 legitimate one). This server, for the most part, provides 672 correct service. 674 2. An attacker by some means and switches the host's tunnel server 675 setting, or spoofs a DNS reply, to point to the above server. If 676 neither DNS nor the tunnel setup is secured (i.e., if the client 677 does not authenticate the information), then the attacker's 678 tunnel server is seen as legitimate. 680 3. A user on the victim host types their bank's URL into his/her 681 browser. 683 4. The bank's hostname resolves to one or more IP addresses and the 684 tunnel is selected for socket connection for whatever reason 685 (e.g., the tunnel provides IPv6 connectivity and the bank has an 686 IPv6 address). 688 5. The tunnel client uses the server for help in connecting to the 689 the bank's IP address. Some tunneling protocols use a separate 690 channel for signaling vs data, but this still allows the server 691 to place itself in the data path by an appropriate signal to the 692 client. For example, in Teredo, the client sends a ping request 693 through a server which is expected to come back through a data 694 relay, and a malicious server can simply send it back itself to 695 indicate that is a data relay for the communication. 697 6. The rest works pretty much like any normal phishing transaction, 698 except that the attacker acts as a tunnel server (or data relay, 699 for protocols such as Teredo) and a host with the bank's IP 700 address. 702 This pharming type attack is not unique to tunneling. Switching DNS 703 server settings to a malicious DNS server could have similar effect. 705 6.1.3. Recommendations 707 In general, anti-phishing and anti-fraud provisions should help with 708 aspects of this, as well as software that specifically monitors for 709 tunnel server changes. 711 Perhaps the best way to mitigate tunnel-specific attacks is to have 712 the client either authenticate the tunnel server, or at least the 713 means by which the tunnel server's IP address is determined. For 714 example, SSL VPNs use https URLs and hence authenticate the server as 715 being the expected one. Another mechanism, when IPv6 Router 716 Advertisements are sent over the tunnel (e.g., in Teredo), is to use 717 SEcure Neighbor Discovery (SEND) to verify that the client trusts the 718 server. 720 On the host, it should require an appropriate level of privilege in 721 order to change the tunnel server setting (as well as other non- 722 tunnel-specific settings such as the DNS server setting, etc.). 723 Making it easy to see the current tunnel server setting (e.g., not 724 requiring privilege for this) should help detection of changes. 726 The scope of the attack can also be reduced by limiting tunneling use 727 in general but especially in preferring native IPv4 to tunneled IPv6; 728 this is because it is reasonable to expect that banks and similar web 729 sites will continue to be accessible over IPv4 for as long as a 730 significant fraction of their customers are still IPv4-only. 732 7. Acknowledgments 734 The authors would like to thank Remi Denis-Courmont, Fred Templin, 735 Jordi Palet Martinez, James Woodyatt and Christian Huitema for 736 reviewing earlier versions of the document and providing comments to 737 make this document better. The authors would also like to thank 738 Alfred Hines for a careful review of the document. 740 8. Security Considerations 742 This entire document discusses security concerns with tunnels. 744 9. IANA Considerations 746 There are no actions for IANA in this document. 748 10. References 750 10.1. Normative References 752 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 753 E. Lear, "Address Allocation for Private Internets", 754 BCP 5, RFC 1918, February 1996. 756 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 757 Domains without Explicit Tunnels", RFC 2529, March 1999. 759 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 760 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 761 RFC 2661, August 1999. 763 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 764 via IPv4 Clouds", RFC 3056, February 2001. 766 [RFC3484] Draves, R., "Default Address Selection for Internet 767 Protocol version 6 (IPv6)", RFC 3484, February 2003. 769 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 770 "STUN - Simple Traversal of User Datagram Protocol (UDP) 771 Through Network Address Translators (NATs)", RFC 3489, 772 March 2003. 774 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 775 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 777 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 778 Neighbor Discovery (SEND)", RFC 3971, March 2005. 780 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 781 "Intra-Site Automatic Tunnel Addressing Protocol 782 (ISATAP)", RFC 4214, October 2005. 784 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 785 Network Address Translations (NATs)", RFC 4380, 786 February 2006. 788 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 789 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 790 September 2007. 792 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 793 of Type 0 Routing Headers in IPv6", RFC 5095, 794 December 2007. 796 10.2. Informative References 798 [I-D.ietf-tsvwg-port-randomization] 799 Larsen, M. and F. Gont, "Port Randomization", 800 draft-ietf-tsvwg-port-randomization-01 (work in progress), 801 February 2008. 803 Authors' Addresses 805 James Hoagland 806 Symantec Corporation 807 350 Ellis St. 808 Mountain View, CA 94043 809 US 811 Email: Jim_Hoagland@symantec.com 812 URI: http://symantec.com/ 814 Suresh Krishnan 815 Ericsson 816 8400 Decarie Blvd. 817 Town of Mount Royal, QC 818 Canada 820 Phone: +1 514 345 7900 x42871 821 Email: suresh.krishnan@ericsson.com 822 Dave Thaler 823 Microsoft Corporation 824 One Microsoft Way 825 Redmond, WA 98052 826 USA 828 Phone: +1 425 703 8835 829 Email: dthaler@microsoft.com 831 Full Copyright Statement 833 Copyright (C) The IETF Trust (2008). 835 This document is subject to the rights, licenses and restrictions 836 contained in BCP 78, and except as set forth therein, the authors 837 retain all their rights. 839 This document and the information contained herein are provided on an 840 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 841 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 842 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 843 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 844 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 845 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 847 Intellectual Property 849 The IETF takes no position regarding the validity or scope of any 850 Intellectual Property Rights or other rights that might be claimed to 851 pertain to the implementation or use of the technology described in 852 this document or the extent to which any license under such rights 853 might or might not be available; nor does it represent that it has 854 made any independent effort to identify any such rights. Information 855 on the procedures with respect to rights in RFC documents can be 856 found in BCP 78 and BCP 79. 858 Copies of IPR disclosures made to the IETF Secretariat and any 859 assurances of licenses to be made available, or the result of an 860 attempt made to obtain a general license or permission for the use of 861 such proprietary rights by implementers or users of this 862 specification can be obtained from the IETF on-line IPR repository at 863 http://www.ietf.org/ipr. 865 The IETF invites any interested party to bring to its attention any 866 copyrights, patents or patent applications, or other proprietary 867 rights that may cover technology that may be required to implement 868 this standard. Please address the information to the IETF at 869 ietf-ipr@ietf.org.