Internet Engineering Task Force (IETF) S. Krishnan Request for Comments: 6169 Ericsson Category: Informational D. Thaler ISSN: 2070-1721 Microsoft J. Hoagland Symantec April 2011 Security Concerns with IP Tunneling
AbstractA number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6169. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction ....................................................2 2. Tunnels May Bypass Security .....................................3 2.1. Network Security Bypass ....................................3 2.2. IP Ingress and Egress Filtering Bypass .....................5 2.3. Source Routing after the Tunnel Client .....................6 3. Challenges in Inspecting and Filtering Content of Tunneled Data Packets ...........................................7 3.1. Inefficiency of Selective Network Filtering of All Tunneled Packets ...........................................7 3.2. Problems with Deep Packet Inspection of Tunneled Data Packets ...............................................8 4. Increased Exposure Due to Tunneling .............................9 4.1. NAT Holes Increase Attack Surface ..........................9 4.2. Exposure of a NAT Hole ....................................11 4.3. Public Tunnels Widen Holes in Restricted NATs .............12 5. Tunnel Address Concerns ........................................13 5.1. Feasibility of Guessing Tunnel Addresses ..................13 5.2. Profiling Targets Based on Tunnel Address .................14 6. Additional Security Concerns ...................................15 6.1. Attacks Facilitated by Changing Tunnel Server Setting .....15 7. Mechanisms to Secure the Use of Tunnels ........................17 8. Acknowledgments ................................................18 9. Security Considerations ........................................18 10. Informative References ........................................18
RFC4380], Layer Two Tunneling Protocol Version 2 (L2TPv2) [RFC2661], and Layer Two Tunneling Protocol Version 3 (L2TPv3) [RFC3931] all tunnel IP packets over UDP. Similarly, many Secure Socket Layer (SSL) VPN solutions that tunnel IP packets over HTTP (and hence over TCP) are deployed today. This document discusses security concerns with tunneling IP packets and includes recommendations where relevant. The primary intent of this document is to help improve security deployments using tunnel protocols. In addition, the document aims to provide information that can be used in any new or updated tunnel protocol specification. The intended audience of this document includes network administrators and future protocol developers.
One way to cut down on this lag is for security developers to follow the progress of new IETF protocols, but this will still not account for any new proprietary protocols. For example, for L2TP or Teredo, an unaware network security device would inspect or regulate the outer IP and the IP-based UDP layer as normal, but it would not recognize that there is an additional IP layer contained inside the UDP payload to which it needs to apply the same controls as it would to a native packet. (Of course, if the device discards the packet due to something in the IP or UDP header, such as referring to an unknown protocol, the embedded packet is no longer a concern.) In addition, if the tunnel does encryption, the network-based security device may not be able to do much, just as if IPsec end-to-end encryption were used without tunneling. Network security controls not being applied must be a concern to those that set them up, since those controls are supposed to provide an additional layer of defense against external attackers. If network controls are being bypassed due to the use of tunneling, the strength of the defense (i.e., the number of layers of defense) is reduced. Since security administrators may have a significantly reduced level of confidence without this layer, this becomes a concern to them. One implication of the security control bypass is that defense in depth has been reduced, perhaps down to zero unless a local firewall is in use as recommended in [RFC4380]. However, even if there are host-based security controls that recognize tunnels and all controls that were maintained by the network are available on the host, security administrators may not have configured them with full security control parity. Thus, there may be gaps in desired coverage. Compounding this is that, unlike what would be the case for native IP, some network administrators will not even be aware that their hosts are globally reachable if the tunnel provides connectivity to/from the Internet; for example, they may not be expecting this for hosts behind a stateful firewall. In addition, Section 3.2 discusses how it may not be efficient to find all tunneled traffic for network devices to examine.
easy to disable on the host and through a central management facility if one is provided. To minimize security exposure due to tunnels, we recommend that a tunnel be an interface of last resort, independent of IP version. Specifically, we suggest that when both native and tunneled access to a remote host is available, the native access be used in preference to tunneled access except when the tunnel endpoint is known to not bypass security (e.g., an IPsec tunnel to a gateway provided by the security administrator of the network). This should also promote greater efficiency and reliability. Note that although Rule 7 of [RFC3484], Section 6 will prefer native connectivity over tunnels, this rule is only a tie-breaker when a choice is not made by earlier rules; hence, tunneling mechanisms that are tied to a particular range of IP address space will be decided based on the prefix precedence. For example, using the prefix policy mechanism of [RFC3484], Section 2.1, Teredo might have a precedence of 5 so that native IPv4 is preferred over Teredo. Section 2.1, but is illustrative.
Implementations of protocols that embed an IPv4 address in a tunneled IPv6 address directly between peers should perform filtering based on checking the correspondence. Implementations of protocols that accept tunneled packets directly from a server, relay, or protocol peer do filtering the same way as it would be done on a native link with traffic from a router. Some protocols such as 6to4 [RFC3056], Teredo, and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] allow both other hosts and a router over a common tunnel. To perform host-based filtering with such protocols, a host would need to know the outer IP address of each router from which it could receive traffic, so that packets from hosts beyond the router will be accepted even though the source address would not embed the router's IP address. Router addresses might be learned via SEcure Neighbor Discovery (SEND) [RFC3971] or some other mechanism (e.g., [RFC5214], Section 8.3.2). RFC5095] and [SECA-IP]. RFC5095] and [SECA-IP], though they may also allow the user to configure what source-routing types are allowed. All pre-existing source-routing controls should be upgraded to apply these controls to tunneled IP packets as well.
Section 3.2). However, this presents difficulties in terms of efficiency of filtering, as is discussed in Section 3.2.
RFC3056] is a tunneling mechanism that uses IPv4 packets to carry encapsulated IPv6 packets and can be identified by the IPv4 protocol type 41.
One heuristic that can be used on packets to determine if they are tunnel-related or not is as follows. For each known tunnel protocol, attempt parsing the packet as if it were a packet of that protocol destined to the local host (i.e., where the local host has the destination address in the inner IP header, if any). If all syntax checks pass, up to and including the inner IP header (if the tunnel does not use encryption), then treat the packet as if it were a tunneled packet of that protocol. It is possible that non-tunneled packets will be treated as if they were tunneled packets using this heuristic, but tunneled packets (of the known types of tunnels) should not escape inspection, absent implementation bugs. For some protocols, it may be possible to monitor setup exchanges to know to expect that data will be exchanged on certain ports later. (Note that this does not necessarily apply to Teredo, for example, since communicating with another Teredo client behind a cone NAT [RFC5389] device does not require such signaling. In such cases this control will not work. However, deprecation of the cone bit as discussed in [RFC5991] means this technique may indeed work with updated Teredo implementations.) RFC2529]) that encapsulates data packets between hosts and a router within the network.
If the tunnel allows inbound access only from a private network (e.g., a remote network to which one has VPNed), the opening created in the NAT device still increases its attack surface area, although not as much as in the public Internet case. RFC4380], Section 7.1 recommends that an IPv6 host firewall be used on all Teredo clients.) (By the virtue of the tunnel being active, we can infer that the inner host firewall is unlikely to do any filtering based on the outer IP.) Any of this processing may expose vulnerabilities an attacker can exploit; similarly, these may expose information to an attacker. Thus, even if firewall filtering is in place (as is prudent) and filters all incoming packets, the exposed area is larger than if a native IP Internet connection were in place, due to the processing that takes place before the inner IP is reached (specifically, the UDP/TCP processing, the tunnel client processing, and additional IP processing, especially if one is IPv4 and the other is IPv6).
One possibility is that a layer 3 (L3) targeted worm makes use of a vulnerability in the exposed processing. The main benefit tunneling provides to worms is enabling L3 reachability to the end host. Even a thoroughly firewalled host could be subject to a worm that spreads with a single UDP packet if the right remote code vulnerability is present.
address is still known to peers, routers, etc., and can still be reached by attackers without their knowing the external IP address or port. 3. Sending packets over a tunnel often results in more message exchanges due to the tunneling protocol, as well as messages being seen by more parties (e.g., due to a longer path length), than sending packets natively, offering more chances for visibility into the port and address in use. Section 4.1 seems to apply here as well: minimize tunnel use. RFC4787] limit the source of incoming packets to just those that are a previous destination. This poses a problem for tunnels that intend to allow inbound connectivity from the Internet. Various protocols (e.g., Teredo, Session Traversal Utilities for NAT (STUN) [RFC5389], etc.) provide a facility for peers, upon request, to become a previous destination. This works by sending a "bubble" packet via a server, which is passed to the client and then sent by the client (through the NAT) to the originator. This removes any NAT-based barrier to attackers sending packets in through the client's service port. In particular, an attacker would no longer need to either be an actual previous destination or forge its addresses as a previous destination. When forging, the attacker would have had to learn of a previous destination and then would face more challenges in seeing any returned traffic.
Section 4.1.3) would lower the attack opportunity related to this exposure.
number assignment behaviors. In addition, the same observations would apply to use of UDP or TCP over native IP as well; hence, this is not new with tunneling. The platform, tunnel client software, or organization information can be used by an attacker to target attacks more carefully. For example, an attacker may decide to attack an address only if it is likely to be associated with a particular platform or tunnel client software with a known vulnerability. (This is similar to the ability to guess some platforms based on the Organizationally Unique Identifier (OUI) in the Extended Unique Identifier (EUI)-64 portion of an IPv6 address generated from a Media Access Control (MAC) address, since some platforms are commonly used with interface cards from particular vendors.) RFC6056]. It is recommended that tunnel protocols minimize the propagation of knowledge about whether the NAT is a cone NAT.
advertisers, competitors, spouses, etc.), then sensitive information would be disclosed, especially if the client's host prefers the tunnel over native IP. Assuming the server provides good service, the user would not have reason to suspect the change. Full interception of IP traffic could also be arranged (including pharming), which would allow any number of deception or monitoring attacks, including phishing. We illustrate this with an example phishing attack scenario. It is often assumed that the tunnel server is a trusted entity. It may be possible for malware or a malicious user to quietly change the client's tunnel server setting and have the user be unaware that their trust has been misplaced for an indefinite period of time. However, malware or a malicious user can do much worse than this, so this is not a significant concern. Hence, it is only important that an attacker on the network cannot change the client's server setting. 1. A phisher sets up a malicious tunnel server (or tampers with a legitimate one). This server, for the most part, provides correct service. 2. An attacker, by some means, switches the host's tunnel server setting or spoofs a DNS reply to point to the above server. If neither DNS nor the tunnel setup is secured (i.e., if the client does not authenticate the information), then the attacker's tunnel server is seen as legitimate. 3. A user on the victim host types their bank's URL into his/her browser. 4. The bank's hostname resolves to one or more IP addresses, and the tunnel is selected for socket connection for whatever reason (e.g., the tunnel provides IPv6 connectivity, and the bank has an IPv6 address). 5. The tunnel client uses the server for help in connecting to the bank's IP address. Some tunneling protocols use a separate channel for signaling versus data, but this still allows the server to place itself in the data path by an appropriate signal to the client. For example, in Teredo, the client sends a ping request through a server, which is expected to come back through a data relay, and a malicious server can simply send it back itself to indicate that is a data relay for the communication.
6. The rest works pretty much like any normal phishing transaction, except that the attacker acts as a tunnel server (or data relay, for protocols such as Teredo) and a host with the bank's IP address. This pharming-type attack is not unique to tunneling. Switching DNS server settings to a malicious DNS server or DNS cache poisoning in a recursive DNS resolver could have a similar effect. RFC3971] to verify that the client trusts the server. On the host, it should require an appropriate level of privilege in order to change the tunnel server setting (as well as other non- tunnel-specific settings such as the DNS server setting, etc.). Making it easy to see the current tunnel server setting (e.g., not requiring privilege for this) should help detection of changes. The scope of the attack can also be reduced by limiting tunneling use in general but especially in preferring native IPv4 to tunneled IPv6 when connecting to peers who are accessible over IPv4, as doing so helps mitigate attacks that are facilitated by changing the tunnel server setting. Please refer to Section 3 of [TUNNEL-LOOPS] for a detailed description and mitigation measures for a class of attacks based on IPv6 automatic tunnels.
o Operating on-premise tunnel servers/relays so that the tunneled traffic does not cross border routers. o Setting up internal routing to steer traffic to these servers/ relays o Setting up of firewalls [RFC2979] to allow known and controllable tunneling mechanisms and disallow unknown tunnels. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo Security Updates", RFC 5991, September 2010. [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, January 2011. [SECA-IP] Gont, F., "Security Assessment of the Internet Protocol version 4", Work in Progress, April 2011. [TUNNEL-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, March 2011.