draft-ietf-6man-nd-extension-headers-04.txt   draft-ietf-6man-nd-extension-headers-05.txt 
IPv6 maintenance Working Group (6man) F. Gont IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Updates: 3971, 4861 (if approved) March 22, 2013 Updates: 3971, 4861 (if approved) June 3, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: September 23, 2013 Expires: December 5, 2013
Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
draft-ietf-6man-nd-extension-headers-04 draft-ietf-6man-nd-extension-headers-05
Abstract Abstract
This document analyzes the security implications of employing IPv6 This document analyzes the security implications of employing IPv6
fragmentation with Neighbor Discovery (ND) messages. It updates RFC fragmentation with Neighbor Discovery (ND) messages. It updates RFC
4861 such that use of the IPv6 Fragmentation Header is forbidden in 4861 such that use of the IPv6 Fragmentation Header is forbidden in
all Neighbor Discovery messages, thus allowing for simple and all Neighbor Discovery messages, thus allowing for simple and
effective counter-measures for Neighbor Discovery attacks. Finally, effective counter-measures for Neighbor Discovery attacks. Finally,
it discusses the security implications of using IPv6 fragmentation it discusses the security implications of using IPv6 fragmentation
with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971 with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 23, 2013. This Internet-Draft will expire on December 5, 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 25 skipping to change at page 2, line 25
4. Rationale for Forbidding IPv6 Fragmentation in Neighbor 4. Rationale for Forbidding IPv6 Fragmentation in Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Operational Advice . . . . . . . . . . . . . . . . . . . . . . 9 6. Operational Advice . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Message Size When Carrying Certificates . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Neighbor Discovery Protocol (NDP) is specified in RFC 4861 The Neighbor Discovery Protocol (NDP) is specified in RFC 4861
[RFC4861]. It is used by both hosts and routers. Its functions [RFC4861]. It is used by both hosts and routers. Its functions
include Neighbor Discovery (ND), Router Discovery (RD), Address include Neighbor Discovery (ND), Router Discovery (RD), Address
Autoconfiguration, Address Resolution, Neighbor Unreachability Autoconfiguration, Address Resolution, Neighbor Unreachability
Detection (NUD), Duplicate Address Detection (DAD), and Redirection. Detection (NUD), Duplicate Address Detection (DAD), and Redirection.
Many of the possible attacks against the Neighbor Discovery Protocol Many of the possible attacks against the Neighbor Discovery Protocol
are discussed in detail in [RFC3756]. In order to mitigate the are discussed in detail in [RFC3756]. In order to mitigate the
aforementioned possible attacks, the SEcure Neighbor Discovery (SEND) aforementioned possible attacks, the SEcure Neighbor Discovery (SEND)
was standardized. SEND employs a number of mechanisms to certify the was standardized. SEND employs a number of mechanisms to certify the
origin of Neighbor Discovery packets and the authority of routers, origin of Neighbor Discovery packets and the authority of routers,
and to protect Neighbor Discovery packets from being the subject of and to protect Neighbor Discovery packets from being the subject of
modification or replay attacks. modification or replay attacks.
However, a number of factors, such as the use of trust anchors and However, a number of factors, such as the high administrative
the unavailability of SEND implementations for many widely-deployed overhead of deploying trust anchors and the unavailability of SEND
operating systems, make SEND hard to deploy [Gont-DEEPSEC2011]. implementations for many widely-deployed operating systems, make SEND
Thus, in many general scenarios it may be necessary and/or convenient hard to deploy [Gont-DEEPSEC2011]. Thus, in many general scenarios
to use other mitigation techniques for NDP-based attacks. The it may be necessary and/or convenient to use other mitigation
following mitigations are currently available for NDP attacks: techniques for NDP-based attacks. The following mitigations are
currently available for NDP attacks:
o Static Access Control Lists (ACLs) in switches
o Layer-2 filtering of Neighbor Discovery packets (such as RA-Guard o Layer-2 filtering of Neighbor Discovery packets (such as RA-Guard
[RFC6105]) [RFC6105])
o Neighbor Discovery monitoring tools (e.g., such as NDPMon o Neighbor Discovery monitoring tools (e.g., such as NDPMon
[NDPMon], ramond [ramond]) [NDPMon], ramond [ramond])
o Intrusion Prevention Systems (IPS) o Intrusion Prevention Systems (IPS)
IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique
skipping to change at page 6, line 29 skipping to change at page 6, line 29
they include typically contains much more information than any other they include typically contains much more information than any other
Neighbor Discovery option. For example, Appendix C of [RFC3971] Neighbor Discovery option. For example, Appendix C of [RFC3971]
reports Certification Path Advertisement messages from 1050 to 1066 reports Certification Path Advertisement messages from 1050 to 1066
bytes on an Ethernet link layer. Since the size of CPA messages bytes on an Ethernet link layer. Since the size of CPA messages
could potentially exceed the MTU of the local link, Section 5 could potentially exceed the MTU of the local link, Section 5
recommends that fragmented CPA messages be normally processed, but recommends that fragmented CPA messages be normally processed, but
discourages the use of keys that would result in fragmented CPA discourages the use of keys that would result in fragmented CPA
messages. messages.
It should be noted that relying on fragmentation opens the door to a It should be noted that relying on fragmentation opens the door to a
variety of IPv6 fragmentation-based attacks. In particular, if an variety of IPv6 fragmentation-based attacks against SEND. In
attacker is located on the same broadcast domain as the victim host, particular, if an attacker is located on the same broadcast domain as
and Certification Path Advertisement messages employ IPv6 the victim host, and Certification Path Advertisement messages employ
fragmentation, it would be trivial for the attacker to forge IPv6 IPv6 fragmentation, it would be trivial for the attacker to forge
fragments such that they result in "Fragment ID collisions", causing IPv6 fragments such that they result in "Fragment ID collisions",
both the attack fragments and the legitimate fragments to be causing both the attack fragments and the legitimate fragments to be
discarded by the victim node. This would eventually cause the discarded by the victim node. This would eventually cause the
Authorization Delegation Discovery to fail, thus leading the host to Authorization Delegation Discovery (Section 6 of [RFC3971]) to fail,
fall back (depending on local configuration) either to unsecured thus leading the host to fall back (depending on local configuration)
mode, or to reject the corresponding Router Advertisement messages either to unsecured mode, or to reject the corresponding Router
(possibly resulting in a Denial of Service). Advertisement messages (possibly resulting in a Denial of Service).
4. Rationale for Forbidding IPv6 Fragmentation in Neighbor Discovery 4. Rationale for Forbidding IPv6 Fragmentation in Neighbor Discovery
A number of considerations should be made regarding the use of IPv6 A number of considerations should be made regarding the use of IPv6
fragmentation with Neighbor Discovery: fragmentation with Neighbor Discovery:
o A significant number of existing implementations already silently o A significant number of existing implementations already silently
drop fragmented ND messages, so the use of IPv6 fragmentation may drop fragmented ND messages, so the use of IPv6 fragmentation may
hamper interoperability among IPv6 implementations. hamper interoperability among IPv6 implementations.
skipping to change at page 8, line 23 skipping to change at page 8, line 23
o Router Solicitation o Router Solicitation
o Router Advertisement o Router Advertisement
o Redirect o Redirect
o Certification Path Solicitation o Certification Path Solicitation
Nodes SHOULD NOT employ IPv6 fragmentation for sending the following Nodes SHOULD NOT employ IPv6 fragmentation for sending the following
messages: messages (see Section 6.4.2 of [RFC3971]):
o Certification Path Advertisement messages o Certification Path Advertisement messages
Nodes MUST silently ignore the following Neighbor Discovery and Nodes MUST silently ignore the following Neighbor Discovery and
SEcure Neighbor Discovery messages if the packets carrying them SEcure Neighbor Discovery messages if the packets carrying them
include an IPv6 Fragmentation Header: include an IPv6 Fragmentation Header:
o Neighbor Solicitation o Neighbor Solicitation
o Neighbor Advertisement o Neighbor Advertisement
skipping to change at page 12, line 14 skipping to change at page 12, line 14
9. Acknowledgements 9. Acknowledgements
The author would like to thank (in alphabetical order) Mikael The author would like to thank (in alphabetical order) Mikael
Abrahamsson, Ran Atkinson, Ron Bonica, Jean-Michel Combes, David Abrahamsson, Ran Atkinson, Ron Bonica, Jean-Michel Combes, David
Farmer, Adrian Farrel, Stephen Farrell, Roque Gagliano, Brian Farmer, Adrian Farrel, Stephen Farrell, Roque Gagliano, Brian
Haberman, Bob Hinden, Philip Homburg, Ray Hunter, Arturo Servin, Mark Haberman, Bob Hinden, Philip Homburg, Ray Hunter, Arturo Servin, Mark
Smith, and Martin Stiemerling, for providing valuable comments on Smith, and Martin Stiemerling, for providing valuable comments on
earlier versions of this document. earlier versions of this document.
The author would like to thank Roque Gagliano, who contributed the
information regarding messages sizes in Appendix A.
This document resulted from the project "Security Assessment of the This document resulted from the project "Security Assessment of the
Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by
Fernando Gont on behalf of the UK Centre for the Protection of Fernando Gont on behalf of the UK Centre for the Protection of
National Infrastructure (CPNI). The author would like to thank the National Infrastructure (CPNI). The author would like to thank the
UK CPNI, for their continued support. UK CPNI, for their continued support.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
Profile and Certificate Management for SEcure Neighbor
Discovery (SEND)", RFC 6494, February 2012.
10.2. Informative References 10.2. Informative References
[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.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", RFC 6104, February 2011. Problem Statement", RFC 6104, February 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.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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).
[Gont-DEEPSEC2011] [Gont-DEEPSEC2011]
Gont, "Results of a Security Assessment of the Internet Gont, "Results of a Security Assessment of the Internet
Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Protocol version 6 (IPv6)", DEEPSEC 2011 Conference,
Vienna, Austria, November 2011, <http:// Vienna, Austria, November 2011, <http://
www.si6networks.com/presentations/deepsec2011/ www.si6networks.com/presentations/deepsec2011/
fgont-deepsec2011-ipv6-security.pdf>. fgont-deepsec2011-ipv6-security.pdf>.
Appendix A. Message Size When Carrying Certificates
This section aims at estimating the size of normal Certification Path
Advertisement messages.
Considering a Certification Path Advertisement (CPA) such as that of
Appendix C of [RFC3971] (certification path length of 4, between 1
and 4 address prefix extensions, and a key length of 1024 bits), the
certificate lengths range between 864 to 888 bytes (and the
corresponding Ethernet packets from 1050 to 1066 bytes) [RFC3971].
Updating the aforementioned packet size to account for the larger
(2048 bits) keys required by [RFC6494] results in packet sizes
ranging from 1127 to 1238 bytes, which are smaller than the minimum
IPv6 MTU (1280 bytes), and much smaller than the ubiquitous Ethernet
MTU (1500 bytes).
However, we note that packet sizes may vary depending on a number of
factors, including:
o the number of prefixes included in the certificate
o the length of Fully-Qualified Domain Names (FQDNs) in Trust Anchor
(TA) options [RFC3971] (if present)
If larger key sizes (i.e. 4096 bits) were required in the future, a
larger MTU size might be required to to convey such information in
Neighbor Discovery packets without the need to employ fragmentation.
Author's Address Author's Address
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
 End of changes. 12 change blocks. 
22 lines changed or deleted 62 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/