draft-ietf-opsec-ipv6-implications-on-ipv4-nets-00.txt   draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01.txt 
Operational Security Capabilities for F. Gont Operational Security Capabilities for F. Gont
IP Network Infrastructure (opsec) UK CPNI IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH
Internet-Draft September 4, 2012 Internet-Draft W. Liu
Intended status: Informational Intended status: Informational Huawei Technologies
Expires: March 8, 2013 Expires: June 15, 2013 December 12, 2012
Security Implications of IPv6 on IPv4 Networks Security Implications of IPv6 on IPv4 Networks
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-00 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01
Abstract Abstract
This document discusses the security implications of native IPv6 This document discusses the security implications of native IPv6
support and IPv6 transition/co-existence technologies on "IPv4-only" support and IPv6 transition/co-existence technologies on "IPv4-only"
networks, and describes possible mitigations for the aforementioned networks, and describes possible mitigations for the aforementioned
issues. issues.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 March 8, 2013. This Internet-Draft will expire on June 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Implications of native IPv6 support . . . . . . . . . 4 2. Security Implications of Native IPv6 Support . . . . . . . . . 4
2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4
3. Security Implications of tunneling Mechanisms . . . . . . . . 6 3. Security Implications of Tunneling Mechanisms . . . . . . . . 6
3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 7 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 7
3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 9 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 9
3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 9 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 9
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol
(TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 11 (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Summary of filtering rules . . . . . . . . . . . . . 17 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Most general-purpose operating systems implement and enable by Most general-purpose operating systems implement and enable by
default native IPv6 [RFC2460] support and a number of transition-co- default native IPv6 [RFC2460] support and a number of transition/
existence technologies. In those cases in which such devices are co-existence technologies. In those cases in which the corresponding
deployed on networks that are assumed to be IPv4-only, the devices are deployed on networks that are assumed to be IPv4-only,
aforementioned technologies could be leveraged by local or remote native IPv6 support and/or IPv6 transition/co-existence technologies
attackers for a number of (illegitimate) purposes. could be leveraged by local or remote attackers for a number of
(illegitimate) purposes. For example,
For example, a Network Intrusion Detection System (NIDS) might be o A Network Intrusion Detection System (NIDS) might be prepared to
prepared to detect attack patterns for IPv4 traffic, but might be detect attack patterns for IPv4 traffic, but might be unable to
unable to detect the same attack patterns when a transition/ detect the same attack patterns when a transition/co-existence
co-existence technology is leveraged for that purpose. Additionally, technology is leveraged for that purpose.
an IPv4 firewall might enforce a specific security policy in IPv4,
but might be unable to enforce the same policy in IPv6. Finally,
some transition/co-existence mechanisms (notably Teredo) are designed
to traverse Network Address Port Translation (NAPT) [RFC2663]
devices, which in many deployments provide a minimum level of
protection by only allowing those instances of communication that
have been initiated from the internal network. Thus, these
mechanisms might cause an internal host with otherwise limited IPv4
connectivity to become globally reachable over IPv6, therefore
resulting in increased (and possibly unexpected) host exposure. That
is, the aforementioned technologies might inadvertently allow
incoming IPv6 connections from the Internet to hosts behind the
organizational firewall.
In general, the aforementioned security implications can be mitigated o An IPv4 firewall might enforce a specific security policy in IPv4,
by enforcing security controls on native IPv6 traffic and on IPv4- but might be unable to enforce the same policy in IPv6.
tunneled traffic. Among such controls is the enforcement of
o Some transition/co-existence mechanisms might cause an internal
host with otherwise limited IPv4 connectivity to become globally
reachable over IPv6, therefore resulting in increased (and
possibly unexpected) host exposure.
Some transition/co-existence mechanisms (notably Teredo) are
designed to traverse Network Address Port Translation (NAPT)
[RFC2663] devices, allowing incoming IPv6 connections from the
Internet to hosts behind the organizational firewall or NAPT
(which in many deployments provides a minimum level of
protection by only allowing those instances of communication
that have been initiated from the internal network).
o IPv6 support might, either inadvertently or as a result of a
deliberate attack, result in VPN traffic leaks if IPv6-unaware
Virtual Private Network (VPN) software is employed by dual-stacked
hosts [I-D.ietf-opsec-vpn-leakages].
In general, most of the aforementioned security implications can be
mitigated by enforcing security controls on native IPv6 traffic and
on IPv4-tunneled traffic. Among such controls is the enforcement of
filtering policies, such that undesirable traffic is blocked. filtering policies, such that undesirable traffic is blocked.
This document discusses the security implications of IPv6 and IPv6 This document discusses the security implications of IPv6 and IPv6
transition/co-existence technologies on (allegedly) IPv4-only transition/co-existence technologies on (allegedly) IPv4-only
networks, and provides guidance on how to mitigate the aforementioned networks, and provides guidance on how to mitigate the aforementioned
issues. issues.
2. Security Implications of native IPv6 support 2. Security Implications of Native IPv6 Support
Most popular operating systems include IPv6 support that is enabled Most popular operating systems include IPv6 support that is enabled
by default. This means that even if a network is expected to be by default. This means that even if a network is expected to be
IPv4-only, much of its infrastructure is nevertheless likely to be IPv4-only, much of its infrastructure is nevertheless likely to be
IPv6 enabled. For example, hosts are likely to have at least link- IPv6 enabled. For example, hosts are likely to have at least link-
local IPv6 connectivity which might be exploited by attackers with local IPv6 connectivity which might be exploited by attackers with
access to the local network. access to the local network.
[CORE2007] is a security advisory about a buffer overflow which [CORE2007] is a security advisory about a buffer overflow which
could be remotely-exploited by leveraging link-local IPv6 could be remotely-exploited by leveraging link-local IPv6
skipping to change at page 4, line 28 skipping to change at page 4, line 28
Additionally, unless appropriate measures are taken, an attacker with Additionally, unless appropriate measures are taken, an attacker with
access to an 'IPv4-only' local network could impersonate a local access to an 'IPv4-only' local network could impersonate a local
router and cause local hosts to enable their 'non-link-local' IPv6 router and cause local hosts to enable their 'non-link-local' IPv6
connectivity (e.g. by sending Router Advertisement messages), connectivity (e.g. by sending Router Advertisement messages),
possibly circumventing security controls that were enforced only on possibly circumventing security controls that were enforced only on
IPv4 communications. IPv4 communications.
[THC-IPV6] is the first publicly-available toolkit that [THC-IPV6] is the first publicly-available toolkit that
implemented this attack vector (along with many others). implemented this attack vector (along with many others).
[IPv6-Toolkit] is a fully-featured trouble-shooting and security
assessment tool that implements this attack vector (along with
many others).
[Waters2011] provides an example of how this could be achieved [Waters2011] provides an example of how this could be achieved
using publicly available tools (besides incorrectly claiming the using publicly available tools (besides incorrectly claiming the
discovery of a "0day vulnerability"). discovery of a "0day vulnerability").
Native IPv6 support could also possibly lead to VPN traffic leakages
when hosts employ VPN software that not only does not support IPv6,
but that does nothing about IPv6 traffic.
[I-D.ietf-opsec-vpn-leakages] describes this issue, along with
possible mitigations.
In general, networks should enforce on native IPv6 traffic the same In general, networks should enforce on native IPv6 traffic the same
security policies they currently enforce on IPv4 traffic. However, security policies they currently enforce on IPv4 traffic. However,
in those networks in which IPv6 has not yet been deployed, and in those networks in which IPv6 has not yet been deployed, and
enforcing the aforementioned policies is deemed as unfeasible, a enforcing the aforementioned policies is deemed as unfeasible, a
network administrator might mitigate IPv6-based attack vectors by network administrator might mitigate IPv6-based attack vectors by
means of appropriate packet filtering. means of appropriate packet filtering.
2.1. Filtering Native IPv6 Traffic 2.1. Filtering Native IPv6 Traffic
Some layer-2 devices might have the ability to selectively filter Some layer-2 devices might have the ability to selectively filter
packets based on the type of layer-2 payload. When such packets based on the type of layer-2 payload. When such
functionality is available, IPv6 traffic could be blocked at those functionality is available, IPv6 traffic could be blocked at those
layer-2 devices by blocking e.g. Ethernet frames with the Protocol layer-2 devices by blocking e.g. Ethernet frames with the Protocol
Type field set to 0x86dd [IANA-ETHER]. Type field set to 0x86dd [IANA-ETHER].
SLAAC-based attacks [RFC3756] can be mitigated with technologies such SLAAC-based attacks [RFC3756] can be mitigated with technologies such
as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a
similar way, DHCPv6-based attacks can be mitigated with technologies similar way, DHCPv6-based attacks can be mitigated with technologies
such as DHCPv6-Shield [I-D.gont-opsec-dhcpv6-shield]. However, such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. However,
neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
employ IPv6 link-local addresses, since configuration of such employ IPv6 link-local addresses, since configuration of such
addresses does not rely on Router Advertisement messages or DCHPv6- addresses does not rely on Router Advertisement messages or DCHPv6-
server messages. server messages.
In order to mitigate attacks based on native IPv6 traffic, IPv6 In order to mitigate attacks based on native IPv6 traffic, IPv6
security controls should be enforced on both IPv4 and IPv6 networks. security controls should be enforced on both IPv4 and IPv6 networks.
The aforementioned controls might include: deploying IPv6-enabled The aforementioned controls might include: deploying IPv6-enabled
NIDS, implementing IPv6 firewalling, etc. NIDS, implementing IPv6 firewalling, etc.
In some very specific scenarios (e.g., military operations In some very specific scenarios (e.g., military operations
networks) in which only IPv4 service might be desired, a network networks) in which only IPv4 service might be desired, a network
administrator might want to disable IPv6 support in all the administrator might want to disable IPv6 support in all the
communicating devices. communicating devices.
3. Security Implications of tunneling Mechanisms 3. Security Implications of Tunneling Mechanisms
Unless properly managed, tunneling mechanisms might result in Unless properly managed, tunneling mechanisms might result in
negative security implications ([RFC6169] describes the security negative security implications ([RFC6169] describes the security
implications of tunneling mechanisms in detail). Therefore, implications of tunneling mechanisms in detail).
tunneling mechanisms should be a concern not only to network
administrators that have consciously deployed them, but also to Of the plethora of tunneling mechanism that have so far been
network and security administrators whose security policies might be standardized and widely implemented, the so-called "automatic
bypassed by exploiting these mechanisms. tunneling" mechanisms (such as Teredo, ISATAP, and 6to4) are of
particular interest from a security standpoint, since they might
be employed without prior consent or action of the user or network
administrator.
Therefore, tunneling mechanisms should be a concern not only to
network administrators that have consciously deployed them, but also
to network and security administrators whose security policies might
be bypassed by exploiting these mechanisms.
[CERT2009] contains some examples of how tunnels can be leveraged [CERT2009] contains some examples of how tunnels can be leveraged
to bypass firewall rules. to bypass firewall rules.
The aforementioned issues could be mitigated by applying the common The aforementioned issues could be mitigated by applying the common
security practice of only allowing traffic deemed as "necessary" security practice of only allowing traffic deemed as "necessary"
(i.e., the so-called "default deny" policy). Thus, when such policy (i.e., the so-called "default deny" policy). Thus, when such policy
is enforced IPv6 transition/co-existence traffic would be blocked by is enforced IPv6 transition/co-existence traffic would be blocked by
default, and would only be allowed as a result of an explicit default, and would only be allowed as a result of an explicit
decision (rather than as a result of lack of awareness about such decision (rather than as a result of lack of awareness about such
skipping to change at page 16, line 18 skipping to change at page 16, line 18
[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.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011. Concerns with IP Tunneling", RFC 6169, April 2011.
[I-D.ietf-v6ops-ra-guard-implementation] [I-D.ietf-v6ops-ra-guard-implementation]
Gont, F., "Implementation Advice for IPv6 Router Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", Advertisement Guard (RA-Guard)",
draft-ietf-v6ops-ra-guard-implementation-04 (work in draft-ietf-v6ops-ra-guard-implementation-07 (work in
progress), May 2012. progress), November 2012.
[I-D.gont-opsec-dhcpv6-shield] [I-D.ietf-opsec-vpn-leakages]
Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Gont, F., "Virtual Private Network (VPN) traffic leakages
Servers", draft-gont-opsec-dhcpv6-shield-00 (work in in dual-stack hosts/ networks",
progress), May 2012. draft-ietf-opsec-vpn-leakages-00 (work in progress),
December 2012.
[I-D.ietf-opsec-dhcpv6-shield]
Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield:
Protecting Against Rogue DHCPv6 Servers",
draft-ietf-opsec-dhcpv6-shield-00 (work in progress),
December 2012.
[IANA-ETHER] [IANA-ETHER]
IANA, "Ether Types", 2012, IANA, "Ether Types", 2012,
<http://www.iana.org/assignments/ethernet-numbers>. <http://www.iana.org/assignments/ethernet-numbers>.
[CERT2009] [CERT2009]
CERT, "Bypassing firewalls with IPv6 tunnels", 2009, <http CERT, "Bypassing firewalls with IPv6 tunnels", 2009, <http
://www.cert.org/blogs/vuls/2009/04/ ://www.cert.org/blogs/vuls/2009/04/
bypassing_firewalls_with_ipv6.html>. bypassing_firewalls_with_ipv6.html>.
[CORE2007] [CORE2007]
CORE, "OpenBSD's IPv6 mbufs remote kernel buffer CORE, "OpenBSD's IPv6 mbufs remote kernel buffer
overflow", 2007, overflow", 2007,
<http://www.coresecurity.com/content/open-bsd-advisorie>. <http://www.coresecurity.com/content/open-bsd-advisorie>.
[CPNI-IPv6] [CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request). National Infrastructure, (available on request).
[IPv6-Toolkit]
"IPv6 Toolkit",
<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/>.
[Waters2011] [Waters2011]
Waters, A., "SLAAC Attack - 0day Windows Network Waters, A., "SLAAC Attack - 0day Windows Network
Interception Configuration Vulnerability", 2011, Interception Configuration Vulnerability", 2011,
<http://resources.infosecinstitute.com/slaac-attack/>. <http://resources.infosecinstitute.com/slaac-attack/>.
Appendix A. Summary of filtering rules Appendix A. Summary of filtering rules
skipping to change at page 18, line 5 skipping to change at page 19, line 5
| TSP | Port 3653) | | TSP | Port 3653) |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
Table 1: Summary of filtering rules Table 1: Summary of filtering rules
NOTE: the table above describes general and simple filtering rules NOTE: the table above describes general and simple filtering rules
for blocking the corresponding traffic. More finer-grained rules for blocking the corresponding traffic. More finer-grained rules
might be available in each of the corresponding sections of this might be available in each of the corresponding sections of this
document. document.
Author's Address Authors' Addresses
Fernando Gont Fernando Gont
UK Centre for the Protection of National Infrastructure SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Email: fernando@gont.com.ar Phone: +54 11 4650 8472
URI: http://www.cpni.gov.uk Email: fgont@si6networks.com
URI: http://www.si6networks.com
Will Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
 End of changes. 22 change blocks. 
53 lines changed or deleted 94 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/