draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02.txt   draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.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: July 1, 2013 December 28, 2012 Expires: August 26, 2013 February 22, 2013
Security Implications of IPv6 on IPv4 Networks Security Implications of IPv6 on IPv4 Networks
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03
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 July 1, 2013. This Internet-Draft will expire on August 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5
3. Security Implications of Tunneling Mechanisms . . . . . . . . 7 3. Security Implications of Tunneling Mechanisms . . . . . . . . 7
3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8
3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10
3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 10 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 10
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol
(TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Additional Considerations when Filtering IPv6 Traffic . . . . 13 3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. Additional Considerations when Filtering IPv6 Traffic . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Summary of filtering rules . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Most general-purpose operating systems implement and enable by Most general-purpose operating systems implement and enable native
default native IPv6 [RFC2460] support and a number of transition/ IPv6 [RFC2460] support and a number of transition/co-existence
co-existence technologies. In those cases in which the corresponding technologies by default. For cases in which the corresponding
devices are deployed on networks that are assumed to be IPv4-only, devices are deployed on networks that are assumed to be IPv4-only,
native IPv6 support and/or IPv6 transition/co-existence technologies native IPv6 support and/or IPv6 transition/co-existence technologies
could be leveraged by local or remote attackers for a number of could be leveraged by local or remote attackers for a number of
(illegitimate) purposes. For example, (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 Some transition/co-existence mechanisms might cause an internal o A NIDS or firewall might support both IPv4 and IPv6, but might be
not be configured to enforce on IPv6 traffic the same controls/
policies it enforces on IPv4 traffic.
o Some transition/co-existence mechanisms could cause an internal
host with otherwise limited IPv4 connectivity to become globally host with otherwise limited IPv4 connectivity to become globally
reachable over IPv6, therefore resulting in increased (and reachable over IPv6, therefore resulting in increased (and
possibly unexpected) host exposure. possibly unexpected) host exposure.
Some transition/co-existence mechanisms (notably Teredo) are Some transition/co-existence mechanisms (notably Teredo) are
designed to traverse Network Address Port Translation (NAPT) designed to traverse Network Address Port Translation (NAPT)
[RFC2663] devices, allowing incoming IPv6 connections from the [RFC2663] devices, allowing incoming IPv6 connections from the
Internet to hosts behind the organizational firewall or NAPT Internet to hosts behind the organizational firewall or NAPT
(which in many deployments provides a minimum level of (which in many deployments provides a minimum level of
protection by only allowing those instances of communication protection by only allowing those instances of communication
that have been initiated from the internal network). that have been initiated from the internal network).
o IPv6 support might, either inadvertently or as a result of a o IPv6 support could, either inadvertently or as a result of a
deliberate attack, result in VPN traffic leaks if IPv6-unaware deliberate attack, result in VPN traffic leaks if IPv6-unaware
Virtual Private Network (VPN) software is employed by dual-stacked Virtual Private Network (VPN) software is employed by dual-stacked
hosts [I-D.ietf-opsec-vpn-leakages]. hosts [I-D.ietf-opsec-vpn-leakages].
In general, most of the aforementioned security implications can be In general, most of the aforementioned security implications can be
mitigated by enforcing security controls on native IPv6 traffic and mitigated by enforcing security controls on native IPv6 traffic and
on IPv4-tunneled traffic. Among such controls is the enforcement of on IPv4-tunneled traffic. Among such controls is the enforcement of
filtering policies, such that undesirable traffic is blocked. While filtering policies, to block undesirable traffic. While IPv6
IPv6 widespread/global IPv6 deployment has been slower than expected, widespread/global IPv6 deployment has been slower than expected, it
it is nevertheless happening, and thus filtering IPv6 traffic is nevertheless happening; and thus, filtering IPv6 traffic (whether
(whether native or transition/co-existence) to mitigate IPv6 security native or transition/co-existence) to mitigate IPv6 security
implications on IPv4 networks should only be considered as a implications on IPv4 networks should (generally) only be considered
temporary solution to protect a network until IPv6 is deployed. Only as a temporary measure until IPv6 is deployed.
in some exceptional cases (such as military operations networks)
could this approach to mitigating the aforementioned security
implications be thought of as a longer-term strategy.
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.
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.
skipping to change at page 5, line 25 skipping to change at page 5, line 25
could be remotely-exploited by leveraging link-local IPv6 could be remotely-exploited by leveraging link-local IPv6
connectivity that is enabled by default. 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] is the first publicly-available toolkit that [THC-IPV6] and [IPv6-Toolkit] include tools that implement this
implemented this attack vector (along with many others). 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 [Waters2013] provides an example of how this could be achieved
using publicly available tools (besides incorrectly claiming the using publicly available tools.
discovery of a "0day vulnerability").
Native IPv6 support could also possibly lead to VPN traffic leakages Native IPv6 support could also possibly lead to VPN traffic leakages
when hosts employ VPN software that not only does not support IPv6, when hosts employ VPN software that not only does not support IPv6,
but that does nothing about IPv6 traffic. but that does nothing about IPv6 traffic.
[I-D.ietf-opsec-vpn-leakages] describes this issue, along with [I-D.ietf-opsec-vpn-leakages] describes this issue, along with
possible mitigations. 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 currently enforced on IPv4 traffic. However, in
in those networks in which IPv6 has not yet been deployed, and those networks in which IPv6 has not yet been deployed, and enforcing
enforcing the aforementioned policies is deemed as unfeasible, a the aforementioned policies is deemed as unfeasible, a network
network administrator might mitigate IPv6-based attack vectors by administrator might mitigate IPv6-based attack vectors by means of
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 e.g. Ethernet frames with the Protocol layer-2 devices by blocking, for example, Ethernet frames with the
Type field set to 0x86dd [IANA-ETHER]. Protocol 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.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 7, line 8 skipping to change at page 7, line 8
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. For example, they might increase
implications of tunneling mechanisms in detail). host exposure, might be leveraged to evade security controls, might
contain protocol-based vulnerabilities, and/or the corresponding code
might contain bugs with security implications.
Of the plethora of tunneling mechanism that have so far been [RFC6169] describes the security implications of tunneling
mechanisms in detail.
Of the plethora of tunneling mechanisms that have so far been
standardized and widely implemented, the so-called "automatic standardized and widely implemented, the so-called "automatic
tunneling" mechanisms (such as Teredo, ISATAP, and 6to4) are of tunneling" mechanisms (such as Teredo, ISATAP, and 6to4) are of
particular interest from a security standpoint, since they might particular interest from a security standpoint, since they might
be employed without prior consent or action of the user or network be employed without prior consent or action of the user or network
administrator. administrator.
Therefore, tunneling mechanisms should be a concern not only to Tunneling mechanisms should be a concern not only to network
network administrators that have consciously deployed them, but also administrators that have consciously deployed them, but also to those
to network and security administrators whose security policies might who have not deployed them, as these mechanisms might be leveraged to
be bypassed by exploiting these mechanisms. bypass their security policies.
[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.
traffic).
It should be noted that this type of policy is usually enforced at It should be noted that this type of policy is usually enforced on
a network that is the target of such traffic (such as an a network that is the target of such traffic (such as an
enterprise network). IPv6 transition traffic should generally enterprise network). IPv6 transition traffic should generally
never be filtered e.g. by an ISP when it is transit traffic. never be filtered e.g. by an ISP when it is transit traffic.
In those scenarios in which transition/co-existence traffic is meant In those scenarios in which transition/co-existence traffic is meant
to be blocked, it is highly recommended that, in addition to the to be blocked, it is highly recommended that, in addition to the
enforcement of filtering policies at the organizational perimeter, enforcement of filtering policies at the organizational perimeter,
the corresponding transition/co-existence mechanisms be disabled on the corresponding transition/co-existence mechanisms be disabled on
each node connected to the organizational network. This would not each node connected to the organizational network. This would not
only prevent security breaches resulting from accidental use of these only prevent security breaches resulting from accidental use of these
skipping to change at page 12, line 14 skipping to change at page 12, line 14
teredo.ipv6.microsoft.com) resolve. teredo.ipv6.microsoft.com) resolve.
As these IPv4 addresses might change over time, an administrator As these IPv4 addresses might change over time, an administrator
should obtain these addresses when implementing the filtering should obtain these addresses when implementing the filtering
policy, and should also be prepared to keep this list up to date. policy, and should also be prepared to keep this list up to date.
The corresponding addresses can be easily obtained from a UNIX The corresponding addresses can be easily obtained from a UNIX
host by issuing the command 'dig teredo.ipv6.microsoft.com a' host by issuing the command 'dig teredo.ipv6.microsoft.com a'
(without quotes). (without quotes).
dig(1) is a free-software tool (part of the "dnsutils" package)
produced by the Internet Software Consortium (ISC).
It should be noted that even with all these filtering policies in It should be noted that even with all these filtering policies in
place, a node in the internal network might still be able to place, a node in the internal network might still be able to
communicate with some Teredo clients. That is, it could configure an communicate with some Teredo clients. That is, it could configure an
IPv6 address itself (without even contacting a Teredo server), and IPv6 address itself (without even contacting a Teredo server), and
might send Teredo traffic to those peers for which intervention of might send Teredo traffic to those peers for which intervention of
the host's Teredo server is not required (e.g., Teredo clients behind the host's Teredo server is not required (e.g., Teredo clients behind
a cone NAT). a cone NAT).
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP)
skipping to change at page 13, line 5 skipping to change at page 12, line 47
TSP can use either TCP or UDP as the transport protocol. In both TSP can use either TCP or UDP as the transport protocol. In both
cases TSP uses port number 3653, which has been assigned by the IANA cases TSP uses port number 3653, which has been assigned by the IANA
for this purpose. As a result, TSP (the Tunnel Broker control for this purpose. As a result, TSP (the Tunnel Broker control
channel) can be blocked by blocking TCP and UDP packets originating channel) can be blocked by blocking TCP and UDP packets originating
from the local network and destined to UDP port 3653 or TCP port from the local network and destined to UDP port 3653 or TCP port
3653. Additionally, the data channel can be blocked by blocking UDP 3653. Additionally, the data channel can be blocked by blocking UDP
packets originated from the local network and destined to UDP port packets originated from the local network and destined to UDP port
3653, and IPv4 packets with a Protocol field set to 41. 3653, and IPv4 packets with a Protocol field set to 41.
3.8. Filtering AYIYA
AYIYA ("Anything In Anything") [I-D.massar-v6ops-ayiya] allows the
tunnelling of packets across Network Address Port Translation (NAPT)
[RFC2663] devices. While the specification of this tunneling
mechanism was never published as an RFC, it is nevertheless widely
deployed [SixXS-stats].
AYIYA can be blocked by blocking TCP and UDP packets originating from
the local network and destined to UDP port 5072 or TCP port 5072.
4. Additional Considerations when Filtering IPv6 Traffic 4. Additional Considerations when Filtering IPv6 Traffic
IPv6 deployments in the Internet are continually increasing, and some IPv6 deployments in the Internet are continually increasing, and some
hosts default to preferring IPv6 connectivity whenever it is hosts default to preferring IPv6 connectivity whenever it is
available. This is likely to cause IPv6-capable hosts to attempt to available. This is likely to cause IPv6-capable hosts to attempt to
reach an ever-increasing number of popular destinations via IPv6, reach an ever-increasing number of popular destinations via IPv6,
even if this IPv6 connectivity is provided relies on a transition even if this IPv6 connectivity relies on a transition technology over
technology over an IPv4-only network. an IPv4-only network.
A large source of IPv6 brokenness today comes from nodes that believe A large source of IPv6 brokenness today comes from nodes that believe
that they have functional IPv6 connectivity, but the path to their that they have functional IPv6 connectivity, but the path to their
destination fails somewhere upstream [Anderson2010] [Anderson2011] destination fails somewhere upstream [Anderson2010] [Anderson2011]
[Huston2010b] [Huston2012]. Upstream filtering of transition [Huston2010b] [Huston2012]. Upstream filtering of transition
technologies or situations where a misconfigured node attempts to technologies or situations where a mis-configured node attempts to
"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 ignore queries for AAAA DNS records, or even recursive DNS servers to respond to queries for AAAA DNS records with
consider filtering AAAA records at the network ingress point to a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
prevent end hosts from attempting their own DNS resolution. This queries, and should even consider filtering AAAA records at the
will ensure that end hosts which are on an IPv4-only network will network ingress point to prevent the internal hosts from attempting
only receive DNS A records, and they will be unlikely to attempt to their own DNS resolution. This will ensure that hosts which are on
use (likely broken) IPv6 connectivity to reach their desired an IPv4-only network will only receive DNS A records, and they will
destinations. Additionally, it is generally deemed as good practice be unlikely to attempt to use (likely broken) IPv6 connectivity to
to signal the packet drop to the source node, such that the source reach their desired destinations.
node is able to react to such packet drop in a more appropriate and
Additionally, it should be noted that when filtering IPv6 traffic, it
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
timely way. timely way.
A firewall could signal the packet drop by means of an ICMPv6 For example, a firewall could signal the packet drop by means of
error message (or TCP [RFC0793] RST segment if appropriate), such an ICMPv6 error message (or TCP [RFC0793] RST segment if
that the source node can e.g. quickly react as described in appropriate), such that the source node can e.g. quickly react as
[RFC5461]. described in [RFC5461].
For obvious reasons, if the traffic being filtered is IPv6 For obvious reasons, if the traffic being filtered is IPv6
transition/co-existence traffic, the signalling packet should be transition/co-existence traffic, the signalling packet should be
sent by means of the corresponding IPv6 transition/co-existence sent by means of the corresponding IPv6 transition/co-existence
technology. technology.
5. IANA Considerations 5. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
skipping to change at page 16, 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, Panos Kampanakis, David Malone, Arturo Servin, Brian Carpenter, Joel Jaeggli, Panos Kampanakis, Warren Kumari, David
Donald Smith, Tina Tsou, and Eric Vyncke, for providing valuable Malone, Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke, for
comments on earlier versions of this document. providing 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
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999. Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
skipping to change at page 18, line 47 skipping to change at page 19, line 50
in dual-stack hosts/ networks", in dual-stack hosts/ networks",
draft-ietf-opsec-vpn-leakages-00 (work in progress), draft-ietf-opsec-vpn-leakages-00 (work in progress),
December 2012. December 2012.
[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]
Massar, J., "AYIYA: Anything In Anything",
draft-massar-v6ops-ayiya-02 (work in progress), July 2004.
[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]
skipping to change at page 19, line 41 skipping to change at page 20, line 47
[Anderson2011] [Anderson2011]
Anderson, T., "IPv6 dual-stack client loss in Norway", Anderson, T., "IPv6 dual-stack client loss in Norway",
2011, <http://www.fud.no/ipv6/>. 2011, <http://www.fud.no/ipv6/>.
[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]
"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/>.
[Waters2011] [Waters2013]
Waters, A., "SLAAC Attack - 0day Windows Network Waters, A., "The SLAAC Attack - using IPv6 as a weapon
Interception Configuration Vulnerability", 2011, against IPv4", 2013, <http://wirewatcher.wordpress.com/
<http://resources.infosecinstitute.com/slaac-attack/>. 2011/04/04/
the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/>.
[SixXS-stats]
SixXS, "SixXS - IPv6 Deployment & Tunnel Broker ::
Statistics", 2013, <http://www.sixxs.net/misc/usage/>.
Appendix A. Summary of filtering rules Appendix A. Summary of filtering rules
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Technology | Filtering rules | | Technology | Filtering rules |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Native | EtherType 0x86DD | | Native | EtherType 0x86DD |
| IPv6 | | | IPv6 | |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| 6in4 | IP proto 41 | | 6in4 | IP proto 41 |
skipping to change at page 20, line 28 skipping to change at page 22, line 28
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| 6to4 | IP proto 41 | | 6to4 | IP proto 41 |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| ISATAP | IP proto 41 | | ISATAP | IP proto 41 |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Teredo | UDP Dest Port 3544 | | Teredo | UDP Dest Port 3544 |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| TB with | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest | | TB with | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest |
| TSP | Port 3653) | | TSP | Port 3653) |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 |
+------------+------------------------------------------------------+
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.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
Will Liu Will (Shucheng) Liu
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China P.R. China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
 End of changes. 32 change blocks. 
84 lines changed or deleted 111 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/