draft-ietf-opsec-vpn-leakages-03.txt   draft-ietf-opsec-vpn-leakages-04.txt 
Operational Security Capabilities for F. Gont opsec F. Gont
IP Network Infrastructure (opsec) Huawei Technologies Internet-Draft Huawei Technologies
Internet-Draft January 23, 2014 Intended status: Informational March 3, 2014
Intended status: Informational Expires: September 4, 2014
Expires: July 27, 2014
Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ Virtual Private Network (VPN) traffic leakages in dual-stack hosts/
networks networks
draft-ietf-opsec-vpn-leakages-03 draft-ietf-opsec-vpn-leakages-04
Abstract Abstract
The subtle way in which the IPv6 and IPv4 protocols co-exist in The subtle way in which the IPv6 and IPv4 protocols co-exist in
typical networks, together with the lack of proper IPv6 support in typical networks, together with the lack of proper IPv6 support in
popular Virtual Private Network (VPN) products, may inadvertently popular Virtual Private Network (VPN) products, may inadvertently
result in VPN traffic leaks. That is, traffic meant to be result in VPN traffic leaks. That is, traffic meant to be
transferred over a VPN connection may leak out of such connection and transferred over an encrypted and integrity protected VPN connection
be transferred in the clear from the local network to the final may leak out of such connection and be sent in the clear on the local
destination. This document discusses some scenarios in which such network towards the final destination. This document discusses some
VPN leakages may occur, either as a side effect of enabling IPv6 on a scenarios in which such VPN leakages may occur as a result of
local network, or as a result of a deliberate attack from a local employing IPv6-unaware VPN software. Additionally, this document
attacker. Additionally, it discusses possible mitigations for the offers possible mitigations for this issue.
aforementioned issue.
Status of this Memo Status of This Memo
This Internet-Draft is submitted 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). 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 July 27, 2014. This Internet-Draft will expire on September 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . . 5 3. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . 4
4. Virtual Private Networks in IPv4/IPv6 dual-stack 4. Virtual Private Networks in IPv4/IPv6 dual-stack
hosts/networks . . . . . . . . . . . . . . . . . . . . . . . . 6 hosts/networks . . . . . . . . . . . . . . . . . . . . . . . 4
5. Inadvertent VPN traffic-leakages in legitimate scenarios . . . 7 5. Inadvertent VPN traffic-leakages in legitimate scenarios . . 5
6. VPN traffic-leakage attacks . . . . . . . . . . . . . . . . . 8 6. VPN traffic-leakage attacks . . . . . . . . . . . . . . . . . 5
7. Mitigations to VPN traffic-leakage vulnerabilities . . . . . . 9 7. Mitigations to VPN traffic-leakage vulnerabilities . . . . . 6
7.1. Fixing VPN client software . . . . . . . . . . . . . . . . 9 7.1. Fixing VPN client software . . . . . . . . . . . . . . . 6
7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 10 7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
It is a very common practice for employees working at remote It is a very common practice for users to employ VPN software when
locations to establish a VPN connection with their office or home employing a public (and possibly-rogue) local network. This is
office. This is typically done to gain access to some resources only typically done not only to gain access to remote resources may not
available within the company's network, but also to secure the host's otherwise accessible from the public Internet, but also to secure the
traffic against attackers that might be connected to the same remote host's traffic against attackers that might be connected to the same
location. The same is true for mobile nodes that establish VPN local network as the victim host. The latter case constitutes the
connections to secure their traffic while they roam from one network problem space of this document. Indeed, it is sometimes assumed that
to another. In some scenarios, it is even assumed that employing a employing a VPN connection makes the use of insecure protocols (e.g.,
VPN connection makes the use of insecure protocols (e.g. that that transfer sensitive information in the clear) acceptable, as a
transfer sensitive information in the clear) acceptable, as the VPN VPN provides security services (such as data integrity and/or
provides security services (such as data integrity and/or confidentiality) for all communications made over that VPN. However,
confidentiality) for all communications made over the VPN. this document illustrates that under certain circumstances, some
traffic might not be mapped onto the VPN and thus be sent in the
clear on the local network.
Many VPN products that are typically employed for the aforementioned Many VPN products that are typically employed for the aforementioned
VPN connections only support the IPv4 protocol: that is, they perform VPN connections only support the IPv4 protocol: that is, they perform
the necessary actions such that IPv4 traffic is sent over the VPN the necessary actions such that IPv4 traffic is sent over the VPN
connection, but they do nothing to secure IPv6 traffic originated connection, but they do nothing to secure IPv6 traffic originated
from (or being received at) the host employing the VPN client. from (or being received at) the host employing the VPN client.
However, the hosts themselves are typically dual-stacked: they However, the hosts themselves are typically dual-stacked: they
support (and enable by default) both IPv4 and IPv6 (even if such IPv6 support (and enable by default) both IPv4 and IPv6 (even if such IPv6
connectivity is simply "dormant" when they connect to IPv4-only connectivity is simply "dormant" when they connect to IPv4-only
networks). When the IPv6 connectivity of such hosts is enabled, they networks). When the IPv6 connectivity of such hosts is enabled, they
skipping to change at page 4, line 7 skipping to change at page 3, line 31
Section 3 provides some background about IPv6 and IPv4 co-existence, Section 3 provides some background about IPv6 and IPv4 co-existence,
summarizing how IPv6 and IPv4 interact on a typical dual-stacked summarizing how IPv6 and IPv4 interact on a typical dual-stacked
network. Section 4 describes the underlying problem that leads to network. Section 4 describes the underlying problem that leads to
the aforementioned VPN traffic leakages. Section 5 describes the aforementioned VPN traffic leakages. Section 5 describes
legitimate scenarios in which such traffic leakages might occur, legitimate scenarios in which such traffic leakages might occur,
while Section 6 describes how VPN traffic leakages can be triggered while Section 6 describes how VPN traffic leakages can be triggered
by deliberate attacks. by deliberate attacks.
2. Terminology 2. Terminology
When employing the term VPN (or its acronym, "VPN"), this document When employing the term "Virtual Private Network" (or its acronym,
refers to IPsec-based or TLS-based tunnels, where traffic is "VPN"), this document refers to IPsec-based or TLS-based tunnels,
encapsulated and sent from a client to a middle-box, to access where traffic is encapsulated and sent from a client to a middle-box,
multiple network services (potentially emplying different transport to access multiple network services (possibly employing different
and/or application protocols). transport and/or application protocols).
Our use of the term "Virtual Private Networks" excludes the so-called Our use of the term "Virtual Private Networks" excludes the so-called
SSL/TLS VPN portals (a front-end provided by the middlebox to add SSL/TLS VPN portals (a front-end provided by the middlebox to add
security to a normally-unsecured site). Further discussion of SSL- security to a normally-unsecured site). Further discussion of SSL-
based VPNs can be found in [SSL-VPNs]. based VPNs can be found in [SSL-VPNs].
We note that, in addition to the general case of "send all traffic We note that, in addition to the general case of "send all traffic
through the VPN", this document additionally considers the so-called through the VPN", this document additionally considers the so-called
"split-tunnel" case, where some subset of the traffic is sent through "split-tunnel" case, where some subset of the traffic is sent through
the VPN, while other traffic is send to its intended destination with the VPN, while other traffic is send to its intended destination with
skipping to change at page 5, line 10 skipping to change at page 4, line 12
goes through a gateway with protections (malware detection, URL goes through a gateway with protections (malware detection, URL
filtering, etc.), but others are more interested in performance of filtering, etc.), but others are more interested in performance of
the user's access or the ability for researchers to have options to the user's access or the ability for researchers to have options to
access sites they may not be able to through the gateway. access sites they may not be able to through the gateway.
3. IPv4 and IPv6 co-existence 3. IPv4 and IPv6 co-existence
The co-existence of the IPv4 and IPv6 protocols has a number of The co-existence of the IPv4 and IPv6 protocols has a number of
interesting and subtle aspects that may have "surprising" interesting and subtle aspects that may have "surprising"
consequences. While IPv6 is not backwards-compatible with IPv4, the consequences. While IPv6 is not backwards-compatible with IPv4, the
two protocols are "tied" together by the Domain Name System (DNS). two protocols are "glued" together by the Domain Name System (DNS).
For example, consider a site (say, www.example.com) that has both For example, consider a site (say, www.example.com) that has both
IPv4 and IPv6 support. The corresponding domain name IPv4 and IPv6 support. The corresponding domain name
(www.example.com, in our case) will contain both A and AAAA DNS (www.example.com, in our case) will contain both A and AAAA DNS
resource records (RRs). Each A record will contain one IPv4 address, resource records (RRs). Each A record will contain one IPv4 address,
while each AAAA record will contain one IPv6 address -- and there while each AAAA record will contain one IPv6 address -- and there
might be more than one instance of each of these record types. Thus, might be more than one instance of each of these record types. Thus,
when a dual-stacked client application means to communicate with when a dual-stacked client application means to communicate with
www.example.com, it can request both A and AAAA records, and use any www.example.com, it can request both A and AAAA records, and use any
of the available addresses. The preferred address family (IPv4 or of the available addresses. The preferred address family (IPv4 or
IPv6) and the specific address that will be used (assuming more than IPv6) and the specific address that will be used (assuming more than
one address of each family is available) varies from one protocol one address of each family is available) varies from one protocol
implementation to another, with many host implementations preferring implementation to another, with many host implementations preferring
IPv6 addresses over IPv4 addresses. IPv6 addresses over IPv4 addresses.
[RFC6724] specifies an algorithm for selecting a destination NOTE: [RFC6724] specifies an algorithm for selecting a destination
address from a list of IPv6 and IPv4 addresses. [RFC6555] address from a list of IPv6 and IPv4 addresses. [RFC6555]
discusses the challenge of selecting the most appropriate discusses the challenge of selecting the most appropriate
destination address, along with a proposed implementation approach destination address, along with a proposed implementation approach
that mitigates connection-establishment delays. that mitigates connection-establishment delays.
As a result of this "co-existence" between IPv6 and IPv4, when a As a result of this "co-existence" between IPv6 and IPv4, when a
dual-stacked client means to communicate with some other system, the dual-stacked client means to communicate with some other system, the
availability of A and AAAA DNS resource records will typically affect availability of A and AAAA DNS resource records will typically affect
which protocol is employed to communicate with that system. which protocol is employed to communicate with that system.
skipping to change at page 6, line 18 skipping to change at page 5, line 5
IPv6 protocol -- or, what is worse, they completely ignore IPv6. IPv6 protocol -- or, what is worse, they completely ignore IPv6.
This typically means that, when establishing a VPN connection, the This typically means that, when establishing a VPN connection, the
VPN software takes care of the IPv4 connectivity by, e.g. inserting VPN software takes care of the IPv4 connectivity by, e.g. inserting
an IPv4 default route that causes all IPv4 traffic to be sent over an IPv4 default route that causes all IPv4 traffic to be sent over
the VPN connection (as opposed to sending the traffic in the clear, the VPN connection (as opposed to sending the traffic in the clear,
employing the local router). However, if IPv6 is not supported (or employing the local router). However, if IPv6 is not supported (or
completely ignored), any packets destined to an IPv6 address will be completely ignored), any packets destined to an IPv6 address will be
sent in the clear using the local IPv6 router. That is, the VPN sent in the clear using the local IPv6 router. That is, the VPN
software will do nothing about the IPv6 traffic. software will do nothing about the IPv6 traffic.
The underlying problem here is that while IPv4 and IPv6 are two The underlying reason for which these VPN leakages may occur is that,
different protocols incompatible with each other, the two protocols while IPv4 and IPv6 are two different protocols incompatible with
are glued together by the Domain Name System. Therefore, for dual- each other, the two protocols are "glued" together by the Domain Name
stacked systems, it is not possible to secure the communication with System. Therefore, for dual-stacked systems, it is not possible to
another system without securing both protocols (IPv6 and IPv4). secure the communication with another system without securing both
protocols (IPv6 and IPv4).
5. Inadvertent VPN traffic-leakages in legitimate scenarios 5. Inadvertent VPN traffic-leakages in legitimate scenarios
Consider a dual-stacked host that employs IPv4-only VPN software to Consider a dual-stacked host that employs IPv4-only VPN software to
establish a VPN connection with a VPN server, and that such host now establish a VPN connection with a VPN server, and that such host now
connects to a dual-stacked network (that provides both IPv6 and IPv4 connects to a dual-stacked network (that provides both IPv6 and IPv4
connectivity). If some application on the client means to connectivity). If some application on the client means to
communicate with a dual-stacked destination, the client will communicate with a dual-stacked destination, the client will
typically query both A and AAAA DNS resource records. Since the host typically query both A and AAAA DNS resource records. Since the host
will have both IPv4 and IPv6 connectivity, and the intended will have both IPv4 and IPv6 connectivity, and the intended
destination will have both A and AAAA DNS resource records, one of destination will have both A and AAAA DNS resource records, one of
the possible outcomes is that the host will employ IPv6 to the possible outcomes is that the host will employ IPv6 to
communicate with the intended destination. Since the VPN software communicate with the intended destination. Since the VPN software
does not support IPv6, the IPv6 traffic will not employ the VPN does not support IPv6, the IPv6 traffic will not employ the VPN
connection, and hence will have neither integrity nor confidentiality connection, and hence will have neither integrity nor confidentiality
protection from the source host to the final destination. protection from the source host to the final destination.
This could inadvertently expose sensitive traffic that was assumed to This could inadvertently expose sensitive traffic that was assumed to
be secured by the VPN software. In this particular scenario, the be secured by the VPN software. In this particular scenario, the
resulting VPN traffic leakage is a side-effect of employing IPv6- resulting VPN traffic leakage is a side-effect of employing
unaware VPN software in a dual-stacked host/network. IPv6-unaware VPN software in a dual-stacked host/network.
6. VPN traffic-leakage attacks 6. VPN traffic-leakage attacks
A local attacker could deliberately trigger IPv6 connectivity on the A local attacker could deliberately trigger IPv6 connectivity on the
victim host by sending forged ICMPv6 Router Advertisement messages victim host by sending forged ICMPv6 Router Advertisement messages
[RFC4861]. Such packets could be sent by employing standard software [RFC4861]. Such packets could be sent by employing standard software
such as rtadvd [RTADVD], or by employing packet-crafting tools such such as rtadvd [RTADVD], or by employing packet-crafting tools such
as [SI6-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity has as [SI6-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity has
been enabled, communications with dual-stacked systems could result been enabled, communications with dual-stacked systems could result
in VPN traffic leakages, as previously described. in VPN traffic leakages, as previously described.
skipping to change at page 8, line 24 skipping to change at page 6, line 4
While this attack may be useful enough (due to the increasing number While this attack may be useful enough (due to the increasing number
of IPv6-enabled sites), it will only lead to traffic leakages when of IPv6-enabled sites), it will only lead to traffic leakages when
the destination system is dual-stacked. However, it is usually the destination system is dual-stacked. However, it is usually
trivial for an attacker to trigger such VPN leakages for any trivial for an attacker to trigger such VPN leakages for any
destination systems: an attacker could simply advertise himself as destination systems: an attacker could simply advertise himself as
the local recursive DNS server by sending forged Router Advertisement the local recursive DNS server by sending forged Router Advertisement
messages [RFC4861] that include the corresponding RDNSS option messages [RFC4861] that include the corresponding RDNSS option
[RFC6106], and then perform a DNS spoofing attack such that he can [RFC6106], and then perform a DNS spoofing attack such that he can
become a "Man in the Middle" and intercept the corresponding traffic. become a "Man in the Middle" and intercept the corresponding traffic.
As with the previous attack scenario, packet-crafting tools such as As with the previous attack scenario, packet-crafting tools such as
[SI6-Toolkit] and [THC-IPv6] can readily perform this attack. [SI6-Toolkit] and [THC-IPv6] can readily perform this attack.
Some systems are known to prefer IPv6-based recursive DNS servers NOTE: Some systems are known to prefer IPv6-based recursive DNS
over IPv4-based ones, and hence the "malicious" recursive DNS servers over IPv4-based ones, and hence the "malicious" recursive
servers would be preferred over the legitimate ones advertised by DNS servers would be preferred over the legitimate ones advertised
the VPN server. by the VPN server.
7. Mitigations to VPN traffic-leakage vulnerabilities 7. Mitigations to VPN traffic-leakage vulnerabilities
7.1. Fixing VPN client software 7.1. Fixing VPN client software
There are a number of possible mitigations for the VPN traffic- There are a number of possible mitigations for the VPN traffic-
leakage vulnerability discussed in this document. leakage vulnerability discussed in this document.
If the VPN client is configured by administrative decision to If the VPN client is configured by administrative decision to
redirect all IPv4 traffic to the VPN, it should: redirect all IPv4 traffic to the VPN, it should:
1. If IPv6 is not supported in the VPN software, disable IPv6 1. If IPv6 is not supported in the VPN software, disable IPv6
support in all network interfaces. support in all network interfaces.
For IPv6-unaware VPN clients, the most simple mitigation NOTE: For IPv6-unaware VPN clients, the most simple mitigation
(although not necessarily the most desirable one) would be to (although not necessarily the most desirable one) would be to
disable IPv6 support in all network interface cards when a VPN disable IPv6 support in all network interface cards when a VPN
connection is meant to be employed. Thus, applications on the connection is meant to be employed. Thus, applications on the
host running the VPN client software will have no other option host running the VPN client software will have no other option
than to employ IPv4, and hence they will simply not even try than to employ IPv4, and hence they will simply not even try
to send/process IPv6 traffic. to send/process IPv6 traffic.
2. If IPv6 is supported in the VPN software, ensure that all IPv6 2. If IPv6 is supported in the VPN software, ensure that all IPv6
traffic is also sent via the VPN. traffic is also sent via the VPN.
skipping to change at page 10, line 5 skipping to change at page 7, line 13
Redirect messages, etc. Redirect messages, etc.
A network may prevent local attackers from successfully performing A network may prevent local attackers from successfully performing
the aforementioned attacks against other local hosts by implementing the aforementioned attacks against other local hosts by implementing
First-Hop Security solutions such as Router Advertisement Guard (RA- First-Hop Security solutions such as Router Advertisement Guard (RA-
Guard) [RFC6105] and DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. Guard) [RFC6105] and DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield].
However, for obvious reasons, a host cannot and should not rely on However, for obvious reasons, a host cannot and should not rely on
this type of mitigations when connecting to an open network this type of mitigations when connecting to an open network
(cybercafe, etc.). (cybercafe, etc.).
Besides, popular implementations of RA-Guard are known to be NOTE: Besides, popular implementations of RA-Guard are known to be
vulnerable to evasion attacks vulnerable to evasion attacks [RFC7113].
[I-D.ietf-v6ops-ra-guard-implementation].
Finally, we note that if (eventually) IPv6-only VPN implementations Finally, we note that if (eventually) IPv6-only VPN implementations
become available, they should consider similar issues that would become available, similar issues to the ones discussed in this
arise if they do nothing about the IPv4 traffic. document could arise if these IPv6-only VPN implementations do
nothing about the IPv4 traffic.
7.2. Operational Mitigations 7.2. Operational Mitigations
While the desired mtigation for the issues discussed in this document While the desired mitigation for the issues discussed in this
is for VPN clients to be IPv6-aware, we note that in scenarios where document is for VPN clients to be IPv6-aware, we note that in
tthis would be unfeasible, and administrator may want to disable IPv6 scenarios where this would be unfeasible, and administrator may want
connectivity on all network interfaces of the node employing the to disable IPv6 connectivity on all network interfaces of the node
IPv6-unaware VPN client. employing the IPv6-unaware VPN client.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Security Considerations 9. Security Considerations
This document discusses how traffic meant to be transferred over a This document discusses how traffic meant to be transferred over a
VPN connection can leak out of the VPN, and hence appear in the clear VPN connection can leak out of the VPN, and hence appear in the clear
on the local network. This is the result of employing IPv6-unaware on the local network. This is the result of employing IPv6-unaware
VPN client software on dual-stacked hosts. VPN client software on dual-stacked hosts.
Possible ways to mitigate this problem include fixing the VPN client Possible ways to mitigate this problem include fixing the VPN client
software, or disabling IPv6 connectivity on all network interfaces software, or disabling IPv6 connectivity on all network interfaces
when the previous option is not feasible. when the previous option is not feasible.
10. Acknowledgements 10. Acknowledgements
The author would like to thank (in alphabetical order) Gert Doering The author of this document would like to thank (in alphabetical
and Tor Houghton, who providing comments on earlier versions of this order) Cameron Byrne, Spencer Dawkins, Gert Doering, Stephen Farrell,
document. Seth Hall, Paul Hoffman, Tor Houghton, Russ Housley, Joel Jaeggli,
Alastair Johnson, Merike Kaeo, Panos Kampanakis, Warren Kumari,
This documents has benefited from the input of Cameron Byrne, Gert Henrik Lund Kramshoj, Barry Leiba, Kathleen Moriarty, Thomas
Doering, Seth Hall, Paul Hoffman, Tor Houghton, Joel Jaeggli, Osterried, Jim Small, Martin Vigoureux, and Andrew Yourtchenko for
Alastair Johnson, Merike Kaeo, Panos Kampanakis, Henrik Lund providing valuable comments on earlier versions of this document.
Kramshoj, Kathleen Moriarty, Thomas Osterried, and Jim Small, while
discussing this topic on the ipv6hackers mailing-list [IPv6-Hackers].
It has also benefited from discussions with Andrew Yourtchenko on the
opsec wg mailing-list [OPSEC-LIST].
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
skipping to change at page 14, line 33 skipping to change at page 8, line 33
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
11.2. Informative References 11.2. Informative References
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
[I-D.ietf-v6ops-ra-guard-implementation] [RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, February 2014.
Advertisement Guard (RA-Guard)",
draft-ietf-v6ops-ra-guard-implementation-07 (work in
progress), November 2012.
[I-D.ietf-opsec-dhcpv6-shield] [I-D.ietf-opsec-dhcpv6-shield]
Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: Gont, F., Will, W., and G. Velde, "DHCPv6-Shield:
Protecting Against Rogue DHCPv6 Servers", Protecting Against Rogue DHCPv6 Servers", draft-ietf-
draft-ietf-opsec-dhcpv6-shield-01 (work in progress), opsec-dhcpv6-shield-02 (work in progress), February 2014.
October 2013.
[IPv6-Hackers]
"IPv6 Hackers mailing-list",
http://lists.si6networks.com/listinfo/ipv6hackers/.
[OPSEC-LIST]
"OPSEC WG mailing-list",
https://www.ietf.org/mailman/listinfo/opsec.
[SI6-Toolkit] [SI6-Toolkit]
"SI6 Networks' IPv6 toolkit", "SI6 Networks' IPv6 toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>. <http://www.si6networks.com/tools/ipv6toolkit>.
[THC-IPv6] [THC-IPv6]
"The Hacker's Choice IPv6 Attack Toolkit", "The Hacker's Choice IPv6 Attack Toolkit",
<http://www.thc.org/thc-ipv6/>. <http://www.thc.org/thc-ipv6/>.
[RTADVD] "rtadvd(8) manual page", <http://www.freebsd.org/cgi/ [RTADVD] "rtadvd(8) manual page", <http://www.freebsd.org/cgi/
man.cgi?query=rtadvd&sektion=8>. man.cgi?query=rtadvd&sektion=8>.
[SSL-VPNs] [SSL-VPNs]
Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72, Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72,
SAAG Meeting., 2008, SAAG Meeting., 2008,
<http://www.ietf.org/proceedings/72/slides/saag-4.pdf>. <http://www.ietf.org/proceedings/72/slides/saag-4.pdf>.
Author's Address Author's Address
Fernando Gont Fernando Gont
Huawei Technologies Huawei Technologies
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
 End of changes. 23 change blocks. 
100 lines changed or deleted 86 lines changed or added

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