draft-ietf-v6ops-tunnel-security-concerns-00.txt   draft-ietf-v6ops-tunnel-security-concerns-01.txt 
IPv6 Operations Working Group J. Hoagland IPv6 Operations Working Group J. Hoagland
Internet-Draft Symantec Internet-Draft Symantec
Expires: January 8, 2009 S. Krishnan Intended status: Informational S. Krishnan
Ericsson Expires: April 17, 2009 Ericsson
D. Thaler D. Thaler
Microsoft Microsoft
July 7, 2008 October 14, 2008
Security Concerns With Tunneling Security Concerns With IP Tunneling
draft-ietf-v6ops-tunnel-security-concerns-00 draft-ietf-v6ops-tunnel-security-concerns-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2009. This Internet-Draft will expire on April 17, 2009.
Abstract Abstract
A number of security concerns with tunnels are documented. The A number of security concerns with IP tunnels are documented in this
primary intent of this document is to raise the awareness regarding document. The intended audience of this document includes network
the security issues with tunnels as deployed today. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Tunnels May Bypass Security . . . . . . . . . . . . . . . . . 3 2. Tunnels May Bypass Security . . . . . . . . . . . . . . . . . 3
2.1. Network Security Bypass . . . . . . . . . . . . . . . . . 3 2.1. Network Security Bypass . . . . . . . . . . . . . . . . . 3
2.2. IP Ingress and Egress Filtering Bypass . . . . . . . . . . 5 2.2. IP Ingress and Egress Filtering Bypass . . . . . . . . . . 5
2.3. Source Routing After the Tunnel Client . . . . . . . . . . 6 2.3. Source Routing After the Tunnel Client . . . . . . . . . . 6
3. Challenges in Inspecting and Filtering Content of Tunneled 3. Challenges in Inspecting and Filtering Content of Tunneled
Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7 Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7 Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7
3.2. Problems with deep packet inspection of tunneled data 3.2. Problems with deep packet inspection of tunneled data
packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 packets . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Increased Exposure Due to Tunneling . . . . . . . . . . . . . 9 4. Increased Exposure Due to Tunneling . . . . . . . . . . . . . 9
4.1. NAT Holes Increase Attack Surface . . . . . . . . . . . . 9 4.1. NAT Holes Increase Attack Surface . . . . . . . . . . . . 9
4.2. Exposure of a NAT Hole . . . . . . . . . . . . . . . . . . 11 4.2. Exposure of a NAT Hole . . . . . . . . . . . . . . . . . . 11
4.3. Public Tunnels Widen Holes in Restricted NATs . . . . . . 12 4.3. Public Tunnels Widen Holes in Restricted NATs . . . . . . 12
5. Tunnel Address Concerns . . . . . . . . . . . . . . . . . . . 12 5. Tunnel Address Concerns . . . . . . . . . . . . . . . . . . . 12
5.1. Feasibility of Guessing Tunnel Addresses . . . . . . . . . 12 5.1. Feasibility of Guessing Tunnel Addresses . . . . . . . . . 12
5.2. Profiling Targets Based on Tunnel Address . . . . . . . . 13 5.2. Profiling Targets Based on Tunnel Address . . . . . . . . 13
6. Additional Security Concerns . . . . . . . . . . . . . . . . . 14 6. Additional Security Concerns . . . . . . . . . . . . . . . . . 15
6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 15 6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
With NATs becoming increasingly more prevalent, there have recently With NAT devices becoming increasingly more prevalent, there have
been many tunneling protocols developed that go through NATs or recently been many tunneling protocols developed that go through NAT
firewalls by tunneling over UDP or TCP. For example, Teredo devices or firewalls by tunneling over UDP or TCP. For example,
[RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel IP Teredo [RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel
packets over UDP. Similarly, many SSL VPN solutions that tunnel IP IP packets over UDP. Similarly, many SSL VPN solutions that tunnel
packets over HTTP (and hence over TCP) are deployed today. IP packets over HTTP (and hence over TCP) are deployed today.
This document discusses security concerns with tunneling IP packets, This document discusses security concerns with tunneling IP packets,
and includes recommendations where relevant. and includes recommendations where relevant.
The primary intent of this document is to provide information that The primary intent of this document is to provide information that
can be used in any new or updated tunnel protocol specification. can be used in any new or updated tunnel protocol specification.
Secondarily, this document can help improve security deployments Secondarily, this document can help improve security deployments
using tunnel protocols. using tunnel protocols. The intended audience of this document
includes network administrators and future protocol developers.
2. Tunnels May Bypass Security 2. Tunnels May Bypass Security
2.1. Network Security Bypass 2.1. Network Security Bypass
2.1.1. Problem 2.1.1. Problem
Tunneled IP traffic may not receive the intended level of inspection Tunneled IP traffic may not receive the intended level of inspection
or policy application by network-based security devices unless such or policy application by network-based security devices unless such
devices are specifically tunnel-aware. This reduces defense in depth devices are specifically tunnel-aware. This reduces defense in depth
skipping to change at page 4, line 37 skipping to change at page 4, line 37
there are host-based security controls that recognize tunnels, there are host-based security controls that recognize tunnels,
security administrators may not have configured them with full security administrators may not have configured them with full
security control parity, even if all controls that were maintained by security control parity, even if all controls that were maintained by
the network are available on the host. Thus there may be gaps in the network are available on the host. Thus there may be gaps in
desired coverage. desired coverage.
Compounding this is that, unlike what would be the case for native Compounding this is that, unlike what would be the case for native
IP, some network administrators will not even be aware that their IP, some network administrators will not even be aware that their
hosts are globally reachable, if the tunnel provides connectivity to/ hosts are globally reachable, if the tunnel provides connectivity to/
from the Internet; for example, they may not be expecting this for from the Internet; for example, they may not be expecting this for
hosts with [RFC1918] addresses behind a NAT. In addition, hosts with [RFC1918] addresses behind a NAT device. In addition,
Section 3.2 discusses how it may not be efficient to find all Section 3.2 discusses how it may not be efficient to find all
tunneled traffic for network devices to examine. tunneled traffic for network devices to examine.
2.1.3. Recommendations 2.1.3. Recommendations
Security administrators who do not consider tunneling an acceptable Security administrators who do not consider tunneling an acceptable
risk should disable tunnel functionality unless their network-based risk should disable tunnel functionality either on the end-nodes
security controls adequately recognize the tunneled traffic. (hosts) or on the network nodes. However, there may be an awareness
However, there may be an awareness gap. Thus, due to the possible gap. Thus, due to the possible negative security consequences, we
negative security consequences, we recommend that explicit user recommend that explicit user action be required to enable tunneling,
action be required to enable tunneling, at least for the first time. at least for the first time.
For example, when Teredo is being enabled or when it is going to be 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 used for the first time, there could be a descriptive warning about
the possible reduction of defense in depth that will occur. In the possible reduction of defense in depth that will occur. In
addition, Teredo client functionality should be easy to disable on addition, Teredo client functionality should be easy to disable on
the host and through a central management facility if one is the host and through a central management facility if one is
provided. (We could find no pre-existing mechanism for tunneling provided. (We could find no pre-existing mechanism for tunneling
protocols to use that could automate their functionality being protocols to use that could automate their functionality being
disabled unless all network-based security controls were aware of it. disabled unless all network-based security controls were aware of it.
A separate type of consent request packet would be needed.) A separate type of consent request packet would be needed.)
To minimize security exposure due to tunnels, we recommend that a To minimize security exposure due to tunnels, we recommend that a
tunnel be an interface of last resort, independent of IP version. tunnel be an interface of last resort, independent of IP version.
Specifically, we suggest that when both native and tunneled access to Specifically, we suggest that when both native and tunneled access to
a remote host is available, that the native-based access be used in a remote host is available, that the native access be used in
preference to tunneled access. This should also promote greater preference to tunneled access except when the tunnel endpoint is
efficiency and reliability. 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 Note that although Rule 7 of [RFC3484] section 6 will prefer native
connectivity over tunnels, this rule is only a tie-breaker when a connectivity over tunnels, this rule is only a tie-breaker when a
choice is not made by earlier rules; hence tunneling mechanisms that choice is not made by earlier rules; hence tunneling mechanisms that
are tied to a particular range of IP address space will be decided are tied to a particular range of IP address space will be decided
based on the prefix precedence. For example, using the prefix policy based on the prefix precedence. For example, using the prefix policy
mechanism of [RFC3484] section 2.1, Teredo might have a precedence of mechanism of [RFC3484] section 2.1, Teredo might have a precedence of
5 so that native IPv4 is preferred over Teredo. 5 so that native IPv4 is preferred over Teredo.
2.2. IP Ingress and Egress Filtering Bypass 2.2. IP Ingress and Egress Filtering Bypass
skipping to change at page 6, line 16 skipping to change at page 6, line 16
updated to find all tunneled packets and to apply ingress and updated to find all tunneled packets and to apply ingress and
egress controls equally to tunneled IP addresses. egress controls equally to tunneled IP addresses.
Tunnel server based: Tunnel servers can apply ingress and egress Tunnel server based: Tunnel servers can apply ingress and egress
controls to tunneled IP addresses passing through them to and from controls to tunneled IP addresses passing through them to and from
tunnel clients. tunnel clients.
Host based: Tunnel clients could make an effort to conduct ingress Host based: Tunnel clients could make an effort to conduct ingress
and egress filtering. and egress filtering.
Protocols that embed an IPv4 address in a tunneled IPv6 address Implementations of protocols that embed an IPv4 address in a
directly between peers often do filtering based on checking the tunneled IPv6 address directly between peers often do filtering
correpondence. based on checking the correspondence.
Protocols that accept tunneled packets directly from a server or Implementations of protocols that accept tunneled packets directly
relay do filtering the same way as it would be done on a native from a server or relay do filtering the same way as it would be
link with traffic from a router. done on a native link with traffic from a router.
To do host-based filtering with protocols that allow both other Some protocols such as 6to4 [RFC3056], Teredo, ISATAP [RFC5214],
hosts and a router over a common tunnel (e.g., 6to4 [RFC3056], and 6over4 [RFC2529] allow both other hosts and a router over a
Teredo, ISATAP [RFC4214], and 6over4 [RFC2529]), hosts would need common tunnel To perform host-based filtering with such protocols
to be able to know the outer IP address of all routers from which a host would need to know the outer IP address of each router from
it could receive traffic. This might be learned via Secure which it could receive traffic, so that packets from hosts beyond
Neighbor Discovery (SEND) [RFC3971] or some other mechanism (e.g., the router will be accepted even though the source address would
[RFC4214] section 8.3.2). 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).
2.3. Source Routing After the Tunnel Client 2.3. Source Routing After the Tunnel Client
2.3.1. Problem 2.3.1. Problem
If the encapsulated IP packet specifies source routing beyond the If the encapsulated IP packet specifies source routing beyond the
recipient tunnel client, the host may forward the IP packet to the recipient tunnel client, the host may forward the IP packet to the
specified next hop. This may be unexpected and contrary to specified next hop. This may be unexpected and contrary to
administrator wishes and may have bypassed network-based source administrator wishes and may have bypassed network-based source
routing controls. routing controls.
skipping to change at page 7, line 22 skipping to change at page 7, line 24
3.1.1. Problem 3.1.1. Problem
There is no mechanism to both efficiently and immediately filter all There is no mechanism to both efficiently and immediately filter all
tunneled packets. This limits the ability to prevent tunnel use on a tunneled packets. This limits the ability to prevent tunnel use on a
network. network.
3.1.2. Discussion 3.1.2. Discussion
Given concerns about tunnel security or a network's lack of Given concerns about tunnel security or a network's lack of
preparedness for tunnels, a network administrator may wish to simply preparedness for tunnels, a network administrator may wish to simply
block all use of tunnels. He or she may wish to do so using network block all use of tunnels that subvert security. He or she may wish
controls; this could be either due to not having confidence in the to do so using network controls; this could be either due to not
ability to disable it on all hosts attached to the network or due to having confidence in the ability to disable it on all hosts attached
wanting an extra layer of prevention. 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 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 protocols is to block outbound packets to the UDP or TCP port used
(e.g., UDP port 3544 for Teredo, UDP port 1701 for L2TP, etc.). This (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for
prevents a tunnel client from establishing a new tunnel. However, L2TP, etc.). This prevents a tunnel client from establishing a new
existing tunnels will not necessarily be affected if the blocked port tunnel. However, existing tunnels will not necessarily be affected
is used only for initial setup. In addition, if the blocking is if the blocked port is used only for initial setup. In addition, if
applied on the outside of the client's NAT, the NAT will retain the the blocking is applied on the outside of the client's NAT device,
port mapping for the client and the client may or may not continue to the NAT device will retain the port mapping for the client and the
use the IP address assigned to its tunnel. It is not known if client may or may not continue to use the IP address assigned to its
blocking all traffic to a given outbound port will interfere with tunnel. In some cases, however, blocking all traffic to a given
non-tunneled traffic. outbound port (e.g., port 80) may interfere with non-tunneled traffic
so this should be used with caution.
Another simple alternative, if the tunnel server addresses are well- Another simple alternative, if the tunnel server addresses are well-
known, is to filter out all traffic to/from such addresses. 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 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, would be done for inspecting all packets (Section 3.2). However,
this faces the difficulties in terms of efficiency of filtering as this faces the difficulties in terms of efficiency of filtering as
was present there. was present there.
3.1.3. Recommendations 3.1.3. Recommendations
Tunneling over UDP or TCP (including HTTP) to reach the Internet is Tunneling over UDP or TCP (including HTTP) to reach the Internet is
not recommended as a solution for managed networks. (Windows, for not recommended as a solution for networks that wish to enforce
example, disables Teredo by default if it detects that it is within a security polcies on the user traffic. (Windows, for example,
managed network.) disables Teredo by default if it detects that it is within an
enterprise network that contains a Windows domain controller.)
Administrators of such networks may wish to filter all tunneled Administrators of such networks may wish to filter all tunneled
traffic at the boundaries of their networks. It is sufficient to traffic at the boundaries of their networks. It is sufficient to
filter out the tunneled connection requests (if they can be filter out the tunneled connection requests (if they can be
identified) to stop further tunneled traffic. The easiest mechanism identified) to stop further tunneled traffic. The easiest mechanism
for this would be to filter out outgoing traffic sent to the for this would be to filter out outgoing traffic sent to the
destination port defined by the tunneling protocol, and incoming destination port defined by the tunneling protocol, and incoming
traffic with that source port. traffic with that source port.
3.2. Problems with deep packet inspection of tunneled data packets 3.2. Problems with deep packet inspection of tunneled data packets
skipping to change at page 9, line 10 skipping to change at page 9, line 15
doesn't use encryption), then treat the packet as if it is a tunneled doesn't use encryption), then treat the packet as if it is a tunneled
packet of that protocol. packet of that protocol.
It is possible that non-tunnel packets will match as tunneled using It is possible that non-tunnel packets will match as tunneled using
this heuristic, but tunneled packets (of the known types of tunnels) this heuristic, but tunneled packets (of the known types of tunnels)
should not escape inspection, absent implementation bugs. should not escape inspection, absent implementation bugs.
For some protocols, it may be possible to monitor setup exchanges to For some protocols, it may be possible to monitor setup exchanges to
know to expect that data will be exchanged on certain ports later. know to expect that data will be exchanged on certain ports later.
(Note that this does not necessarily apply to Teredo, for example, (Note that this does not necessarily apply to Teredo, for example,
since communicating with another Teredo client behind a cone NAT does since communicating with another Teredo client behind a cone NAT
not require such signaling. However, deprecation of the cone bit as device does not require such signaling. However, deprecation of the
discussed in [RFC4380] means this technique may indeed work with cone bit as discussed in [RFC4380] means this technique may indeed
Teredo.) work with Teredo.)
3.2.3. Recommendations 3.2.3. Recommendations
As illustrated above, it should be clear that inspecting the contents As illustrated above, it should be clear that inspecting the contents
of tunneled data packets is highly complex and often impractical. of tunneled data packets is highly complex and often impractical.
For this reason, if a network wishes to monitor IP traffic, tunneling For this reason, if a network wishes to monitor IP traffic, tunneling
is not recommended. For example, to provide an IPv6 transition is not recommended. For example, to provide an IPv6 transition
solution, the network should provide native IPv6 connectivity or a solution, the network should provide native IPv6 connectivity or a
tunnel solution (e.g., ISATAP or 6over4) that encapsulates data tunnel solution (e.g., ISATAP or 6over4) that encapsulates data
packets between hosts and a router within the network. packets between hosts and a router within the network.
4. Increased Exposure Due to Tunneling 4. Increased Exposure Due to Tunneling
4.1. NAT Holes Increase Attack Surface 4.1. NAT Holes Increase Attack Surface
4.1.1. Problem 4.1.1. Problem
If the tunnel allows inbound access from the public Internet, the If the tunnel allows inbound access from the public Internet, the
opening created in a NAT due to a tunnel client increases its opening created in a NAT device due to a tunnel client increases its
Internet attack surface area. If vulnerabilities are present, this Internet attack surface area. If vulnerabilities are present, this
increased exposure can be used by attackers and their programs. increased exposure can be used by attackers and their programs.
If the tunnel allows inbound access only from a private network 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 (e.g., a remote network to which one has VPN'ed), the opening created
in the NAT still increases its attack surface area, although not as in the NAT device still increases its attack surface area, although
much as in the public Internet case. not as much as in the public Internet case.
4.1.2. Discussion 4.1.2. Discussion
When a tunnel is active, a mapped port is maintained on the NAT When a tunnel is active, a mapped port is maintained on the NAT
through which remote hosts can send packets and perhaps establish device through which remote hosts can send packets and perhaps
connections. The following sequence is intended to sketch out the establish connections. The following sequence is intended to sketch
processing on the tunnel client host that can be reached through out the processing on the tunnel client host that can be reached
this; the actual processing for a given host may be somewhat through this; the actual processing for a given host may be somewhat
different. different.
1. Link-layer protocol processing 1. Link-layer protocol processing
2. (Outer) IP host firewall processing 2. (Outer) IP host firewall processing
3. (Outer) IP processing by stack 3. (Outer) IP processing by stack
4. UDP/TCP processing by stack 4. UDP/TCP processing by stack
skipping to change at page 11, line 5 skipping to change at page 11, line 10
4.1.3. Recommendations 4.1.3. Recommendations
This problem seems inherent in tunneling being active on a host, so This problem seems inherent in tunneling being active on a host, so
the solution seems to be to minimize tunneling use. the solution seems to be to minimize tunneling use.
For example, it can be active only when it is really needed and only 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 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 configured and only used when it is entirely the last resort. The
interface should then be deactivated (ideally, automatically) again interface should then be deactivated (ideally, automatically) again
as soon as possible. Note however that the hole will remain in the as soon as possible. Note however that the hole will remain in the
NAT for some amount of time after this, so some processing of NAT device for some amount of time after this, so some processing of
incoming packets is inevitable (unless the client's native IP address incoming packets is inevitable (unless the client's native IP address
behind the NAT is changed). behind the NAT device is changed).
4.2. Exposure of a NAT Hole 4.2. Exposure of a NAT Hole
4.2.1. Problem 4.2.1. Problem
Attackers are more likely to know about a tunnel client's NAT hole Attackers are more likely to know about a tunnel client's NAT hole
than a typical hole in the NAT. If they know about the hole, they than a typical hole in the NAT device. If they know about the hole,
could try to use it. they could try to use it.
4.2.2. Discussion 4.2.2. Discussion
There are at least three reasons why an attacker may be more likely 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 to learn of the tunnel client's exposed port than a typical NAT
exposed port: exposed port:
1. The NAT mapping for a tunnel is typically held open for a 1. The NAT mapping for a tunnel is typically held open for a
significant period of time, and kept stable. This increases the significant period of time, and kept stable. This increases the
chance of it being discovered. chance of it being discovered.
skipping to change at page 12, line 12 skipping to change at page 12, line 17
The recommendations from Section 4.1 seem to apply here as well: The recommendations from Section 4.1 seem to apply here as well:
minimize tunnel use. minimize tunnel use.
4.3. Public Tunnels Widen Holes in Restricted NATs 4.3. Public Tunnels Widen Holes in Restricted NATs
4.3.1. Problem 4.3.1. Problem
Tunnels that allow inbound connectivity from the Internet (e.g., Tunnels that allow inbound connectivity from the Internet (e.g.,
Teredo, tunnel brokers, etc) essentially turn a restricted or Teredo, tunnel brokers, etc) essentially turn a restricted or
symmetric NAT into an unrestricted one, for all tunnel client ports. symmetric NAT into an unrestricted one, for all tunnel client ports.
This eliminates NAT filtering for such ports and may eliminate the This eliminates NAT devices filtering for such ports and may
need for an attacker to spoof an address. eliminate the need for an attacker to spoof an address.
4.3.2. Discussion 4.3.2. Discussion
Restricted, port restricted, and symmetric NATs [RFC3489] limit the Restricted, port restricted, and symmetric NAT devices [RFC3489]
source of incoming packets to just those that are a previous limit the source of incoming packets to just those that are a
destination. This poses a problem for tunnels that intend to allow previous destination. This poses a problem for tunnels that intend
inbound connectivity from the Internet. to allow inbound connectivity from the Internet.
Various protocols (e.g., Teredo, STUN [RFC3489], etc.) provide a Various protocols (e.g., Teredo, STUN [RFC3489], etc.) provide a
facility for peers, upon request, to become a previous destination. facility for peers, upon request, to become a previous destination.
This works by sending a "bubble" packet via a server, which is passed 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 to the client, and then sent by the client (through the NAT) to the
originator. originator.
This removes any NAT-based barrier to attackers sending packets in This removes any NAT-based barrier to attackers sending packets in
through the client's service port. In particular, an attacker would through the client's service port. In particular, an attacker would
no longer need to either be an actual previous destination or to no longer need to either be an actual previous destination or to
skipping to change at page 13, line 47 skipping to change at page 14, line 6
software is often deployed, installed, and/or configured using software is often deployed, installed, and/or configured using
some degree of automation. It seems likely that the majority of some degree of automation. It seems likely that the majority of
the time the tunnel server that results from the initial the time the tunnel server that results from the initial
configuration will go unchanged from the initial setting. configuration will go unchanged from the initial setting.
Moreover, the server that is configured for use may be associated Moreover, the server that is configured for use may be associated
with a particular means of installation, which often suggests the with a particular means of installation, which often suggests the
platform. For example, if the server field in a Teredo address is platform. For example, if the server field in a Teredo address is
one of the IPv4 addressees to which teredo.ipv6.microsoft.com one of the IPv4 addressees to which teredo.ipv6.microsoft.com
resolves, it suggests that the host is running Windows. resolves, it suggests that the host is running Windows.
o The external IPv4 address of a NAT can of course be readily 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 associated with a particular organization or at least an ISP, and
hence putting this address in an IPv6 address reveals this hence putting this address in an IPv6 address reveals this
information. However, this is no different than using a native IP information. However, this is no different than using a native IP
address, and hence is not new with tunneling. address, and hence is not new with tunneling.
o It is also possible that external client port numbers may be more o It is also possible that external client port numbers may be more
often associated with particular client software or the platform often associated with particular client software or the platform
on which it is running. The usefulness of this for platform on which it is running. The usefulness of this for platform
determination is, however, reduced by the different NAT port determination is, however, reduced by the different NAT port
number assignment behaviors. In addition, the same observations number assignment behaviors. In addition, the same observations
skipping to change at page 17, line 8 skipping to change at page 17, line 11
The scope of the attack can also be reduced by limiting tunneling use The scope of the attack can also be reduced by limiting tunneling use
in general but especially in preferring native IPv4 to tunneled IPv6; in general but especially in preferring native IPv4 to tunneled IPv6;
this is because it is reasonable to expect that banks and similar web 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 sites will continue to be accessible over IPv4 for as long as a
significant fraction of their customers are still IPv4-only. significant fraction of their customers are still IPv4-only.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Remi Denis-Courmont, Fred Templin, The authors would like to thank Remi Denis-Courmont, Fred Templin,
Jordi Palet Martinez, James Woodyatt and Christian Huitema for Jordi Palet Martinez, James Woodyatt, Christian Huitema and Kurt
reviewing earlier versions of the document and providing comments to Zeilenga for reviewing earlier versions of the document and providing
make this document better. The authors would also like to thank comments to make this document better. The authors would also like
Alfred Hines for a careful review of the document. to thank Alfred Hines for a careful review of the document.
8. Security Considerations 8. Security Considerations
This entire document discusses security concerns with tunnels. This entire document discusses security concerns with tunnels.
9. IANA Considerations 9. IANA Considerations
There are no actions for IANA in this document. There are no actions for IANA in this document.
10. References 10. Informative References
10.1. Normative References [I-D.ietf-tsvwg-port-randomization]
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 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999. Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
skipping to change at page 18, line 8 skipping to change at page 18, line 16
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. 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 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. 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 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
10.2. Informative References [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
[I-D.ietf-tsvwg-port-randomization] March 2008.
Larsen, M. and F. Gont, "Port Randomization",
draft-ietf-tsvwg-port-randomization-01 (work in progress),
February 2008.
Authors' Addresses Authors' Addresses
James Hoagland James Hoagland
Symantec Corporation Symantec Corporation
350 Ellis St. 350 Ellis St.
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: Jim_Hoagland@symantec.com Email: Jim_Hoagland@symantec.com
 End of changes. 34 change blocks. 
100 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/