draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04.txt   draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.txt 
Operational Security Capabilities for F. Gont Operational Security Capabilities for F. Gont
IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH
Internet-Draft W. Liu Internet-Draft W. Liu
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: November 3, 2013 May 2, 2013 Expires: January 6, 2014 July 5, 2013
Security Implications of IPv6 on IPv4 Networks Security Implications of IPv6 on IPv4 Networks
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05
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 November 3, 2013. This Internet-Draft will expire on January 6, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 3, line 11 skipping to change at page 3, line 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Summary of filtering rules . . . . . . . . . . . . . 22 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Most general-purpose operating systems implement and enable native Most general-purpose operating systems implement and enable native
IPv6 [RFC2460] support and a number of transition/co-existence IPv6 [RFC2460] support and a number of transition/co-existence
technologies by default. Support of IPv6 by all nodes is intended to technologies by default. Support of IPv6 by all nodes is intended to
become best current practice [RFC6540]. Some enterprise networks become best current practice [RFC6540]. Some enterprise networks
might, however, choose to delay active use of IPv6. In scenarios in might, however, choose to delay active use of IPv6.
which the aforementioned devices are deployed on networks that are
assumed to be IPv4-only, native IPv6 support and/or IPv6 transition/ This document describes operational practices for enterprise networks
co-existence technologies could be leveraged by local or remote to prevent security exposure resulting from unplanned use of IPv6 on
attackers for a number of (illegitimate) purposes. For example, such networks. This document is only applicable to enterprise
networks: networks where the network operator is not providing a
general-purpose internet, but rather a business-specific network.
The solutions proposed here are not practical for home networks, nor
are they appropriate for provider networks such as ISPs, mobile
providers, Wifi hotspot providers or any other public internet
service.
In scenarios in which IPv6-enabled devices are deployed on enterprise
networks that are intended to be IPv4-only, native IPv6 support
and/or IPv6 transition/co-existence technologies could be leveraged
by local or remote attackers for a number of (illegitimate) purposes.
For example,
o A Network Intrusion Detection System (NIDS) might be prepared to o A Network Intrusion Detection System (NIDS) might be prepared to
detect attack patterns for IPv4 traffic, but might be unable to detect attack patterns for IPv4 traffic, but might be unable to
detect the same attack patterns when a transition/co-existence detect the same attack patterns when a transition/co-existence
technology is leveraged for that purpose. technology is leveraged for that purpose.
o An IPv4 firewall might enforce a specific security policy in IPv4, o An IPv4 firewall might enforce a specific security policy in IPv4,
but might be unable to enforce the same policy in IPv6. but might be unable to enforce the same policy in IPv6.
o A NIDS or firewall might support both IPv4 and IPv6, but might be o A NIDS or firewall might support both IPv4 and IPv6, but might be
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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
could be remotely-exploited by leveraging link-local IPv6
connectivity that is enabled by default.
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] and [IPv6-Toolkit] include tools that implement this [THC-IPV6] and [IPv6-Toolkit] include tools that implement this
attack vector (along with many others). attack vector (along with many others).
skipping to change at page 5, line 50 skipping to change at page 5, line 46
the aforementioned policies is deemed as unfeasible, a network the aforementioned policies is deemed as unfeasible, a network
administrator might mitigate IPv6-based attack vectors by means of administrator might mitigate IPv6-based attack vectors by means of
appropriate packet filtering. 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, for example, Ethernet frames with the layer-2 devices by blocking, for example, Ethernet frames with the
Protocol Type field set to 0x86dd [IANA-ETHER]. Protocol Type field set to 0x86dd [IANA-ETHER]. We note, however,
that enforcement of such filtering policy would break applications
that expect IPv6 link-local connectivity to work properly (e.g.
Bonjour).
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.ietf-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.
skipping to change at page 14, line 29 skipping to change at page 14, line 29
"provide" native IPv6 service on a given network without proper "provide" native IPv6 service on a given network without proper
upstream IPv6 connectivity may result in hosts attempting to reach upstream IPv6 connectivity may result in hosts attempting to reach
remote nodes via IPv6, and depending on the absence or presence and remote nodes via IPv6, and depending on the absence or presence and
specific implementation details of "Happy Eyeballs" [RFC6555], there specific implementation details of "Happy Eyeballs" [RFC6555], there
might be a non-trivial timeout period before the host falls back to might be a non-trivial timeout period before the host falls back to
IPv4 [Huston2010a] [Huston2012]. IPv4 [Huston2010a] [Huston2012].
For this reason, networks attempting to prevent IPv6 traffic from For this reason, networks attempting to prevent IPv6 traffic from
traversing their devices should consider configuring their local traversing their devices should consider configuring their local
recursive DNS servers to respond to queries for AAAA DNS records with recursive DNS servers to respond to queries for AAAA DNS records with
a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such
queries, and should even consider filtering AAAA records at the queries, and should even consider filtering AAAA records at the
network ingress point to prevent the internal hosts from attempting network ingress point to prevent the internal hosts from attempting
their own DNS resolution. This will ensure that hosts which are on their own DNS resolution. This will ensure that hosts which are on
an IPv4-only network will only receive DNS A records, and they will an IPv4-only network will only receive DNS A records, and they will
be unlikely to attempt to use (likely broken) IPv6 connectivity to be unlikely to attempt to use (likely broken) IPv6 connectivity to
reach their desired destinations. reach their desired destinations.
Additionally, it should be noted that when filtering IPv6 traffic, it Additionally, it should be noted that when filtering IPv6 traffic, it
is good practice to signal the packet drop to the source node, such is good practice to signal the packet drop to the source node, such
that it is able to react to the packet drop in a more appropriate and that it is able to react to the packet drop in a more appropriate and
skipping to change at page 17, line 11 skipping to change at page 17, line 11
traffic the same security policies currently enforced for IPv4 traffic the same security policies currently enforced for IPv4
traffic, and/or blocking the aforementioned traffic when it is deemed traffic, and/or blocking the aforementioned traffic when it is deemed
as undesirable. as undesirable.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Wes George, who contributed most of The authors would like to thank Wes George, who contributed most of
the text that comprises Section 4 of this document. the text that comprises Section 4 of this document.
The authors would like to thank (in alphabetical order) Ran Atkinson, The authors would like to thank (in alphabetical order) Ran Atkinson,
Brian Carpenter, Joel Jaeggli, Panos Kampanakis, Warren Kumari, David Brian Carpenter, Stephen Farrell, Joel Jaeggli, Panos Kampanakis,
Malone, Joseph Salowey, Arturo Servin, Donald Smith, Tina Tsou, and Warren Kumari, Ted Lemon, David Malone, Joseph Salowey, Arturo
Eric Vyncke, for providing valuable comments on earlier versions of Servin, Donald Smith, Tina Tsou, and Eric Vyncke, for providing
this document. valuable comments on earlier versions of this document.
This document is based on the results of the the project "Security This document is based on the results of the the project "Security
Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6],
carried out by Fernando Gont on behalf of the UK Centre for the carried out by Fernando Gont on behalf of the UK Centre for the
Protection of National Infrastructure (CPNI). Fernando Gont would Protection of National Infrastructure (CPNI). Fernando Gont would
like to thank the UK CPNI for their continued support. like to thank the UK CPNI for their continued support.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 20, line 6 skipping to change at page 20, line 6
[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-07 (work in draft-ietf-v6ops-ra-guard-implementation-07 (work in
progress), November 2012. progress), November 2012.
[I-D.ietf-opsec-vpn-leakages] [I-D.ietf-opsec-vpn-leakages]
Gont, F., "Virtual Private Network (VPN) traffic leakages Gont, F., "Virtual Private Network (VPN) traffic leakages
in dual-stack hosts/ networks", in dual-stack hosts/ networks",
draft-ietf-opsec-vpn-leakages-00 (work in progress), draft-ietf-opsec-vpn-leakages-01 (work in progress),
December 2012. June 2013.
[I-D.ietf-opsec-dhcpv6-shield] [I-D.ietf-opsec-dhcpv6-shield]
Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield: Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield:
Protecting Against Rogue DHCPv6 Servers", Protecting Against Rogue DHCPv6 Servers",
draft-ietf-opsec-dhcpv6-shield-00 (work in progress), draft-ietf-opsec-dhcpv6-shield-00 (work in progress),
December 2012. December 2012.
[I-D.massar-v6ops-ayiya] [I-D.massar-v6ops-ayiya]
Massar, J., "AYIYA: Anything In Anything", Massar, J., "AYIYA: Anything In Anything",
draft-massar-v6ops-ayiya-02 (work in progress), July 2004. draft-massar-v6ops-ayiya-02 (work in progress), July 2004.
 End of changes. 9 change blocks. 
20 lines changed or deleted 31 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/