draft-ietf-v6ops-tunnel-security-concerns-03.txt   draft-ietf-v6ops-tunnel-security-concerns-04.txt 
IPv6 Operations Working Group S. Krishnan IPv6 Operations Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational D. Thaler Intended status: Informational D. Thaler
Expires: April 23, 2011 Microsoft Expires: April 28, 2011 Microsoft
J. Hoagland J. Hoagland
Symantec Symantec
October 20, 2010 October 25, 2010
Security Concerns With IP Tunneling Security Concerns With IP Tunneling
draft-ietf-v6ops-tunnel-security-concerns-03 draft-ietf-v6ops-tunnel-security-concerns-04
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 level regarding the security this document is to raise the awareness level regarding the security
issues with IP tunnels as deployed today. issues with IP tunnels as deployed today.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on April 23, 2011. This Internet-Draft will expire on April 28, 2011.
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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
than English. than English.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Inefficiency of Selective Network Filtering of All 3.1. Inefficiency of Selective Network Filtering of All
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 . . . . . . . . . . . . . . . . . 14
6.1. Attacks Facilitated By Changing Tunnel Server Setting . . 14 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 . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . 17 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
skipping to change at page 4, line 19 skipping to change at page 4, line 19
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 to which 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 provide
adequately regulate all traffic. If network controls are being an additional layer of defense against external attackers. If
bypassed due to the use of tunneling, the burden of control shifts to network controls are being bypassed due to the use of tunneling, the
the tunnel client. Since security administrators may not always have strength of the defense (i.e. the number of layers of defense) is
full control over all the nodes on their network, they sometimes reduced. Since security administrators may have a significantly
prefer to implement security controls on the network. reduced level of confidence without this layer, this becomes a
concern to them.
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
firewall' is in use as recommended in [RFC4380]. However, even if is in use as recommended in [RFC4380]. However, even if there are
there are host-based security controls that recognize tunnels, host-based security controls that recognize tunnels, security
security administrators may not have configured them with full administrators may not have configured them with full security
security control parity, even if all controls that were maintained by control parity, even if all controls that were maintained by the
the network are available on the host. Thus there may be gaps in network are available on the host. Thus there may be gaps in desired
desired coverage. 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 device. In addition, hosts behind a stateful firewall. In addition, Section 3.2 discusses
Section 3.2 discusses how it may not be efficient to find all how it may not be efficient to find all tunneled traffic for network
tunneled traffic for network devices to examine. 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 at the perimeter of their network. (hosts) or on the network nodes at the perimeter of their network.
However, there may be an awareness gap. Thus, due to the possible However, there may be an awareness gap. Thus, due to the possible
negative security consequences, tunneling functionality should be negative security consequences, tunneling functionality should be
easy to disable on the host and through a central management facility easy to disable on the host and through a central management facility
if one is provided. if one is provided.
skipping to change at page 5, line 45 skipping to change at page 5, line 46
of a packet and are considered to be a good practice. e.g. ingress of a packet and are considered to be a good practice. e.g. ingress
filtering at the network perimeter should not allow packets with a filtering at the network perimeter should not allow packets with a
source address that belongs to the network to enter the network from source address that belongs to the network to enter the network from
the outside the network. This function is most naturally (and in the the outside the network. This function is most naturally (and in the
general case, by requirement) done at network boundaries. Tunneled general case, by requirement) done at network boundaries. Tunneled
IP traffic bypassing this network control is a specific case of IP traffic bypassing this network control is a specific case of
Section 2.1, but is illustrative. 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 Tunnel servers can apply ingress and egress controls to tunneled IP
specifically, there are three locations in which ingress and egress addresses passing through them to and from tunnel clients.
filtering can be done.
Network based: Network-based devices (e.g., routers) could be
updated to find all tunneled packets and to apply ingress and
egress controls equally to tunneled IP addresses.
Tunnel server based: Tunnel servers can apply ingress and egress
controls to tunneled IP addresses passing through them to and from
tunnel clients.
Host based: Tunnel clients could make an effort to conduct ingress Tunnel clients could make an effort to conduct ingress and egress
and egress filtering. filtering.
Implementations of protocols that embed an IPv4 address in a Implementations of protocols that embed an IPv4 address in a tunneled
tunneled IPv6 address directly between peers should perform IPv6 address directly between peers should perform filtering based on
filtering based on checking the correspondence. 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, relay or protocol peer do filtering the same way as it
done on a native link with traffic from a router. would be done on a native link with traffic from a router.
Some protocols such as 6to4 [RFC3056], Teredo, and ISATAP Some protocols such as 6to4 [RFC3056], Teredo, and ISATAP [RFC5214]
[RFC5214] allow both other hosts and a router over a common allow both other hosts and a router over a common tunnel. To perform
tunnel. To perform host-based filtering with such protocols a host-based filtering with such protocols a host would need to know
host would need to know the outer IP address of each router from the outer IP address of each router from which it could receive
which it could receive traffic, so that packets from hosts beyond traffic, so that packets from hosts beyond the router will be
the router will be accepted even though the source address would accepted even though the source address would not embed the router's
not embed the router's IP address. Router addresses might be IP address. Router addresses might be learned via Secure Neighbor
learned via Secure Neighbor Discovery (SEND) [RFC3971] or some Discovery (SEND) [RFC3971] or some other mechanism (e.g., [RFC5214]
other mechanism (e.g., [RFC5214] section 8.3.2). 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 34 skipping to change at page 7, line 31
not having the capability to disable tunneling 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 of doing this easily for many tunnel protocols is One simple method of doing this easily for many tunnel protocols is
to block outbound packets to the UDP or TCP port used (e.g., to block outbound packets to the UDP or TCP port used (e.g.,
destination UDP port is 3544 for Teredo, UDP port 1701 for L2TP, destination UDP port is 3544 for Teredo, UDP port 1701 for L2TP,
etc.). This prevents a tunnel client from establishing a new tunnel. etc.). This prevents a tunnel client from establishing a new tunnel.
However, existing tunnels will not necessarily be affected if the However, existing tunnels will not necessarily be affected if the
blocked port is used only for initial setup. In addition, if the blocked port is used only for initial setup. In addition, if the
blocking is applied on the outside of the client's NAT device, the blocking is applied on the outside of the client's NAT device, the
NAT device will retain the port mapping for the client and the client NAT device will retain the port mapping for the client. In some
may or may not continue to use the IP address assigned to its tunnel. cases, however, blocking all traffic to a given outbound port (e.g.,
In some cases, however, blocking all traffic to a given outbound port port 80) may interfere with non-tunneled traffic so this should be
(e.g., port 80) may interfere with non-tunneled traffic so this 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
is discussed there. is discussed there.
3.1.3. Recommendations 3.1.3. Recommendations
Tunneling over UDP or TCP (including HTTP) to reach the Internet is Developers of protocols that tunnel over UDP or TCP (including HTTP)
not recommended for use in networks that wish to enforce security to reach the Internet should disable their protocols in networks that
policies on the user traffic. (Windows, for example, disables Teredo wish to enforce security policies on the user traffic. (Windows, for
by default if it detects that it is within an enterprise network that example, disables Teredo by default if it detects that it is within
contains a Windows domain controller.) 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. Similarly, in certain cases, it is traffic with that source port. Similarly, in certain cases, it is
also possible to use the IP protocol field to identify and filter also possible to use the IP protocol field to identify and filter
tunneled packets. e.g. 6to4 [RFC3056] is a tunneling mechanism that tunneled packets. e.g. 6to4 [RFC3056] is a tunneling mechanism that
skipping to change at page 12, line 42 skipping to change at page 12, line 37
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
would face more challenges in seeing any returned traffic. would face more challenges in seeing any returned traffic.
4.3.3. Recommendations 4.3.3. Recommendations
Minimizing public tunnel use (see Section 4.1.3) would lower the If the tunnel can provide connectivity to the Internet, the tunnel
client should run a host firewall on the tunnel interface. Also,
minimizing public tunnel use (see Section 4.1.3) would lower the
attack opportunity related to this exposure. attack opportunity related to this exposure.
5. Tunnel Address Concerns 5. Tunnel Address Concerns
5.1. Feasibility of Guessing Tunnel Addresses 5.1. Feasibility of Guessing Tunnel Addresses
5.1.1. Problem 5.1.1. Problem
For some types of tunneling protocols, it may be feasible to guess IP For some types of tunneling protocols, it may be feasible to guess IP
addresses assigned to tunnels, either when looking for a specific addresses assigned to tunnels, either when looking for a specific
client or when looking for an arbitrary client. This is in contrast client or when looking for an arbitrary client. This is in contrast
to native IPv6 addresses in general, but is no worse than for native to native IPv6 addresses in general, but is no worse than for native
IPv4 addresses today. IPv4 addresses today.
For example, some protocols (e.g., 6to4 and Teredo) use well-defined For example, some protocols (e.g., 6to4 and Teredo) use well-defined
address ranges. As another example, using well-known public servers address ranges. As another example, using well-known public servers
skipping to change at page 16, line 49 skipping to change at page 16, line 40
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;
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. Please
refer to Section 3 of [TUNNEL-LOOPS] for a detailed description and
mitigation measures for a class of attacks based on IPv6 automatic
tunnels.
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 [RFC2979] to allow known and controllable
mechanisms and disallow unknown tunnels. tunneling 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, Kurt Zeilenga, Joel Halpern, Erik Kline, Carpenter, Nathan Ward, Kurt Zeilenga, Joel Halpern, Erik Kline,
Alfred Hoenes and Fernando Gont for reviewing earlier versions of the Alfred Hoenes and Fernando Gont for reviewing earlier versions of the
document and providing comments to make this document better. document and providing comments to make this document better.
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. This document does not require any IANA action.
11. Informative References 11. Informative References
[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.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000.
[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.
[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
skipping to change at page 19, line 5 skipping to change at page 18, line 50
[SECA-IP] Gont, F., "Security Assessment of the Internet Protocol [SECA-IP] Gont, F., "Security Assessment of the Internet Protocol
version 4", draft-ietf-opsec-ip-security-03 (work in version 4", draft-ietf-opsec-ip-security-03 (work in
progress), April 2010. progress), April 2010.
[TSV-PORT] [TSV-PORT]
Larsen, M. and F. Gont, "Transport Protocol Port Larsen, M. and F. Gont, "Transport Protocol Port
Randomization Recommendations", Randomization Recommendations",
draft-ietf-tsvwg-port-randomization-09 (work in progress), draft-ietf-tsvwg-port-randomization-09 (work in progress),
August 2010. August 2010.
[TUNNEL-LOOPS]
Nakibly, G. and F. Templin, "Routing Loop Attack using
IPv6 Automatic Tunnels: Problem Statement and Proposed
Mitigations", draft-ietf-v6ops-tunnel-loops-00 (work in
progress), September 2010.
Authors' Addresses 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
 End of changes. 23 change blocks. 
65 lines changed or deleted 71 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/