IPv6 Operations Working Group                                J. Hoagland
Internet-Draft                                                  Symantec
Expires: January 8, 2009
Intended status: Informational                               S. Krishnan
Expires: April 17, 2009                                         Ericsson
                                                               D. Thaler
                                                            July 7,
                                                        October 14, 2008

                  Security Concerns With IP Tunneling

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 8, April 17, 2009.


   A number of security concerns with IP tunnels are documented. documented in this
   document.  The intended audience of this document includes network
   administrators and future protocol developers.  The primary intent of
   this document is to raise the awareness regarding the security issues
   with IP tunnels as deployed today.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   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  . . . . . . . . . . . . . . . . . . . 12
     5.1.  Feasibility of Guessing Tunnel Addresses . . . . . . . . . 12
     5.2.  Profiling Targets Based on Tunnel Address  . . . . . . . . 13
   6.  Additional Security Concerns . . . . . . . . . . . . . . . . . 14 15
     6.1.  Attacks Facilitated By Changing Tunnel Server Setting  . . 15
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. Informative References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20

1.  Introduction

   With NATs NAT devices becoming increasingly more prevalent, there have
   recently been many tunneling protocols developed that go through NATs NAT
   devices or firewalls by tunneling over UDP or TCP.  For example,
   Teredo [RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel
   IP packets over UDP.  Similarly, many 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 provide information that
   can be used in any new or updated tunnel protocol specification.
   Secondarily, this document can help improve security deployments
   using tunnel protocols.  The intended audience of this document
   includes 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 receive the intended level of inspection
   or policy application by network-based security devices unless such
   devices are specifically tunnel-aware.  This reduces defense in depth
   and may cause security gaps.  This applies to all network-located
   devices and to any end-host based firewalls whose existing hooking
   mechanism(s) would not show them the IP packet stream after the
   tunnel client does decapsulation.

2.1.2.  Discussion

   Evasion by tunneling is often a problem for network-based security
   devices such as network firewalls, intrusion detection and prevention
   systems, and router controls.  To provide such functionality in the
   presence of tunnels, the developer of such devices must add support
   for detunneling for each new protocol.  There is typically a
   significant lag between when the security developer recognizes that a
   tunnel will be used (or will be remotely usable) to a significant
   degree and when the detunneling can be implemented in a product
   update, the update tested and released, and customers begin using the
   update.  Late changes in the protocol specification or in the way it
   is implemented can cause additional delays.  This becomes a
   significant security concern when a delay in applied coverage is
   occurring frequently.

   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 that 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 being not applied must be a concern to
   those that set them up, since those controls are supposed to
   adequately regulate all traffic.  If network controls are being
   bypassed due to the use of tunneling, the burden of controls shifts
   to the tunnel client host.  Since security administrators may not
   have full control over all the nodes on their network, they sometimes
   prefer to implement security controls on the network.

   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,
   security administrators may not have configured them with full
   security control parity, even if all controls that were maintained by
   the network are available on the host.  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 with [RFC1918] addresses behind a NAT. NAT device.  In addition,
   Section 3.2 discusses how it may not be efficient to find all
   tunneled traffic for network devices to examine.

2.1.3.  Recommendations

   Security administrators who do not consider tunneling an acceptable
   risk should disable tunnel functionality unless their network-based
   security controls adequately recognize either on the tunneled traffic. end-nodes
   (hosts) or on the network nodes.  However, there may be an awareness
   gap.  Thus, due to the possible negative security consequences, we
   recommend that explicit user action be required to enable tunneling,
   at least for the first time.

   For example, when Teredo is being enabled or when it is going to be
   used for the first time, there could be a descriptive warning about
   the possible reduction of defense in depth that will occur.  In
   addition, Teredo client functionality should be easy to disable on
   the host and through a central management facility if one is
   provided.  (We could find no pre-existing mechanism for tunneling
   protocols to use that could automate their functionality being
   disabled unless all network-based security controls were aware of it.
   A separate type of consent request packet would be needed.)

   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, that the native-based native access be used in
   preference to tunneled access. 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.

2.2.  IP Ingress and Egress Filtering Bypass

2.2.1.  Problem

   IP addresses inside tunnels are not subject to ingress and egress
   filtering in the network they tunnel over, unless extraordinary
   measures are taken.  Only the tunnel endpoints can do such filtering.

2.2.2.  Discussion

   Ingress filtering (sanity-checking incoming destination addresses)
   and egress filtering (sanity-checking outgoing source addresses) are
   done to mitigate attacks and to make it easier to identify the source
   of a packet and are considered to be a good practice.  This is most
   naturally (and in the general case, by requirement) done at network
   boundaries.  Tunneled IP traffic bypassing this network control is a
   specific case of Section 2.1, but is illustrative.

2.2.3.  Recommendations

   The recommendations in Section 2.1.3 can help here.  For this problem
   specifically, there are three locations in which ingress and egress
   filtering can be done.

   Network based:  Network-based devices (e.g., routers) could be
      updated to find all tunneled packets and to apply ingress and
      egress controls equally to tunneled IP addresses.

   Tunnel server based:  Tunnel servers can apply ingress and egress
      controls to tunneled IP addresses passing through them to and from
      tunnel clients.

   Host based:  Tunnel clients could make an effort to conduct ingress
      and egress filtering.


      Implementations of protocols that embed an IPv4 address in a
      tunneled IPv6 address directly between peers often do filtering
      based on checking the

      Protocols correspondence.

      Implementations of protocols that accept tunneled packets directly
      from a server or relay do filtering the same way as it would be
      done on a native link with traffic from a router.

      To do host-based filtering with

      Some protocols that such as 6to4 [RFC3056], Teredo, ISATAP [RFC5214],
      and 6over4 [RFC2529] allow both other hosts and a router over a
      common tunnel (e.g., 6to4 [RFC3056],
      Teredo, ISATAP [RFC4214], and 6over4 [RFC2529]), hosts To perform host-based filtering with such protocols
      a host would need to be able to know the outer IP address of all routers each router from
      which it could receive traffic.  This 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.,
      [RFC4214] [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 may have bypassed network-based source
   routing controls.

2.3.2.  Discussion

   A detailed discussion of issues related to source routing can be
   found in [RFC5095].

2.3.3.  Recommendations

   Tunnel clients should by default discard tunneled IP packets that
   specify additional routing, as recommended in [RFC5095], 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.

3.  Challenges in Inspecting and Filtering Content of Tunneled Data

3.1.  Inefficiency of Selective Network Filtering of All Tunneled

3.1.1.  Problem

   There is no mechanism to both efficiently and immediately filter all
   tunneled packets.  This limits the ability to prevent tunnel use on a

3.1.2.  Discussion

   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. tunnels that subvert security.  He or she may wish
   to do so using network controls; this could be either due to not
   having confidence in the ability to disable it on all hosts attached
   to the network or due to wanting an extra layer of prevention.

   One simple method to do that is easy to employ for many tunnel
   protocols is to block outbound packets to the UDP or TCP port used
   (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for
   L2TP, etc.).  This prevents a tunnel client from establishing a new
   tunnel.  However, existing tunnels will not necessarily be affected
   if the blocked port is used only for initial setup.  In addition, if
   the blocking is applied on the outside of the client's NAT, NAT device,
   the NAT device will retain the port mapping for the client and the
   client may or may not continue to use the IP address assigned to its
   tunnel.  It is not known if  In some cases, however, blocking all traffic to a given
   outbound port will (e.g., port 80) may interfere with non-tunneled traffic. traffic
   so this should be used with caution.

   Another simple alternative, if the tunnel server addresses are well-
   known, is to filter out all traffic to/from such addresses.

   The other approach is to find all packets to block in the same way as
   would be done for inspecting all packets (Section 3.2).  However,
   this faces the difficulties in terms of efficiency of filtering as
   was present there.

3.1.3.  Recommendations

   Tunneling over UDP or TCP (including HTTP) to reach the Internet is
   not recommended as a solution for managed networks. networks that wish to enforce
   security polcies on the user traffic.  (Windows, for example,
   disables Teredo by default if it detects that it is within an
   enterprise network that contains a
   managed network.) Windows domain controller.)

   Administrators of such networks may wish to filter all tunneled
   traffic at the boundaries of their networks.  It is sufficient 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.

3.2.  Problems with deep packet inspection of tunneled data packets

3.2.1.  Problem

   There is no efficient mechanism for network-based devices to inspect
   the contents of all tunneled data packets, the way they can for
   native packets.  This makes it difficult to apply the same controls
   as they do to native IP.

3.2.2.  Discussion

   Some tunnel protocols are easy to identify, such as if all data
   packets are encapsulated using a well-known UDP or TCP port that is
   unique to the protocol.

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

   The implication of this is that network-based devices that wish to
   passively inspect (and perhaps selectively apply policy to) all
   encapsulated traffic must inspect all TCP or UDP packets (or at least
   all packets not part of a session that is known not to be a tunnel).
   This is imperfect since a heuristic must then be applied to determine
   if a packet is indeed part of a tunnel.  This may be too slow to make
   use of in practice, especially if it means that all TCP or UDP
   packets must be taken off of the device's "fast path".

   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
   doesn't use encryption), then treat the packet as if it is a tunneled
   packet of that protocol.

   It is possible that non-tunnel packets will match as tunneled 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
   device does not require such signaling.  However, deprecation of the
   cone bit as discussed in [RFC4380] means this technique may indeed
   work with Teredo.)

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 wishes to monitor IP traffic, tunneling
   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) 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 to which one has VPN'ed), 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 through which remote hosts can send packets and perhaps
   establish connections.  The following sequence is intended to sketch
   out the processing on the tunnel client host that can be reached
   through this; the actual processing for a given host may be somewhat

   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
   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 targeted worm makes use of a
   vulnerability in the exposed processing.  While the main benefit to
   worms from tunneling is targeting at layer 3 reaching the end host,
   even a throughly 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.  Recommendations

   This problem seems inherent in tunneling being active on a host, so
   the solution seems to be to minimize tunneling use.

   For example, it can be active only when it is really needed and only
   for as long as needed.  So, the tunnel interface can be initially not
   configured and only used when it is entirely the last resort.  The
   interface should then be deactivated (ideally, automatically) again
   as soon as possible.  Note however that the hole will remain in the
   NAT device for some amount of time after this, 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 more likely to know about a tunnel client's NAT hole
   than a typical hole in the NAT. NAT device.  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 of 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 (e.g., L2TP) that do not construct
       the inner IP address based on the outer IP address, the inner IP
       address is still known to peers, routers, etc. and can still be
       reached by attackers without knowing the external IP address or

   3.  The tunnel protocol contains more messages that are exchanged and
       with more parties (e.g., due to a longer path length) than
       without using the tunnel, offering more chance for visibility
       into the port and address in use.

4.2.3.  Recommendations

   The recommendations from Section 4.1 seem 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) essentially turn a restricted or
   symmetric NAT into an unrestricted one, for all tunnel client ports.
   This eliminates NAT devices filtering for such ports and may
   eliminate the need for an attacker to spoof an address.

4.3.2.  Discussion

   Restricted, port restricted, and symmetric NATs NAT devices [RFC3489]
   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, STUN [RFC3489], 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

   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 to
   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

   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 is 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

5.2.  Profiling Targets Based on Tunnel Address

5.2.1.  Problem

   An attacker encountering an address associated with a particular
   tunneling protocol or well-known tunnel server has the opportunity to
   infer certain relevant pieces of information that can be used to
   profile the host before sending any packets.  This can reduce the
   attacker's footprint and increase the attacker's efficiency.

5.2.2.  Discussion

   The tunnel address reveals some information about the nature of the

   o  That a host has a tunnel address associated with a given proocol
      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 where the host's default rules for using it make it
      susceptible to being in use, then it 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 running Windows Vista.

   o  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 addressees to which teredo.ipv6.microsoft.com
      resolves, it suggests that the host is running Windows.

   o  The external IPv4 address of a NAT device can of course be readily
      associated with a particular organization or at least an ISP, and
      hence putting this address in an IPv6 address reveals this
      information.  However, this is no different than using a native IP
      address, and hence is not new with tunneling.

   o  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, and 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 OUI in the EUI-64 portion of an
   IPv6 address generated from a MAC address, since some platforms are
   commonly used with interface cards from particular vendors.)

   In Teredo as defined in [RFC4380], the cone bit tells the attacker
   whether a bubble is needed to proceed a connection.  It may also have
   some value in terms of profiling to the extent that it reveals the
   security posture of the network.  If the cone bit is set, the
   attacker may decide it is fruitful to port scan the embedded external
   IPv4 address and others associated with the same organization,
   looking for open ports.  As such, this cone bit is deprecated in
   Windows Vista.

5.2.3.  Recommendations

   If installation programs randomized the server setting, that 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 different Teredo clients did this.  Further discussion on
   randomizing ports can be found at

   It is recommended that tunnel protocols minimize the propagation
   knowledge about whether the NAT is a cone NAT.  For example, the cone
   bit for Teredo should be deprecated.

6.  Additional Security Concerns

6.1.  Attacks Facilitated By Changing Tunnel Server Setting

6.1.1.  Problem

   If an attacker could either change a tunnel client's server setting
   or change the IP addresses to which a configured host name resolves
   (e.g., by intercepting DNS queries), this would allow them to become
   a man-in-the-middle at least monitor peer communication and at worst
   pretend to represent the remote peer.

6.1.2.  Discussion

   A client's server has good visibility into the client's communication
   with IP peers.  If the server were switched to one that records this
   information and makes it available to third parties (e.g.,
   advertisers, competitors, spouses, etc.) then sensitive information
   is being 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
   Teredo client's server setting and have the user be unaware 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 and 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

   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
       the bank's IP address.  Some tunneling protocols use a separate
       channel for signaling vs 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

   This pharming type attack is not unique to tunneling.  Switching DNS
   server settings to a malicious DNS server could have similar effect.

6.1.3.  Recommendations

   In general, anti-phishing and anti-fraud provisions should help with
   aspects of this, as well as software that specifically monitors for
   tunnel server changes.

   Perhaps the best way to mitigate tunnel-specific attacks is to have
   the client either authenticate the tunnel server, or at least the
   means by which the tunnel server's IP address is determined.  For
   example, SSL VPNs use https URLs and hence authenticate the server as
   being the expected one.  Another mechanism, when IPv6 Router
   Advertisements are sent over the tunnel (e.g., in Teredo), is to use
   SEcure Neighbor Discovery (SEND) to verify that the client trusts the

   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;
   this is because it is reasonable to expect that banks and similar web
   sites will continue to be accessible over IPv4 for as long as a
   significant fraction of their customers are still IPv4-only.

7.  Acknowledgments

   The authors would like to thank Remi Denis-Courmont, Fred Templin,
   Jordi Palet Martinez, James Woodyatt and Woodyatt, Christian Huitema and Kurt
   Zeilenga for reviewing earlier versions of the document and providing
   comments to make this document better.  The authors would also like
   to thank Alfred Hines for a careful review of the document.

8.  Security Considerations

   This entire document discusses security concerns with tunnels.

9.  IANA Considerations

   There are no actions for IANA in this document.

10.  Informative References

10.1.  Normative References

              Larsen, M. and F. Gont, "Port Randomization",
              draft-ietf-tsvwg-port-randomization-02 (work in progress),
              August 2008.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

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

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

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4214]  Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
              "Intra-Site Automatic Tunnel Addressing Protocol
              (ISATAP)", RFC 4214, October 2005.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095,
              December 2007.

10.2.  Informative References

              Larsen, M.

   [RFC5214]  Templin, F., Gleeson, T., and F. Gont, "Port Randomization",
              draft-ietf-tsvwg-port-randomization-01 (work in progress),
              February D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

Authors' Addresses

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

   Email: Jim_Hoagland@symantec.com
   URI:   http://symantec.com/

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

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com
   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052

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

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at