draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt   draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04.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: August 26, 2013 February 22, 2013 Expires: November 3, 2013 May 2, 2013
Security Implications of IPv6 on IPv4 Networks Security Implications of IPv6 on IPv4 Networks
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04
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 August 26, 2013. This Internet-Draft will expire on November 3, 2013.
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 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Implications of Native IPv6 Support . . . . . . . . . 5 2. Security Implications of Native IPv6 Support . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 11
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol
(TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 12 3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 13
4. Additional Considerations when Filtering IPv6 Traffic . . . . 14 4. Additional Considerations when Filtering IPv6 Traffic . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
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. For cases in which the corresponding technologies by default. Support of IPv6 by all nodes is intended to
devices are deployed on networks that are assumed to be IPv4-only, become best current practice [RFC6540]. Some enterprise networks
native IPv6 support and/or IPv6 transition/co-existence technologies might, however, choose to delay active use of IPv6. In scenarios in
could be leveraged by local or remote attackers for a number of which the aforementioned devices are deployed on networks that are
(illegitimate) purposes. For example, assumed 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 3, line 47 skipping to change at page 3, line 49
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 could, 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 IPv6 traffic. Among such controls is the
filtering policies, to block undesirable traffic. While IPv6 enforcement of filtering policies, to block undesirable traffic.
widespread/global IPv6 deployment has been slower than expected, it While IPv6 widespread/global IPv6 deployment has been slower than
is nevertheless happening; and thus, filtering IPv6 traffic (whether expected, it is nevertheless happening; and thus, filtering IPv6
native or transition/co-existence) to mitigate IPv6 security traffic (whether native or transition/co-existence) to mitigate IPv6
implications on IPv4 networks should (generally) only be considered security implications on IPv4 networks should (generally) only be
as a temporary measure until IPv6 is deployed. considered as a temporary measure until IPv6 is deployed.
The aforementioned security controls should contemplate not only
network-based solutions, but also host-based solutions (such as
e.g. personal firewalls).
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 8, line 13 skipping to change at page 8, line 13
implementation of these transition/co-existence mechanisms. implementation of these transition/co-existence mechanisms.
IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured
tunnels) can generally be blocked by dropping IPv4 packets that tunnels) can generally be blocked by dropping IPv4 packets that
contain a Protocol field set to 41. Security devices such as NIDS contain a Protocol field set to 41. Security devices such as NIDS
might also include signatures that detect such transition/ might also include signatures that detect such transition/
co-existence traffic. co-existence traffic.
Administrators considering the filtering of transition/co-existence Administrators considering the filtering of transition/co-existence
traffic are urged to pay attention to the general considerations for traffic are urged to pay attention to the general considerations for
IPv6 traffic filtering discussed in Section 4 IPv6 traffic filtering discussed in Section 4.
We note that this document only covers standardized IPv6 tunneling
mechanisms, but does not aim to cover non-standard tunneling
mechanisms or IPsec-based [RFC4301] or SSL/TLS-based [RFC5246]
[RFC6101] tunneling of IPv6 packets.
3.1. Filtering 6in4 3.1. Filtering 6in4
Probably the most basic type of tunnel employed for connecting IPv6 Probably the most basic type of tunnel employed for connecting IPv6
"islands" is the so-called "6in4", in which IPv6 packets are "islands" is the so-called "6in4", in which IPv6 packets are
encapsulated within IPv4 packets. These tunnels are typically result encapsulated within IPv4 packets. These tunnels are typically result
from manual configuration at the two tunnel endpoints. from manual configuration at the two tunnel endpoints.
6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol
field of 41. field of 41.
skipping to change at page 17, line 12 skipping to change at page 17, line 12
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, Joel Jaeggli, Panos Kampanakis, Warren Kumari, David
Malone, Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke, for Malone, Joseph Salowey, Arturo Servin, Donald Smith, Tina Tsou, and
providing valuable comments on earlier versions of this document. Eric Vyncke, for 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
skipping to change at page 19, line 16 skipping to change at page 19, line 16
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004. May 2004.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for [RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004. 6to4", RFC 3964, December 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
February 2009. February 2009.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
August 2011.
[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.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011. RFC 6343, August 2011.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, April 2012.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[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]
 End of changes. 12 change blocks. 
20 lines changed or deleted 46 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/