This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues.
b620fd364138e64c6e10717389b326fd4176c5005ea71cbad80cb84096381fe9
Operational Security Capabilities for F. Gont
IP Network Infrastructure (opsec) UK CPNI
Internet-Draft April 24, 2012
Intended status: BCP
Expires: October 26, 2012
Security Implications of IPv6 on IPv4 networks
draft-gont-opsec-ipv6-implications-on-ipv4-nets-00
Abstract
This document discusses the security implications of native IPv6
support and IPv6 transition/co-existence technologies on "IPv4-only"
networks, and describes possible mitigations for the aforementioned
issues.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 26, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Gont Expires October 26, 2012 [Page 1]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Implications of native IPv6 support . . . . . . . . . 4
3. Security Implications of tunneling Mechanisms . . . . . . . . 5
3.1. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 6
3.3. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 7
3.4. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Gont Expires October 26, 2012 [Page 2]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
1. Introduction
Most general-purpose operating systems implement and enable by
default native IPv6 support and a number of transition-co-existence
technologies. In those cases in which such devices are deployed on
networks that are assumed to be IPv4-only, the aforementioned
technologies could be leveraged by local or remote attackers for a
number of (illegitimate) purposes.
For example, a Network Intrusion Detection System (NIDS) might be
prepared to detect attack patterns for IPv4 traffic, but might be
unable to detect the same attack patterns when a transition/
co-existence technology is leveraged for that purpose. Additionally,
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 Translators (NATs), 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
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.
This document discusses the security implications of IPv6 and IPv6
transition/co-existence technologies on (allegedly) IPv4-only
networks, and provides guidance on how to mitigate the aforementioned
issues.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Gont Expires October 26, 2012 [Page 3]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
2. Security Implications of native IPv6 support
Most popular operating systems include IPv6 support that is enabled
by default. This means that even if a network is expected 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-
local IPv6 connectivity which might be exploited by attackers with
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
access to an 'IPv4-only' local network could impersonate a local
router and cause local hosts to enable their IPv6 connectivity (e.g.
by sending Router Advertisement messages), possibly circumventing
security controls that were are enforced only on IPv4 communications.
[Waters2011] provides an example of how this could be achieved
using publicly available tools.
SLAAC-based attacks [RFC3756] can be mitigated with technologies such
as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation].
However, RA-Guard cannot mitigate attack vectors that employ IPv6
link-local addresses, since configuration of such addresses does not
rely on Router Advertisement messages.
In order to mitigate attacks based on native IPv6 traffic, IPv6
security controls should be enforced on both IPv4 and IPv6 networks.
The aforementioned controls might include: deploying IPv6-enabled
NIDS, implementing IPv6 firewalling, etc.
In some very specific scenarios (e.g., military operations
networks) in which only IPv4 service might be desired, a network
administrator might disable IPv6 support in all the communicating
devices.
Gont Expires October 26, 2012 [Page 4]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
3. Security Implications of tunneling Mechanisms
Unless properly managed, tunneling mechanisms may result in negative
security implication. [RFC6169] describes the security implications
of tunneling mechanisms in detail. 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
to bypass firewall rules.
To help mitigate these issues, a good security practice is to only
allow traffic deemed as "necessary" (i.e., the so-called "default
deny" policy). Therefore, security administrators should only allow
IPv6 transition co-existence traffic as a result of an explicit
decision, rather than as a result of lack of awareness about such
traffic.
It should be noted that this recommendation is aimed at a network
that is the target of such traffic (such as an enterprise
network). IPv6-transition traffic should not be filtered e.g. by
an ISP when it is transit traffic.
Additionally, it is highly recommended that in those networks where
specific transition mechanisms are not explicitly deployed, not only
the corresponding traffic should be filtered at the organizational
perimeter, but also the corresponding mechanisms disabled on each
node connected to the organizational network. This not only prevents
security breaches resulting from accidental use of these mechanisms,
but also disables this functionality altogether, possibly mitigating
vulnerabilities that might be present in the host implementation of
this transition/co-existence mechanisms.
IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured
tunnels) can generally be blocked by dropping IPv4 packets that
contain a Protocol field set to 41. Security devices such as NIDS
might also include signatures that detect such transition/
co-existence traffic.
3.1. Filtering 6to4
6to4 [RFC3056] is an address assignment and router-to-router, host-
to-router, and router-to-host automatic tunnelling mechanism that is
meant to provide IPv6 connectivity between IPv6 sites and hosts
across the IPv4 Internet.
Gont Expires October 26, 2012 [Page 5]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4,
could be easily blocked by filtering IPv4 that contain their Protocol
field set to 41. This is the most effective way of filtering such
traffic.
Additional filtering rules that might be incorporated include:
o Filter outgoing IPv4 packets that have their Destination Address
set to an address that belongs to the prefix 192.88.99.0/24.
o Filter incoming IPv4 packets that have their Source Address set to
an address that belongs to the prefix 192.88.99.0/24.
It has been suggested that 6to4 relays send their packets with
their IPv4 Source Address set to 192.88.99.1.
o Filter outgoing IPv4 packets that have their Destination Address
set to the IPv4 address of well-known 6to4 relays.
o Filter incoming IPv4 packets that have their Destination Address
set to the IPv4 address of well-known 6to4 relays.
These last two filtering policies will generally be unnecessary, and
possibly unfeasible to enforce (given the number of potential 6to4
relays, and the fact that many relays may remain unknown to the
network administrator). If anything, they should be applied with the
additional requirement that such IPv4 packets have their Protocol
field set to 41, to avoid the case where other services available at
the same IPv4 address as a 6to4 relay are mistakenly made
inaccessible.
If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4
traffic is allowed, then the following filtering rules could be
applied:
o Filter outgoing IPv4 packets that have their Protocol field set to
41, and that have an IPv6 Source Address (embedded in the IPv4
payload) that belongs to the prefix 2002::/16.
o Filter incoming IPv4 packets that have their Protocol field set to
41, and that have an IPv6 Destination address (embedded in the
IPv4 payload) that belongs to the prefix 2002::/16.
3.2. Filtering ISATAP
ISATAP [RFC5214] is an Intra-site tunnelling protocol, and thus it is
generally expected that such traffic will not traverse the
organizational firewall of an IPv4-only. Nevertheless, ISATAP
Gont Expires October 26, 2012 [Page 6]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
traffic is easily filtered as described in Section 3 of this
document.
3.3. Filtering Teredo
Teredo [RFC4380] is an address assignment and automatic tunnelling
technology that provides IPv6 connectivity to dual-stack nodes that
are behind one or more Network Address Translators (NATs), by
encapsulating IPv6 packets in IPv4-based UDP datagrams. Teredo is
meant to be a 'last resort' IPv6 connectivity technology, to be used
only when other technologies such as 6to4 cannot be deployed (e.g.,
because the edge device has not been assigned a public IPv4 address).
As noted in [RFC4380], in order for a Teredo client to configure its
Teredo IPv6 address, it must contact a Teredo server, through the
Teredo service port (UDP port number 3544).
To prevent the Teredo initialization process from succeeding, and
hence prevent the use of Teredo, an organizational firewall could
filter outgoing UDP packets with a Destination Port of 3544.
It is clear that such a filtering policy does not prevent an attacker
from running its own Teredo server in the public Internet, using a
non-standard UDP port for the Teredo service port (i.e., a port
number other than 3544).
The most popular operating system that includes an implementation of
Teredo in the default installation is Microsoft Windows. Microsoft
Windows obtains the Teredo server addresses (primary and secondary)
by resolving the domain name teredo.ipv6.microsoft.com into DNS A
records. A network administrator may want to prevent Microsoft
Windows hosts from obtaining Teredo service by filtering at the
organizational firewall outgoing UDP datagrams (i.e., IPv4 packets
with the Protocol field set to 17) that contain in the IPv4
Destination Address any of the IPv4 addresses that the domain name
teredo.ipv6.microsoft.com maps to. Additionally, the firewall would
filter incoming UDP datagrams from any of the IPv4 addresses to which
the domain names of well-known Teredo servers (such as
teredo.ipv6.microsoft.com) resolve.
As these IPv4 addresses might change over time, an administrator
should obtain these addresses himself when implementing the
filtering policy, and should also be prepared to maintain this
list updated over time.
Gont Expires October 26, 2012 [Page 7]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
The corresponding addresses can be easily obtained from a UNIX
host by issuing the command 'dig teredo.ipv6.microsoft.com a'
(without quotes).
It should be noted that even with all these filtering policies in
place, a node in the internal network might still be able to
communicate with some Teredo clients. That is, it could configure an
IPv6 address itself (without even contacting a Teredo server), and
might send Teredo traffic to those peers for which intervention of
the host's Teredo server is not required (e.g., Teredo clients behind
a cone NAT).
3.4. Filtering 6over4
[RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4'
(or colloquially as 'virtual Ethernet'), which comprises a set of
mechanisms and policies to allow isolated IPv6 hosts located on
physical links with no directly-connected IPv6 router, to become
fully functional IPv6 hosts by using an IPv4 domain that supports
IPv4 multicast as their virtual local link.
This transition technology has never been widely deployed, because
of the low level of deployment of multicast in most networks.
6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol
field set to 41. As a result, simply filtering all IPv4 packets that
have a Protocol field equal to 41 will filter 6over4 (along with many
other transition technologies).
A more selective filtering could be enforced such that 6over4 traffic
is filtered while other transition traffic is still allowed. Such a
filtering policy would block all IPv4 packets that have their
Protocol field set to 41, and that have a Destination Address that
belongs to the prefix 239.0.0.0/8.
This filtering policy basically blocks 6over4 Neighbor Discovery
traffic directed to multicast addresses, thus preventing Stateless
Address Auto-configuration (SLAAC), address resolution, etc.
Additionally, it would prevent the 6over multicast addresses from
being leveraged for the purpose of network reconnaissance.
Gont Expires October 26, 2012 [Page 8]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
4. Security Considerations
This document discusses the security implications of IPv6 on IPv4
networks, and describes a number of techniques to mitigate the
aforementioned issues.
Gont Expires October 26, 2012 [Page 9]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
5. Acknowledgements
This document resulted from the project "Security Assessment of the
Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by
Fernando Gont on behalf of the UK Centre for the Protection of
National Infrastructure (CPNI).
Fernando Gont would like to thank the UK CPNI for their continued
support.
Gont Expires October 26, 2012 [Page 10]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
6.2. Informative References
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011.
[I-D.ietf-v6ops-ra-guard-implementation]
Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)",
draft-ietf-v6ops-ra-guard-implementation-02 (work in
progress), March 2012.
[CERT2009]
CERT, "Bypassing firewalls with IPv6 tunnels", 2009, <http
://www.cert.org/blogs/vuls/2009/04/
bypassing_firewalls_with_ipv6.html>.
Gont Expires October 26, 2012 [Page 11]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
[CORE2007]
CORE, "OpenBSD's IPv6 mbufs remote kernel buffer
overflow", 2007,
<http://www.coresecurity.com/content/open-bsd-advisorie>.
[CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request).
[Waters2011]
Waters, A., "SLAAC Attack - 0day Windows Network
Interception Configuration Vulnerability", 2011,
<http://resources.infosecinstitute.com/slaac-attack/>.
Gont Expires October 26, 2012 [Page 12]
Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012
Author's Address
Fernando Gont
UK Centre for the Protection of National Infrastructure
Email: fernando@gont.com.ar
URI: http://www.cpni.gov.uk
Gont Expires October 26, 2012 [Page 13]