draft-ietf-v6ops-tunnel-security-concerns-02.txt   draft-ietf-v6ops-tunnel-security-concerns-03.txt 
IPv6 Operations Working Group J. Hoagland IPv6 Operations Working Group S. Krishnan
Internet-Draft Symantec Internet-Draft Ericsson
Intended status: Informational S. Krishnan Intended status: Informational D. Thaler
Expires: September 9, 2010 Ericsson Expires: April 23, 2011 Microsoft
D. Thaler J. Hoagland
Microsoft Symantec
March 8, 2010 October 20, 2010
Security Concerns With IP Tunneling Security Concerns With IP Tunneling
draft-ietf-v6ops-tunnel-security-concerns-02 draft-ietf-v6ops-tunnel-security-concerns-03
Abstract Abstract
A number of security concerns with IP tunnels are documented in this A number of security concerns with IP tunnels are documented in this
memo. The intended audience of this document includes network memo. The intended audience of this document includes network
administrators and future protocol developers. The primary intent of administrators and future protocol developers. The primary intent of
this document is to raise the awareness regarding the security issues this document is to raise the awareness level regarding the security
with IP tunnels as deployed today. issues with IP tunnels as deployed today.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on April 23, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 25 skipping to change at page 2, line 40
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 . . . . . . . . . . . . . . . . . 15 6. Additional Security Concerns . . . . . . . . . . . . . . . . . 14
6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 15 6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 14
7. Mechanisms to secure the use of tunnels . . . . . . . . . . . 17 7. Mechanisms to secure the use of tunnels . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Informative References . . . . . . . . . . . . . . . . . . . . 18 11. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
With NAT devices becoming increasingly more prevalent, there have With NAT devices becoming increasingly more prevalent, there have
recently been many tunneling protocols developed that go through NAT recently been many tunneling protocols developed that go through NAT
devices or firewalls by tunneling over UDP or TCP. For example, devices or firewalls by tunneling over UDP or TCP. For example,
Teredo [RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel Teredo [RFC4380], L2TPv2 [RFC2661], and L2TPv3 [RFC3931] all tunnel
IP packets over UDP. Similarly, many SSL VPN solutions that tunnel IP packets over UDP. Similarly, many SSL VPN solutions that tunnel
IP 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 help improve security
can be used in any new or updated tunnel protocol specification. deployments using tunnel protocols. In addition, the document aims
Secondarily, this document can help improve security deployments to provide information that can be used in any new or updated tunnel
using tunnel protocols. The intended audience of this document protocol specification. The intended audience of this document
includes network administrators and future protocol developers. 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
and may cause security gaps. This applies to all network-located and may cause security gaps. This applies to all network-located
devices and to any end-host based firewalls whose existing hooking devices and to any end-host based firewalls whose existing hooking
mechanism(s) would not show them the IP packet stream after the mechanism(s) would not show them the IP packet stream after the
tunnel client does decapsulation. tunnel client does decapsulation or before it does encapsulation.
2.1.2. Discussion 2.1.2. Discussion
Evasion by tunneling is often a problem for network-based security Evasion by tunneling is often a problem for network-based security
devices such as network firewalls, intrusion detection and prevention devices such as network firewalls, intrusion detection and prevention
systems, and router controls. To provide such functionality in the systems, and router controls. To provide such functionality in the
presence of tunnels, the developer of such devices must add support presence of tunnels, the developer of such devices must add support
for detunneling for each new protocol. There is typically a for parsing each new protocol. There is typically a significant lag
significant lag between when the security developer recognizes that a between when the security developer recognizes that a tunnel will be
tunnel will be used (or will be remotely usable) to a significant used (or will be remotely usable) to a significant degree and when
degree and when the detunneling can be implemented in a product the parsing can be implemented in a product update, the update tested
update, the update tested and released, and customers begin using the and released, and customers begin using the update. Late changes in
update. Late changes in the protocol specification or in the way it the protocol specification or in the way it is implemented can cause
is implemented can cause additional delays. This becomes a additional delays. This becomes a significant security concern when
significant security concern when a delay in applied coverage is a delay in applied coverage is occurring frequently. One way to cut
occurring frequently. down on this lag is for security developers to follow the progress of
new IETF protocols but this will still not account for any new
proprietary protocols.
For example, for L2TP or Teredo, an unaware network security device 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 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 normal, but it would not recognize that there is an additional IP
layer contained inside the UDP payload that it needs to apply the layer contained inside the UDP payload to which it needs to apply the
same controls as it would to a native packet. (Of course, if the 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, 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 such as referring to an unknown protocol, the embedded packet is no
longer a concern.) In addition, if the tunnel does encryption, the 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 network-based security device may not be able to do much, just as if
IPsec end-to-end encryption were used without tunneling. IPsec end-to-end encryption were used without tunneling.
Network security controls being not applied must be a concern to Network security controls being not applied must be a concern to
those that set them up, since those controls are supposed to those that set them up, since those controls are supposed to
adequately regulate all traffic. If network controls are being adequately regulate all traffic. If network controls are being
bypassed due to the use of tunneling, the burden of controls shifts bypassed due to the use of tunneling, the burden of control shifts to
to the tunnel client host. Since security administrators may not the tunnel client. Since security administrators may not always have
have full control over all the nodes on their network, they sometimes full control over all the nodes on their network, they sometimes
prefer to implement security controls on the network. prefer to implement security controls on the network.
One implication of the security control bypass is that defense in One implication of the security control bypass is that defense in
depth has been reduced, perhaps down to zero unless a 'local depth has been reduced, perhaps down to zero unless a 'local
firewall' is in use as recommended in [RFC4380]. However, even if firewall' is in use as recommended in [RFC4380]. However, even if
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.
skipping to change at page 5, line 45 skipping to change at page 4, line 47
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 device. 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 either on the end-nodes risk should disable tunnel functionality either on the end-nodes
(hosts) or on the network nodes. However, there may be an awareness (hosts) or on the network nodes at the perimeter of their network.
gap. Thus, due to the possible negative security consequences, we However, there may be an awareness gap. Thus, due to the possible
recommend that explicit user action be required to enable tunneling, negative security consequences, tunneling functionality should be
at least for the first time. easy to disable on the host and through a central management facility
if one is provided.
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 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 access be used in a remote host is available, that the native access be used in
preference to tunneled access except when the tunnel endpoint is preference to tunneled access except when the tunnel endpoint is
known to not bypass security (e.g., an IPsec tunnel to a gateway known to not bypass security (e.g., an IPsec tunnel to a gateway
provided by the security administrator of the network). This should provided by the security administrator of the network). This should
also promote greater efficiency and reliability. also promote greater efficiency and reliability.
skipping to change at page 6, line 41 skipping to change at page 5, line 35
IP addresses inside tunnels are not subject to ingress and egress IP addresses inside tunnels are not subject to ingress and egress
filtering in the network they tunnel over, unless extraordinary filtering in the network they tunnel over, unless extraordinary
measures are taken. Only the tunnel endpoints can do such filtering. measures are taken. Only the tunnel endpoints can do such filtering.
2.2.2. Discussion 2.2.2. Discussion
Ingress filtering (sanity-checking incoming destination addresses) Ingress filtering (sanity-checking incoming destination addresses)
and egress filtering (sanity-checking outgoing source addresses) are and egress filtering (sanity-checking outgoing source addresses) are
done to mitigate attacks and to make it easier to identify the source 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 of a packet and are considered to be a good practice. e.g. ingress
naturally (and in the general case, by requirement) done at network filtering at the network perimeter should not allow packets with a
boundaries. Tunneled IP traffic bypassing this network control is a source address that belongs to the network to enter the network from
specific case of Section 2.1, but is illustrative. the outside the network. This function 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 2.2.3. Recommendations
The recommendations in Section 2.1.3 can help here. For this problem The recommendations in Section 2.1.3 can help here. For this problem
specifically, there are three locations in which ingress and egress specifically, there are three locations in which ingress and egress
filtering can be done. filtering can be done.
Network based: Network-based devices (e.g., routers) could be Network based: Network-based devices (e.g., routers) could be
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.
Implementations of protocols that embed an IPv4 address in a Implementations of protocols that embed an IPv4 address in a
tunneled IPv6 address directly between peers often do filtering tunneled IPv6 address directly between peers should perform
based on checking the correspondence. filtering based on checking the correspondence.
Implementations of protocols that accept tunneled packets directly Implementations of protocols that accept tunneled packets directly
from a server or relay do filtering the same way as it would be from a server or relay do filtering the same way as it would be
done on a native link with traffic from a router. done on a native link with traffic from a router.
Some protocols such as 6to4 [RFC3056], Teredo, ISATAP [RFC5214], Some protocols such as 6to4 [RFC3056], Teredo, and ISATAP
and 6over4 [RFC2529] allow both other hosts and a router over a [RFC5214] allow both other hosts and a router over a common
common tunnel. To perform host-based filtering with such tunnel. To perform host-based filtering with such protocols a
protocols a host would need to know the outer IP address of each host would need to know the outer IP address of each router from
router from which it could receive traffic, so that packets from which it could receive traffic, so that packets from hosts beyond
hosts beyond the router will be accepted even though the source the router will be accepted even though the source address would
address would not embed the router's IP address. Router addresses not embed the router's IP address. Router addresses might be
might be learned via Secure Neighbor Discovery (SEND) [RFC3971] or learned via Secure Neighbor Discovery (SEND) [RFC3971] or some
some other mechanism (e.g., [RFC5214] section 8.3.2). 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.
2.3.2. Discussion 2.3.2. Discussion
A detailed discussion of issues related to source routing can be A detailed discussion of issues related to source routing can be
found in [RFC5095]. found in [RFC5095] and [SECA-IP].
2.3.3. Recommendations 2.3.3. Recommendations
Tunnel clients should by default discard tunneled IP packets that Tunnel clients should by default discard tunneled IP packets that
specify additional routing, as recommended in [RFC5095], though they specify additional routing, as recommended in [RFC5095] and
may also allow the user to configure what source routing types are [SECA-IP], though they may also allow the user to configure what
allowed. All pre-existing source routing controls should be upgraded source routing types are allowed. All pre-existing source routing
to apply these controls to tunneled IP packets as well. 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. Challenges in Inspecting and Filtering Content of Tunneled Data
Packets Packets
3.1. Inefficiency of Selective Network Filtering of All Tunneled 3.1. Inefficiency of Selective Network Filtering of All Tunneled
Packets Packets
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 (other than the obviously faulty method of filtering
all 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 that subvert security. He or she may wish block all use of tunnels that bypass security policies. He or she
to do so using network controls; this could be either due to not may wish to do so using network controls; this could be either due to
having confidence in the ability to disable it on all hosts attached not having the capability to disable tunneling on all hosts attached
to the network or due to 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 of doing this easily for many tunnel protocols is
protocols is to block outbound packets to the UDP or TCP port used to block outbound packets to the UDP or TCP port used (e.g.,
(e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for destination UDP port is 3544 for Teredo, UDP port 1701 for L2TP,
L2TP, etc.). This prevents a tunnel client from establishing a new etc.). This prevents a tunnel client from establishing a new tunnel.
tunnel. However, existing tunnels will not necessarily be affected However, existing tunnels will not necessarily be affected if the
if the blocked port is used only for initial setup. In addition, if blocked port is used only for initial setup. In addition, if the
the blocking is applied on the outside of the client's NAT device, blocking is applied on the outside of the client's NAT device, the
the NAT device will retain the port mapping for the client and the NAT device will retain the port mapping for the client and the client
client may or may not continue to use the IP address assigned to its may or may not continue to use the IP address assigned to its tunnel.
tunnel. In some cases, however, blocking all traffic to a given In some cases, however, blocking all traffic to a given outbound port
outbound port (e.g., port 80) may interfere with non-tunneled traffic (e.g., port 80) may interfere with non-tunneled traffic so this
so this should be used with caution. 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. is discussed 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 networks that wish to enforce not recommended for use in networks that wish to enforce security
security polcies on the user traffic. (Windows, for example, policies on the user traffic. (Windows, for example, disables Teredo
disables Teredo by default if it detects that it is within an by default if it detects that it is within an enterprise network that
enterprise network that contains a Windows domain controller.) 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. Similarly, in certain cases, it is
also possible to use the IP protocol field to identify and filter
tunneled packets. e.g. 6to4 [RFC3056] is a tunneling mechanism that
uses the IPv4 packets to carry encapsulated IPv6 packets, and can be
identified by the IPv4 protocol type 41.
3.2. Problems with deep packet inspection of tunneled data packets 3.2. Problems with deep packet inspection of tunneled data packets
3.2.1. Problem 3.2.1. Problem
There is no efficient mechanism for network-based devices to inspect There is no efficient mechanism for network-based devices, which are
the contents of all tunneled data packets, the way they can for not the tunnel endpoint, to inspect the contents of all tunneled data
native packets. This makes it difficult to apply the same controls packets, the way they can for native packets. This makes it
as they do to native IP. difficult to apply the same controls as they do to native IP.
3.2.2. Discussion 3.2.2. Discussion
Some tunnel protocols are easy to identify, such as if all data 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 packets are encapsulated using a well-known UDP or TCP port that is
unique to the protocol. unique to the protocol.
Other protocols, however, either use dynamic ports for data traffic, Other protocols, however, either use dynamic ports for data traffic,
or else share ports with other protocols (e.g., tunnels over HTTP). or else share ports with other protocols (e.g., tunnels over HTTP).
skipping to change at page 10, line 16 skipping to change at page 9, line 15
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 since communicating with another Teredo client behind a cone NAT
device does not require such signaling. However, deprecation of the [RFC5389] device does not require such signaling. In such cases this
cone bit as discussed in [RFC4380] means this technique may indeed control will not work. However, deprecation of the cone bit as
work with Teredo.) discussed in [RFC5991] means this technique may indeed work with
updated Teredo implementations.)
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 across, as opposed to tunneling to, the security boundary is not
solution, the network should provide native IPv6 connectivity or a recommended. For example, to provide an IPv6 transition solution,
tunnel solution (e.g., ISATAP or 6over4) that encapsulates data the network should provide native IPv6 connectivity or a tunnel
packets between hosts and a router within the network. 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. 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 device 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
skipping to change at page 11, line 5 skipping to change at page 10, line 6
(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 device still increases its attack surface area, although in the NAT device still increases its attack surface area, although
not as 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
device through which remote hosts can send packets and perhaps device through which remote hosts can send packets and perhaps
establish connections. The following sequence is intended to sketch establish connections. The following sequence is intended to sketch
out the processing on the tunnel client host that can be reached out the processing on the tunnel client host that can be reached
through this; the actual processing for a given host may be somewhat through this mapped port; the actual processing for a given host may
different. be somewhat 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
5. Tunnel client processing 5. Tunnel client processing
skipping to change at page 11, line 30 skipping to change at page 10, line 31
7. (Inner) IP processing by stack 7. (Inner) IP processing by stack
8. Various upper layer processing may follow 8. Various upper layer processing may follow
The inner firewall (and other security) processing may or may not be 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 present, but if it is, some of the inner IP processing may be
filtered. (For example, [RFC4380] section 7.1 recommends that an filtered. (For example, [RFC4380] section 7.1 recommends that an
IPv6 host firewall be used on all Teredo clients.) IPv6 host firewall be used on all Teredo clients.)
(By the virtue of the tunnel being active, we can infer that the (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 inner host firewall is unlikely to do any filtering based on the
of this processing may expose vulnerabilities an attacker can outer IP.) Any of this processing may expose vulnerabilities an
exploit; similarly these may expose information to an attacker. attacker can exploit; similarly these may expose information to an
Thus, even if firewall filtering is in place (as is prudent) and attacker. Thus, even if firewall filtering is in place (as is
filters all incoming packets, the exposed area is larger than if a prudent) and filters all incoming packets, the exposed area is larger
native IP Internet connection were in place, due to the processing than if a native IP Internet connection were in place, due to the
that takes place before the inner IP is reached (specifically, the processing that takes place before the inner IP is reached
UDP/TCP processing, the tunnel client processing, and additional IP (specifically, the UDP/TCP processing, the tunnel client processing,
processing, especially if one is IPv4 and the other is IPv6). 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 One possibility is that a layer 3 targeted worm makes use of a
vulnerability in the exposed processing. While the main benefit to vulnerability in the exposed processing. The main benefit tunneling
worms from tunneling is targeting at layer 3 reaching the end host, provides to worms is enabling L3 reachability to the end host. Even
even a thoroughly firewalled host could be subject to a worm that a thoroughly firewalled host could be subject to a worm that spreads
spreads with a single UDP packet if the right remote code with a single UDP packet if the right remote code vulnerability is
vulnerability is present. present.
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 device 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 device 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 device. If they know about the hole, than a typical hole in the NAT device. If they know about the hole,
they could try to use it. they could try to use it.
4.2.2. Discussion 4.2.2. Discussion
skipping to change at page 12, line 44 skipping to change at page 11, line 49
end and possibly even advertised in a name resolution system. end and possibly even advertised in a name resolution system.
While the tunnel protocol itself might only distribute this While the tunnel protocol itself might only distribute this
address in IP headers, peers, routers, and other on-path nodes address in IP headers, peers, routers, and other on-path nodes
still see the client's IP address. Although this point does not still see the client's IP address. Although this point does not
apply directly to protocols (e.g., L2TP) that do not construct apply directly to protocols (e.g., L2TP) that do not construct
the inner IP address based on the outer IP address, the inner IP 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 address is still known to peers, routers, etc. and can still be
reached by attackers without knowing the external IP address or reached by attackers without knowing the external IP address or
port. port.
3. The tunnel protocol contains more messages that are exchanged and 3. The tunnel protocol often contains more messages that are
with more parties (e.g., due to a longer path length) than exchanged and with more parties (e.g., due to a longer path
without using the tunnel, offering more chance for visibility length) than without using the tunnel, offering more chance for
into the port and address in use. visibility into the port and address in use.
4.2.3. Recommendations 4.2.3. Recommendations
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 disable the filtering
symmetric NAT into an unrestricted one, for all tunnel client ports. behavior of the NAT for all tunnel client ports. This eliminates NAT
This eliminates NAT devices filtering for such ports and may devices filtering for such ports and may eliminate the need for an
eliminate the need for an attacker to spoof an address. attacker to spoof an address.
4.3.2. Discussion 4.3.2. Discussion
Restricted, port restricted, and symmetric NAT devices [RFC3489] NATs that implement Address-Dependent or Address and Port-Dependent
limit the source of incoming packets to just those that are a Filtering [RFC4787] limit the source of incoming packets to just
previous destination. This poses a problem for tunnels that intend those that are a previous destination. This poses a problem for
to allow inbound connectivity from the Internet. tunnels that intend to allow inbound connectivity from the Internet.
Various protocols (e.g., Teredo, STUN [RFC3489], etc.) provide a Various protocols (e.g., Teredo, STUN [RFC5389], 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
forge its addresses as a previous destination. When forging, the forge its addresses as a previous destination. When forging, the
attacker would have had to learn of a previous destination and then attacker would have had to learn of a previous destination and then
skipping to change at page 14, line 40 skipping to change at page 13, line 40
client. client.
o That a host has a tunnel address associated with a given protocol o That a host has a tunnel address associated with a given protocol
means that the client is running on some platform for which there means that the client is running on some platform for which there
exists a tunnel client implementation of that protocol. In exists a tunnel client implementation of that protocol. In
addition, if some platforms have that protocol installed by addition, if some platforms have that protocol installed by
default and where the host's default rules for using it make it 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 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. 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 For example, as of this writing, seeing a Teredo address suggests
that the host it is on is running Windows Vista. that the host it is on is probably running Windows.
o Similarly, the use of an address associated with a particular o Similarly, the use of an address associated with a particular
tunnel server also suggests some information. Tunnel client tunnel server also suggests some information. Tunnel client
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
skipping to change at page 15, line 29 skipping to change at page 14, line 29
The platform, tunnel client software, or organization information can The platform, tunnel client software, or organization information can
be used by an attacker to target attacks more carefully. For be used by an attacker to target attacks more carefully. For
example, an attacker may decide to attack an address only if it is example, an attacker may decide to attack an address only if it is
likely to be associated with a particular platform or tunnel client likely to be associated with a particular platform or tunnel client
software with a known vulnerability. (This is similar to the ability 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 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 IPv6 address generated from a MAC address, since some platforms are
commonly used with interface cards from particular vendors.) 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 5.2.3. Recommendations
If installation programs randomized the server setting, that would If installation programs randomized the server setting, that would
reduce the extent to which they can be profiled. Similarly, reduce the extent to which they can be profiled. Similarly,
administrators can choose to change the default setting to reduce the administrators can choose to change the default setting to reduce the
degree to which they can be profiled ahead of time. degree to which they can be profiled ahead of time.
Randomizing the tunnel client port in use would mitigate any Randomizing the tunnel client port in use would mitigate any
profiling that can be done based on the external port, especially if profiling that can be done based on the external port, especially if
multiple different Teredo clients did this. Further discussion on multiple different tunnel clients did this. Further discussion on
randomizing ports can be found at randomizing ports can be found at [TSV-PORT].
[I-D.ietf-tsvwg-port-randomization].
It is recommended that tunnel protocols minimize the propagation It is recommended that tunnel protocols minimize the propagation of
knowledge about whether the NAT is a cone NAT. For example, the cone knowledge about whether the NAT is a cone NAT.
bit for Teredo should be deprecated.
6. Additional Security Concerns 6. Additional Security Concerns
6.1. Attacks Facilitated By Changing Tunnel Server Setting 6.1. Attacks Facilitated By Changing Tunnel Server Setting
6.1.1. Problem 6.1.1. Problem
If an attacker could either change a tunnel client's server setting If an attacker could either change a tunnel client's server setting
or change the IP addresses to which a configured host name resolves or change the IP addresses to which a configured host name resolves
(e.g., by intercepting DNS queries), it would let them become a man (e.g., by intercepting DNS queries) AND the tunnel is not
in the middle. This will allow them to at least monitor peer authenticated, it would let the attacker become a man in the middle.
communication and at worst pretend to represent the remote peer. This would allow them to at least monitor peer communication and at
worst to impersonate the remote peer.
6.1.2. Discussion 6.1.2. Discussion
A client's server has good visibility into the client's communication 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 with IP peers. If the server were switched to one that records this
information and makes it available to third parties (e.g., information and makes it available to third parties (e.g.,
advertisers, competitors, spouses, etc.) then sensitive information advertisers, competitors, spouses, etc.) then sensitive information
is being disclosed, especially if the client's host prefers the would be disclosed, especially if the client's host prefers the
tunnel over native IP. Assuming the server provides good service, tunnel over native IP. Assuming the server provides good service,
the user would not have reason to suspect the change. the user would not have reason to suspect the change.
Full interception of IP traffic could also be arranged (including Full interception of IP traffic could also be arranged (including
pharming) which would allow any number of deception or monitoring pharming) which would allow any number of deception or monitoring
attacks including phishing. We illustrate this with an example attacks including phishing. We illustrate this with an example
phishing attack scenario. phishing attack scenario.
It is often assumed that the tunnel server is a trusted entity. It 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 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 client's tunnel server setting and have the user be unaware their
trust has been misplaced for an indefinite period of time. However, 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 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 not a significant concern. Hence it is only important that an
attacker on the network cannot change the client's server setting. attacker on the network cannot change the client's server setting.
1. A phisher sets up a malicious tunnel server (or tampers with a 1. A phisher sets up a malicious tunnel server (or tampers with a
legitimate one). This server, for the most part, provides legitimate one). This server, for the most part, provides
correct service. correct service.
2. An attacker, by some means, switches the host's tunnel server 2. An attacker, by some means, switches the host's tunnel server
skipping to change at page 17, line 42 skipping to change at page 16, line 35
In general, anti-phishing and anti-fraud provisions should help with In general, anti-phishing and anti-fraud provisions should help with
aspects of this, as well as software that specifically monitors for aspects of this, as well as software that specifically monitors for
tunnel server changes. tunnel server changes.
Perhaps the best way to mitigate tunnel-specific attacks is to have Perhaps the best way to mitigate tunnel-specific attacks is to have
the client either authenticate the tunnel server, or at least the the client either authenticate the tunnel server, or at least the
means by which the tunnel server's IP address is determined. For means by which the tunnel server's IP address is determined. For
example, SSL VPNs use https URLs and hence authenticate the server as example, SSL VPNs use https URLs and hence authenticate the server as
being the expected one. Another mechanism, when IPv6 Router being the expected one. Another mechanism, when IPv6 Router
Advertisements are sent over the tunnel (e.g., in Teredo), is to use Advertisements are sent over the tunnel is to use SEcure Neighbor
SEcure Neighbor Discovery (SEND) to verify that the client trusts the Discovery (SEND) [RFC3971] to verify that the client trusts the
server. server.
On the host, it should require an appropriate level of privilege in On the host, it should require an appropriate level of privilege in
order to change the tunnel server setting (as well as other non- order to change the tunnel server setting (as well as other non-
tunnel-specific settings such as the DNS server setting, etc.). tunnel-specific settings such as the DNS server setting, etc.).
Making it easy to see the current tunnel server setting (e.g., not Making it easy to see the current tunnel server setting (e.g., not
requiring privilege for this) should help detection of changes. requiring privilege for this) should help detection of changes.
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;
skipping to change at page 18, line 17 skipping to change at page 17, line 13
significant fraction of their customers are still IPv4-only. significant fraction of their customers are still IPv4-only.
7. Mechanisms to secure the use of tunnels 7. Mechanisms to secure the use of tunnels
This document described several security issues with tunnels. This This document described several security issues with tunnels. This
does not mean that tunnels need to be avoided at any cost. On the does not mean that tunnels need to be avoided at any cost. On the
contrary, tunnels can be very useful if deployed, operated and used contrary, tunnels can be very useful if deployed, operated and used
properly. The threats against IP tunnels are documented here. If properly. The threats against IP tunnels are documented here. If
the threats can be mitigated, network administrators can efficiently the threats can be mitigated, network administrators can efficiently
and securely use tunnels in their network. Several measures can be and securely use tunnels in their network. Several measures can be
taken in order to secure the operation of IPv6 tunnels. taken in order to secure the operation of IPv6 tunnels:
o Operating on-premise tunnel servers/relays so that the tunneled o Operating on-premise tunnel servers/relays so that the tunneled
traffic does not cross border routers. traffic does not cross border routers.
o Setting up internal routing to steer traffic to these servers/ o Setting up internal routing to steer traffic to these servers/
relays relays
o Setting up of firewalls to allow known and controllable tunneling o Setting up of firewalls to allow known and controllable tunneling
mechanisms and disallow unknown tunnels. mechanisms and disallow unknown tunnels.
8. Acknowledgments 8. 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, Christian Huitema, Brian Jordi Palet Martinez, James Woodyatt, Christian Huitema, Brian
Carpenter, Nathan Ward and Kurt Zeilenga for reviewing earlier Carpenter, Nathan Ward, Kurt Zeilenga, Joel Halpern, Erik Kline,
versions of the document and providing comments to make this document Alfred Hoenes and Fernando Gont for reviewing earlier versions of the
better. The authors would also like to thank Alfred Hoenes for a document and providing comments to make this document better.
careful review of the document.
9. Security Considerations 9. Security Considerations
This entire document discusses security concerns with tunnels. This entire document discusses security concerns with tunnels.
10. IANA Considerations 10. IANA Considerations
There are no actions for IANA in this document. There are no actions for IANA in this document.
11. Informative References 11. Informative References
[I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Transport Protocol Port
Randomization Recommendations",
draft-ietf-tsvwg-port-randomization-06 (work in progress),
February 2010.
[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"",
RFC 2661, August 1999. RFC 2661, August 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. 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 [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.
[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.
[RFC4787] Audet, F. 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 [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.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008. March 2008.
Authors' Addresses [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
James Hoagland [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo
Symantec Corporation Security Updates", RFC 5991, September 2010.
350 Ellis St.
Mountain View, CA 94043
US
Email: Jim_Hoagland@symantec.com [SECA-IP] Gont, F., "Security Assessment of the Internet Protocol
URI: http://symantec.com/ version 4", draft-ietf-opsec-ip-security-03 (work in
progress), April 2010.
[TSV-PORT]
Larsen, M. and F. Gont, "Transport Protocol Port
Randomization Recommendations",
draft-ietf-tsvwg-port-randomization-09 (work in progress),
August 2010.
Authors' Addresses
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Phone: +1 425 703 8835 Phone: +1 425 703 8835
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
James Hoagland
Symantec Corporation
350 Ellis St.
Mountain View, CA 94043
US
Email: Jim_Hoagland@symantec.com
URI: http://symantec.com/
 End of changes. 55 change blocks. 
191 lines changed or deleted 179 lines changed or added

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