RFC 6169

Security Concerns with IP Tunneling

📅 published April 2011, from ietf

Security Concerns with IP Tunneling 🎀

  • RFC: 6169
  • Title: Security Concerns with IP Tunneling
  • Authors: S. Krishnan (Ericsson), D. Thaler (Microsoft), J. Hoagland (Symantec)
  • Category: Informational
  • ISSN: 2070-1721
  • Date: April 2011
  • Obsoletes / Updates: the title block doesn't list any 💅

Published by the Internet Engineering Task Force (IETF) 🌈

Abstract ✨

Bestie, this memo is all about the security concerns that come with IP tunnels 🦋 The people it's written for are network administrators and whoever is building future protocols. The main goal is to make everyone more aware of the security problems that show up when tunnels are actually deployed, and to suggest ways to deal with them 🫶

Status of This Memo 🌸

This one is not an Internet Standards Track specification. It's published for informational purposes, so no, it's not a standard 🙈

It is still an IETF product 💖 It reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Being approved by the IESG doesn't automatically make a document a candidate for any level of Internet Standard, though. Section 2 of RFC 5741 has the details.

Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6169 🧚

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) as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, 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. The one exception is formatting it for publication as an RFC or translating it into languages other than English 🍓

Table of Contents 📖

   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

1. Introduction 🦋

NAT devices are everywhere now, so there's been a whole wave of new tunneling protocols that get through NAT devices or firewalls by tunneling over UDP or TCP. Some examples are Teredo [RFC4380], Layer Two Tunneling Protocol Version 2 (L2TPv2) [RFC2661], and Layer Two Tunneling Protocol Version 3 (L2TPv3) [RFC3931]. All three tunnel IP packets over UDP. Then there are the Secure Socket Layer (SSL) VPN solutions that tunnel IP packets over HTTP (and so over TCP), which are deployed all over the place today 💅

This document talks about the security concerns that come with tunneling IP packets, and it includes recommendations wherever they make sense ✨

The main point is to help make security deployments that use tunnel protocols better 🫶 The document also aims to give information that any new or updated tunnel protocol specification can use. Its intended audience is network administrators and future protocol developers 💖

2. Tunnels May Bypass Security 🙈

2.1. Network Security Bypass 🔥

2.1.1. Problem

Tunneled IP traffic may not get the level of inspection or policy application it was supposed to get from network-based security devices, unless those devices are specifically tunnel aware. That weakens defense in depth and can open up security gaps 😭 This affects every network-located device, and also any end-host-based firewall whose existing hooking mechanisms wouldn't show it the IP packet stream after the tunnel client decapsulates it or before it encapsulates it.

2.1.2. Discussion

Evasion by tunneling is a real headache for network-based security devices like network firewalls, intrusion detection and prevention systems, and router controls 💀 To handle tunnels, the developers of those devices have to add support for parsing each new protocol. There's usually a big lag between the moment a security developer realizes a tunnel will be used (or will be remotely usable) to a significant degree, and the moment parsing can actually land in a product update, get tested and released, and get used by customers 🍓 Late changes to the protocol specification, or to the way it gets implemented, can add even more delay. This turns into a serious security concern when the delay in coverage keeps happening over and over 😤

One way to shrink that lag is for security developers to keep an eye on new IETF protocols. Even so, this still won't cover any new proprietary protocols 🌈

For example, with L2TP or Teredo, an unaware network security device would inspect or regulate the outer IP and the IP-based UDP layer like normal. But it wouldn't realize there's an extra IP layer inside the UDP payload that it needs to apply the same controls to as it would to a native packet. (Of course, if the device throws the packet away because of something in the IP or UDP header, such as a reference to an unknown protocol, then the embedded packet isn't a concern anymore 🧚) On top of that, if the tunnel does encryption, the network-based security device may not be able to do much, just like what happens with IPsec end-to-end encryption when there's no tunneling 💜

Network security controls that aren't being applied should be a big deal for the people who set them up, since those controls exist to be an extra layer of defense against external attackers 👑 If tunneling gets those controls bypassed, the strength of the defense (meaning the number of layers) goes down. Security administrators might feel a lot less confident without that layer, and that's a worry for them too 😬

One result of the security control bypass is that defense in depth may have been reduced, possibly all the way to zero, unless a local firewall is in use as recommended in [RFC4380]. Even when there are host-based security controls that recognize tunnels, and every control the network used to maintain is available on the host, security administrators may not have set them up with full security control parity. So there may still be gaps in the coverage they want 🫠

It gets worse. Unlike native IP, some network administrators won't even know their hosts are globally reachable if the tunnel gives connectivity to or from the Internet. For example, they might not be expecting that for hosts sitting behind a stateful firewall 🙈 Also, Section 3.2 explains how it may not be efficient to find all the tunneled traffic for network devices to examine 🎀

2.1.3. Recommendations

Security administrators who don't think tunneling is an acceptable risk should turn off tunnel functionality, either on the end nodes (hosts) or on the network nodes at the edge of their network 🛑 But there might be an awareness gap. So, because of the possible negative security consequences, tunneling functionality should be easy to disable on the host, and through a central management facility if one is provided 💖

To keep security exposure from tunnels low, we recommend that a tunnel be an interface of last resort, no matter the IP version 🦋 More specifically, we suggest that when both native and tunneled access to a remote host are available, native access be used over tunneled access. The exception is when the tunnel endpoint is known not to bypass security, such as an IPsec tunnel to a gateway provided by the network's security administrator. This should also make things more efficient and more reliable ✨

Heads up, though: Rule 7 of [RFC3484], Section 6 will prefer native connectivity over tunnels. That rule is only a tie-breaker, used when earlier rules haven't made a choice. So tunneling mechanisms that are tied to a particular range of IP address space will be decided by prefix precedence instead 🌸 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 🧚

2.2. IP Ingress and Egress Filtering Bypass 💅

2.2.1. Problem

IP addresses inside tunnels don't get ingress and egress filtering in the network they tunnel over, unless someone goes to extraordinary lengths. Only the tunnel endpoints can do that filtering 🔥

2.2.2. Discussion ✨

okay so ingress filtering (sanity-checking incoming destination addresses) and egress filtering (sanity-checking outgoing source addresses) exist to mitigate attacks and make it easier to figure out where a packet actually came from 🕵️‍♀️ and they're considered a good practice, no cap. 💅 For example, ingress filtering at the network perimeter should not allow packets with a source address that belongs to the network to enter the network from outside the network. 🙅‍♀️ This job is most naturally (and in the general case, by requirement) done at network boundaries 🧱. Tunneled IP traffic sneaking past this network control is a specific case of Section 2.1, but it's a super illustrative one 🎀.

2.2.3. Recommendations 🌸

tunnel servers can apply ingress and egress controls to the tunneled IP addresses passing through them, going to and coming from tunnel clients 🚪

tunnel clients could make an effort to do ingress and egress filtering too 🫶

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 it would be done on a native link with traffic from a router 🛣️

okay this one is giving main character energy 👑. some protocols like 6to4 [RFC3056], Teredo, and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] let both other hosts and a router talk over a common tunnel 🧚. so to do host-based filtering with these, a host would need to know the outer IP address of each router it could receive traffic from 🗺️. that way packets from hosts beyond the router get accepted even though their source address wouldn't embed the router's IP 🫧. router addresses might be learned via SEcure Neighbor Discovery (SEND) [RFC3971] or some other mechanism (e.g., [RFC5214], Section 8.3.2) 💜

2.3. Source Routing after the Tunnel Client 🦋

2.3.1. Problem 😭

if the encapsulated IP packet specifies source routing beyond the recipient tunnel client, the host may forward the IP packet to the specified next hop 🫠. this may be unexpected and contrary to administrator wishes, and it may have bypassed network-based source-routing controls 💀. not it!!

2.3.2. Discussion 📚

a detailed discussion of issues related to source routing can be found in [RFC5095] and [SECA-IP] 🤓

2.3.3. Recommendations 💅

tunnel clients should by default discard tunneled IP packets that specify additional routing, as recommended in [RFC5095] and [SECA-IP] 🙌. they may also allow the user to configure which source-routing types are allowed, which is a nice little bonus 🎀. all pre-existing source-routing controls should be upgraded to apply these controls to tunneled IP packets as well 🔐

3. Challenges in Inspecting and Filtering Content of Tunneled Data Packets 🧁

3.1. Inefficiency of Selective Network Filtering of All Tunneled Packets 🍓

3.1.1. Problem 🙈

there is no mechanism that both efficiently and immediately filters all tunneled packets (other than the obviously faulty method of filtering all packets) 😤. this limits the ability to prevent tunnel use on a network 🚫

3.1.2. Discussion 🧠

okay so, given concerns about tunnel security or a network's lack of preparedness for tunnels, a network administrator may wish to simply block all use of tunnels that bypass security policies 🛑. they may want to do this using network controls, and that could be either because they can't disable tunneling on every host attached to the network, or because they want an extra layer of prevention 🫶. he or she, whoever's in charge, lol 🧑‍💻

one simple way to do this easily for many tunnel protocols is to block outbound packets to the UDP or TCP port the tunnel uses (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for L2TP, etc.) 🚧. this stops a tunnel client from setting up a new tunnel 🙅‍♀️. however, existing tunnels won't necessarily be affected if the blocked port is only used for initial setup 🤷‍♀️. and if the blocking is applied on the outside of the client's NAT device, the NAT device will keep the port mapping for the client 😬. in some cases, though, blocking all traffic to a given outbound port (e.g., port 80) may mess with non-tunneled traffic too, so this should be used with caution ⚠️

⚠️ blocking a common port like 80 can break regular, totally innocent traffic. use with caution, bestie!

another simple alternative, if the tunnel server addresses are well-known, is to filter out all traffic to and from those addresses 🎯

the other approach is to find all packets to block in the same way you'd do for inspecting all packets (Section 3.2) 🔎. however, this gets kinda hard in terms of filtering efficiency, as is discussed in Section 3.2 🥲

3.1.3. Recommendations 🎀

developers of protocols that tunnel over UDP or TCP (including HTTP) to reach the Internet should disable their protocols in networks that want to enforce security policies on user traffic 🫡. (Windows, for example, disables Teredo by default if it detects that it's inside an enterprise network that contains a Windows domain controller 🪟.)

administrators of these networks may wish to filter all tunneled traffic at the boundaries of their networks 🧱. it's enough to filter out the tunneled connection requests (if they can be identified) to stop further tunneled traffic 🛑. the easiest mechanism for this would be to filter out outgoing traffic sent to the destination port defined by the tunneling protocol, and incoming traffic with that source port 🔐. similarly, in certain cases, you can also use the IP protocol field to identify and filter tunneled packets 🧾. for example, 6to4 [RFC3056] is a tunneling mechanism that uses IPv4 packets to carry encapsulated IPv6 packets, and it can be identified by the IPv4 protocol type 41 🌈

3.2. Problems with Deep Packet Inspection of Tunneled Data Packets 🔬

3.2.1. Problem 😵‍💫

there is no efficient mechanism for network-based devices (which are not the tunnel endpoint) to inspect the contents of all tunneled data packets the way they can for native packets 🥴. this makes it hard to apply the same controls they use on native IP 💔

3.2.2. Discussion 🕸️

some tunnel protocols are easy to identify, like when all data packets are encapsulated using a well-known UDP or TCP port that's unique to the protocol 🪪.

other protocols, though, either use dynamic ports for data traffic or share ports with other protocols (e.g., tunnels over HTTP) 🫠.

the implication? network-based devices that want to passively inspect (and maybe selectively apply policy to) all encapsulated traffic must inspect all TCP or UDP packets (or at least all packets not part of a session known not to be a tunnel) 😩. this is imperfect, because a heuristic has to be applied to figure out if a packet is actually part of a tunnel 🧩. it may be too slow to be useful in practice, especially if it means all TCP or UDP packets have to be pulled off the device's "fast path" 🏎️💨

one heuristic that can be used on packets to decide if they're tunnel-related is as follows 🧪. for each known tunnel protocol, attempt to parse 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's possible that non-tunneled packets get treated as 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 so you know to expect data on certain ports later 👀. (note that this doesn't necessarily apply to Teredo, for example, since communicating with another Teredo client behind a cone NAT [RFC5389] device doesn't require that kind of signaling 🙅‍♀️. in those cases this control won't work 💀. however, the deprecation of the cone bit, as discussed in [RFC5991], means this technique may indeed work with updated Teredo implementations ✨)

3.2.3. Recommendations 💜

as illustrated above, it should be clear that inspecting the contents of tunneled data packets is highly complex and often impractical 🥹. for this reason, if a network wants to monitor IP traffic, tunneling across the security boundary (as opposed to tunneling to it) is not recommended 🚫. for example, to provide an IPv6 transition solution, the network should provide native IPv6 connectivity, or a tunnel solution (e.g., ISATAP or 6over4 [RFC2529]) that encapsulates data packets between hosts and a router within the network 🌷

4. Increased Exposure Due to Tunneling 🌊

4.1. NAT Holes Increase Attack Surface 🕳️

4.1.1. Problem 🚨

if the tunnel allows inbound access from the public Internet, the opening created in a NAT device due to a tunnel client increases its Internet attack surface area 😱. if vulnerabilities are present, this increased exposure can be used by attackers and their programs 💀

if the tunnel allows inbound access only from a private network (e.g., a remote network you VPNed into), the opening created in the NAT device still increases its attack surface area 🥺, although not as much as in the public Internet case 💅

4.1.2. Discussion 🔍

when a tunnel is active, a mapped port is maintained on the NAT device, and remote hosts can send packets through it and perhaps establish connections 🚪✨. the following sequence is meant to sketch out the processing on the tunnel client host that can be reached through this mapped port 🗺️. the actual processing for a given host may be somewhat different 🫶

  1. Link-layer protocol processing
  2. (Outer) IP host firewall processing
  3. (Outer) IP processing by stack
  4. UDP/TCP processing by stack
  5. Tunnel client processing
  6. (Inner) IP host firewall processing
  7. (Inner) IP processing by stack
  8. Various upper layer processing may follow

the inner firewall (and other security) processing may or may not be present, but if it is, some of the inner IP processing may be filtered 🧱. (for example, [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, and 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 📈. that's because of the processing that happens 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 gives 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 😱🔥

4.1.3. Recommendation ✨

okay so the big takeaway here is that this problem is basically baked in once tunneling is active on a host 💅, which means the move is to minimize tunnel use 🫶

For example, tunneling can be active only when it's really needed, and only for as long as it's needed 🦋. So the tunnel interface can start out not configured and only get used when it's entirely the last resort 🧚. The interface should then be deactivated (ideally, automatically) again as soon as possible 💖. BUT here's the catch: the hole will stay in the NAT device for some amount of time after that, so some processing of incoming packets is inevitable unless the client's native IP address behind the NAT device is changed 😭

4.2. Exposure of a NAT Hole

4.2.1. Problem

attackers are way more likely to know about a tunnel client's NAT hole than a typical hole in the NAT device 👀. And if they know about the hole, they could try to use it 💀

4.2.2. Discussion

there are at least three reasons why an attacker may be more likely to learn about the tunnel client's exposed port than a typical NAT exposed port 🕵️‍♀️

  1. The NAT mapping for a tunnel is typically held open for a significant period of time and kept stable. This increases the chance of it being discovered.
  2. In some protocols (e.g., Teredo), the external IP address and port are contained in the client's address that is used end-to-end, and possibly even advertised in a name resolution system. While the tunnel protocol itself might only distribute this address in IP headers, peers, routers, and other on-path nodes still see the client's IP address. Although this point does not apply directly to protocols that do not construct the inner IP address based on the outer IP address (e.g., L2TP), the inner IP 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. That offers more chances for visibility into the port and address in use.

4.2.3. Recommendation

the recommendation from Section 4.1 seems to apply here as well: minimize tunnel use 🌸

4.3. Public Tunnels Widen Holes in Restricted NATs

4.3.1. Problem

tunnels that allow inbound connectivity from the Internet (e.g., Teredo, tunnel brokers, etc.) basically switch off the filtering behavior of the NAT for all tunnel client ports 🚪😱. That means NAT devices stop filtering for those ports, and an attacker may not even need to spoof an address anymore 🙈

4.3.2. Discussion

NATs that implement Address-Dependent or Address and Port-Dependent Filtering [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. The packet is passed to the client, and then the client sends it (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 🕸️

4.3.3. Recommendations

if the tunnel can provide connectivity to the Internet, the tunnel client should run a host firewall on the tunnel interface 🔥. Also, minimizing public tunnel use (see Section 4.1.3) would lower the attack opportunity related to this exposure 👑

5. Tunnel Address Concerns ✨

5.1. Feasibility of Guessing Tunnel Addresses

5.1.1. Problem

for some types of tunneling protocols, it may be feasible to guess IP addresses assigned to tunnels, either when looking for a specific client or when looking for an arbitrary client 🎯. This is in contrast to native IPv6 addresses in general, but it's no worse than for native IPv4 addresses today 🤷‍♀️

For example, some protocols (e.g., 6to4 and Teredo) use well-defined address ranges. As another example, using well-known public servers for Teredo or tunnel brokers also implies using a well-known address range 🗺️

5.1.2. Discussion

several tunnel protocols use endpoint addresses that can be algorithmically derived from some known values. These addresses are structured, and the fields contained in them can be fairly predictable 🧩. This reduces the search space for an attacker and reduces the resistance of the address to scanning attacks 😬

5.1.3. Recommendations

it is recommended that tunnel protocol developers use tunnel endpoint addresses that are not easily guessable 💅. When the tunnel endpoint addresses are structured and fairly guessable, it is recommended that the implementation use any unused fields in the address to provide additional entropy to the address, in order to reduce the address-scanning risks. For example, this could be done by setting these unused fields to some random values 🎲

5.2. Profiling Targets Based on Tunnel Address

5.2.1. Problem

an attacker who encounters an address associated with a particular tunneling protocol or well-known tunnel server gets to infer certain relevant pieces of information that can be used to profile the host before sending any packets 🕵️. This can shrink the attacker's footprint and make them more efficient 😈

5.2.2. Discussion

the tunnel address reveals some information about the nature of the client:

  • That a host has a tunnel address associated with a given protocol means that the client is running on some platform for which there exists a tunnel client implementation of that protocol. In addition, if some platforms have that protocol installed by default, and if the host's default rules for using it make it susceptible to being in use, then the protocol is more likely to be running on such a platform than on one where it is not used by default. For example, as of this writing, seeing a Teredo address suggests that the host it is on is probably running Windows 🪟
  • Similarly, the use of an address associated with a particular tunnel server also suggests some information. Tunnel client software is often deployed, installed, and/or configured using some degree of automation. It seems likely that the majority of the time, the tunnel server that results from the initial configuration will go unchanged from the initial setting. Moreover, the server that is configured for use may be associated with a particular means of installation, which often suggests the platform. For example, if the server field in a Teredo address is one of the IPv4 addresses to which teredo.ipv6.microsoft.com resolves, the host is likely running Windows 🍓
  • The external IPv4 address of a NAT device can, of course, be readily associated with a particular organization or at least an ISP. Hence, putting this address in an IPv6 address reveals this information. However, this is no different than using a native IP address, and is therefore not new with tunneling 🌈
  • It is also possible that external client port numbers may be more often associated with particular client software or the platform on which it is running. The usefulness of this for platform determination is, however, reduced by the different NAT port number assignment behaviors. In addition, the same observations would apply to use of UDP or TCP over native IP as well, so this is not new with tunneling either 🧃

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 🖨️)

5.2.3. Recommendations

if installation programs randomize the server setting, they would reduce the extent to which they can be profiled 🎰. Similarly, administrators can choose to change the default setting to reduce the degree to which they can be profiled ahead of time 🔐

Randomizing the tunnel client port in use would mitigate any profiling that can be done based on the external port, especially if multiple tunnel clients did this. Further discussion on randomizing ports can be found at [RFC6056] 🎀

it is recommended that tunnel protocols minimize the propagation of knowledge about whether the NAT is a cone NAT 🤫

6. Additional Security Concerns ⚠️

6.1. Attacks Facilitated by Changing Tunnel Server Setting

6.1.1. Problem

⚠️ this one is SERIOUS bestie 😭 If an attacker could change either a tunnel client's server setting, or the IP addresses to which a configured host name resolves (e.g., by intercepting DNS queries), AND the tunnel is not authenticated, the attacker would become a man in the middle. That would let them at least monitor peer communication, and at worst impersonate the remote peer 💀

6.1.2. Discussion 👀

okay so bestie, a client's tunnel server has really good visibility into everything the client talks to over IP peers 🫣. If someone swapped that server for one that logs all of it and sells it to third parties (advertisers, competitors, spouses, etc.), sensitive info would leak 😭, especially if the host prefers the tunnel over native IP. And if the server is doing a good job, the user has zero reason to suspect anything is off 🙈.

Full interception of IP traffic could also be set up (pharming included) 💀, which opens the door to all kinds of deception or monitoring attacks, phishing very much included. We're gonna walk through an example phishing scenario so you can see how it goes 🕵️‍♀️.

It's often assumed that the tunnel server is a trusted entity 🤝. Malware or a malicious user could quietly change the client's tunnel server setting and the user would never notice that their trust got misplaced, possibly for an indefinite period of time 😶. BUT malware or a malicious user can do way worse things than that, so this isn't a significant concern 💅. The real takeaway: it's 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 messes with a legitimate one). For the most part, this server gives correct service 🎭.
  2. An attacker, somehow, switches the host's tunnel server setting or spoofs a DNS reply to point to that server. If neither DNS nor the tunnel setup is secured (aka the client doesn't authenticate the info), the attacker's tunnel server looks totally legit 😈.
  3. A user types their bank's URL into their browser 🏦.
  4. The bank's hostname resolves to one or more IP addresses, and the tunnel gets picked for the socket connection for whatever reason (for example, the tunnel provides IPv6 connectivity and the bank has an IPv6 address) ✨.
  5. The tunnel client asks the server for help connecting to the bank's IP address. Some tunneling protocols use a separate channel for signaling versus data, but that still lets the server put itself in the data path by sending the right signal to the client 📡. Like, 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 just send it back itself to say that it's the data relay for the communication 😳.
  6. The rest goes pretty much like any normal phishing transaction, except the attacker is acting as the tunnel server (or data relay, for protocols like Teredo) AND as a host with the bank's IP address 🎀.

This pharming-type attack isn't 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 🌸.

6.1.3. Recommendations 🛡️

In general, anti-phishing and anti-fraud provisions should help with parts of this, and so should software that specifically watches for tunnel server changes 👀.

Honestly, the best way to mitigate tunnel-specific attacks is to have the client authenticate either the tunnel server or, at the very least, the means by which the tunnel server's IP address is determined 🔐. For example, SSL VPNs use https URLs and so authenticate the server as being the expected one 🧁. When IPv6 Router Advertisements are sent over the tunnel, another option is to use SEcure Neighbor Discovery (SEND) [RFC3971] to verify that the client trusts the server 🦋.

On the host, changing the tunnel server setting should require an appropriate level of privilege (same goes for other non-tunnel-specific settings like the DNS server setting, etc.) 🔑. Making it easy to see the current tunnel server setting (like, not requiring privilege to look at it) should help with detecting changes 🔍.

The scope of the attack can also be reduced by limiting tunneling use in general, but especially by preferring native IPv4 over tunneled IPv6 when connecting to peers that are reachable over IPv4 🌈. Doing so helps mitigate attacks that are facilitated by changing the tunnel server setting 💜. For a detailed description and mitigation measures for a class of attacks based on IPv6 automatic tunnels, please refer to Section 3 of [TUNNEL-LOOPS] 📚.

7. Mechanisms to Secure the Use of Tunnels 🔐

This document described several security issues with tunnels 🚨. That does NOT mean tunnels need to be avoided at all costs! Tunnels can be super useful if they're deployed, operated, and used properly 💖. The threats against IP tunnels are documented here, and if the threats can be mitigated, network administrators can use tunnels efficiently and securely in their network ✨. Here are several measures you can take to secure the operation of IPv6 tunnels:

  • Operating on-premise tunnel servers/relays so that the tunneled traffic does not cross border routers 🏢.
  • Setting up internal routing to steer traffic to these servers/relays 🧭.
  • Setting up firewalls [RFC2979] to allow known and controllable tunneling mechanisms and disallow unknown tunnels 🧱.

8. Acknowledgments 🫶

The authors would like to thank Remi Denis-Courmont, Fred Templin, Jordi Palet Martinez, James Woodyatt, Christian Huitema, Brian Carpenter, Nathan Ward, Kurt Zeilenga, Joel Halpern, Erik Kline, Alfred Hoenes, and Fernando Gont for reviewing earlier versions of the document and giving comments to make it better 💕.

9. Security Considerations 🛡️

This entire document discusses security concerns with tunnels 😤.

10. Informative References 📚

[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.

Authors' Addresses 💌

Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada

Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com


Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052
USA

Phone: +1 425 703 8835
EMail: dthaler@microsoft.com


James Hoagland
Symantec Corporation
350 Ellis St.
Mountain View, CA  94043
USA

EMail: Jim_Hoagland@symantec.com
URI:   http://symantec.com/
📦 where this page comes from