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/ |