draft-ietf-6man-nd-extension-headers-00.txt   draft-ietf-6man-nd-extension-headers-01.txt 
IPv6 maintenance Working Group (6man) F. Gont IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft UK CPNI Internet-Draft SI6 Networks / UTN-FRH
Updates: 3971, 4861 (if approved) June 29, 2012 Updates: 3971, 4861 (if approved) November 5, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: December 31, 2012 Expires: May 9, 2013
Security Implications of the Use of IPv6 Extension Headers with IPv6 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
Neighbor Discovery draft-ietf-6man-nd-extension-headers-01
draft-ietf-6man-nd-extension-headers-00
Abstract Abstract
This document analyzes the security implications of using IPv6 This document analyzes the security implications of using IPv6
Extension Headers with Neighbor Discovery (ND) messages. It updates Extension Headers with Neighbor Discovery (ND) messages. It updates
RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden
in all Neighbor Discovery messages, thus allowing for simple and in 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 provides advice such that with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971
the aforementioned security implications are mitigated. to provide advice regarding how the aforementioned security
implications can be prevented.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 31, 2012. This Internet-Draft will expire on May 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 3, line 27 skipping to change at page 3, line 27
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 use of trust anchors and
the unavailability of SEND implementations for many widely-deployed the unavailability of SEND implementations for many widely-deployed
operating systems, make SEND hard to deploy [Gont-DEEPSEC2011]. operating systems, make SEND hard to deploy [Gont-DEEPSEC2011].
Thus, in many general scenarios it may be necessary and/or convenient Thus, in many general scenarios it may be necessary and/or convenient
to use other mitigation techniques for NDP-based attacks. The to use other mitigation techniques for NDP-based attacks. The
following "lightweight" mitigations are currently available for NDP following mitigations are currently available for NDP attacks:
attacks:
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]) [NDPMon])
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
for attack vectors based on ICMPv6 Router Advertisement messages. It for attack vectors based on ICMPv6 Router Advertisement messages. It
is meant to block attack packets at a layer-2 device before the is meant to block attack packets at a layer-2 device before the
attack packets actually reach the target nodes. [RFC6104] describes attack packets actually reach the target nodes. [RFC6104] describes
the problem statement of "Rogue IPv6 Router Advertisements", and the problem statement of "Rogue IPv6 Router Advertisements", and
[RFC6105] specifies the "IPv6 Router Advertisement Guard" [RFC6105] specifies the "IPv6 Router Advertisement Guard"
functionality. functionality.
Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring
Neighbor Discovery traffic in the hopes of detecting possible attacks Neighbor Discovery traffic in the hopes of detecting possible attacks
when there are discrepancies between the information advertised in when there are discrepancies between the information advertised in
Neighbor Discovery packets and the information stored on a local Neighbor Discovery packets and the information stored on a local
database. database.
Some Intrusion Prevention Systems (IPS) can mitigate Neighbor
Discovery attacks. We recommend that Intrusion Prevention Systems
(IPS) implement mitigations for NDP attacks.
A key challenge that these mitigation or monitoring techniques face A key challenge that these mitigation or monitoring techniques face
is that introduced by IPv6 fragmentation, since it is trivial for an is that introduced by IPv6 fragmentation, since it is trivial for an
attacker to conceal his attack by fragmenting his packets into attacker to conceal his attack by fragmenting his packets into
multiple fragments. This may limit or even eliminate the multiple fragments. This may limit or even eliminate the
effectiveness of the aforementioned mitigation or monitoring effectiveness of the aforementioned mitigation or monitoring
techniques. Recent work [CPNI-IPv6] indicates that current techniques. Recent work [CPNI-IPv6] indicates that current
implementations of the aforementioned "lightweight" mitigations for implementations of the aforementioned mitigations for NDP attacks can
NDP attacks can be trivially evaded. For example, as noted in be trivially evaded. For example, as noted in
[I-D.ietf-v6ops-ra-guard-implementation], current RA-Guard [I-D.ietf-v6ops-ra-guard-implementation], current RA-Guard
implementations can be trivially evaded by fragmenting the attack implementations can be trivially evaded by fragmenting the attack
packets into multiple fragments, such that the layer-2 device cannot packets into multiple fragments, such that the layer-2 device cannot
find all the necessary information to perform packet filtering in the find all the necessary information to perform packet filtering in the
same packet. While Neighbor Discovery monitoring tools could (in same packet. While Neighbor Discovery monitoring tools could (in
theory implement IPv6 fragment reassembly, this is usually an arms- theory implement IPv6 fragment reassembly, this is usually an arms-
race with the attacker (an attacker generate lots of forged fragments race with the attacker (an attacker generate lots of forged fragments
to "confuse" the monitoring tools), and therefore the aforementioned to "confuse" the monitoring tools), and therefore the aforementioned
tools are unreliable for the detection of such attacks. tools are unreliable for the detection of such attacks.
Section 2 analyzes the use of IPv6 fragmentation in traditional Section 2 analyzes the use of IPv6 fragmentation in traditional
Neighbor discovery. Section 3 analyzes the use of IPv6 fragmentation Neighbor discovery. Section 3 analyzes the use of IPv6 fragmentation
in SEcure Neighbor Discovery (SEND). Section 4 formally updates RFC in SEcure Neighbor Discovery (SEND). Section 4 formally updates RFC
4861 such that use of the IPv6 Fragment Header with traditional 4861 such that use of the IPv6 Fragment Header with traditional
Neighbor Discovery is forbidden, and provides advice on the use of Neighbor Discovery is forbidden, and also formally updates RFC 3971
IPv6 fragmentation with SEND. providing advice on the use of IPv6 fragmentation with SEND.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Traditional Neighbor Discovery and IPv6 Fragmentation 2. Traditional Neighbor Discovery and IPv6 Fragmentation
The only potential use case for IPv6 fragmentation with traditional The only potential use case for IPv6 fragmentation with traditional
(i.e., non-SEND) IPv6 Neighbor Discovery would be that in which a (i.e., non-SEND) IPv6 Neighbor Discovery would be that in which a
Router Advertisement must include a large number of options (Prefix Router Advertisement must include a large number of options (Prefix
skipping to change at page 6, line 11 skipping to change at page 6, line 11
filtering ND, Section 4 specifies that hosts silently ignore filtering ND, Section 4 specifies that hosts silently ignore
traditional Neighbor Discovery messages (i.e., those specified in traditional Neighbor Discovery messages (i.e., those specified in
[RFC4861]) that employ IPv6 fragmentation. [RFC4861]) that employ IPv6 fragmentation.
3. SEcure Neighbor Discovery (SEND) and IPv6 Fragmentation 3. SEcure Neighbor Discovery (SEND) and IPv6 Fragmentation
SEND packets typically carry more information than traditional SEND packets typically carry more information than traditional
Neighbor Discovery packets: for example, they include additional Neighbor Discovery packets: for example, they include additional
options such as the CGA option and the RSA signature option. options such as the CGA option and the RSA signature option.
In the case of Neighbor Discovery messages specified in [RFC4861], When SEND nodes employ any of the Neighbor Discovery messages
the situation is roughly the same: if more information than would fit specified in [RFC4861], the situation is roughly the same: if more
in a non-fragmented Neighbor Discovery packet needs to be sent, it information than would fit in a non-fragmented Neighbor Discovery
should be split into multiple Neighbor Discovery messages (such that packet needs to be sent, it should be split into multiple Neighbor
IPv6 fragmentation is avoided). Discovery messages (such that IPv6 fragmentation is avoided).
However, Certification Path Advertisement messages (specified in However, Certification Path Advertisement messages (specified in
[RFC3971]) pose a different situation, since the Certificate Option [RFC3971]) pose a different situation, since the Certificate Option
they include contain much more information than any other Neighbor they include typically contains much more information than any other
Discovery option. For example, Appendix C of [RFC3971] reports Neighbor Discovery option. For example, Appendix C of [RFC3971]
Certification Path Advertisement messages from 1050 to 1066 bytes on reports Certification Path Advertisement messages from 1050 to 1066
an Ethernet link layer. Since the size of CPA messages could bytes on an Ethernet link layer. Since the size of CPA messages
potentially exceed the MTU of the local link, we recommend that could potentially exceed the MTU of the local link, Section 4
fragmented CPA messages be normally processed (although *sending* recommends that fragmented CPA messages be normally processed, but
fragmented CPA messages is discouraged). discourages the use of keys that would result in fragmented CPA
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. In particular, if an
attacker is located on the same broadcast domain as the victim host, attacker is located on the same broadcast domain as the victim host,
and Certification Path Advertisement messages employ IPv6 and Certification Path Advertisement messages employ IPv6
fragmentation, it would be trivial for the attacker to forge IPv6 fragmentation, it would be trivial for the attacker to forge IPv6
fragment such that they result in "Fragment ID collisions", causing fragments such that they result in "Fragment ID collisions", causing
both the attack fragments and the legitimate fragments to be 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 to fail, thus leading the host to
fall back (depending to local configuration) either to unsecured fall back (depending on local configuration) either to unsecured
mode, or to reject the corresponding Router Advertisement messages mode, or to reject the corresponding Router Advertisement messages
(possibly resulting in a Denial of Service). (possibly resulting in a Denial of Service).
4. Specification 4. Specification
Nodes MUST NOT employ IPv6 fragmentation for sending any of the Nodes MUST NOT employ IPv6 fragmentation for sending any of the
following Neighbor Discovery and SEcure Neighbor Discovery messages: following Neighbor Discovery and SEcure Neighbor Discovery messages:
Neighbor Solicitation, Neighbor Advertisement, Router Solicitation,
Router Advertisement, Redirect, and Certification Path Solicitation. o Neighbor Solicitation
SEND nodes SHOULD NOT employ IPv6 fragmentation for sending
Certification Path Advertisement messages. o Neighbor Advertisement
o Router Solicitation
o Router Advertisement
o Redirect
o Certification Path Solicitation
Nodes SHOULD NOT employ IPv6 fragmentation for sending the following
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: Neighbor Solicitation, Neighbor include an IPv6 Fragmentation Header:
Advertisement, Router Solicitation, Router Advertisement, Redirect,
and Certification Path Solicitation.
Nodes SHOULD normally process Certification Path Advertisement o Neighbor Solicitation
messages that employ IPv6 fragmentation.
o Neighbor Advertisement
o Router Solicitation
o Router Advertisement
o Redirect
o Certification Path Solicitation
Nodes SHOULD normally process the following messages when the packets
carrying them include an IPv6 Fragmentation Header:
o Certification Path Advertisement
SEND nodes SHOULD NOT employ keys that would result in fragmented CPA
messages.
5. Security Considerations 5. Security Considerations
The IPv6 Fragmentation Header can be leveraged to circumvent network The IPv6 Fragmentation Header can be leveraged to circumvent network
monitoring tools and current implementations of mechanisms such as monitoring tools and current implementations of mechanisms such as
RA-Guard [I-D.ietf-v6ops-ra-guard-implementation]. By updating the RA-Guard [I-D.ietf-v6ops-ra-guard-implementation]. By updating the
relevant specifications such that the IPv6 Fragment Header is not relevant specifications such that the IPv6 Fragment Header is not
allowed in any Neighbor Discovery messages except "Certification Path allowed in any Neighbor Discovery messages except "Certification Path
Advertisement", protection of local nodes against Neighbor Discovery Advertisement", protection of local nodes against Neighbor Discovery
attacks, and monitoring of Neighbor Discovery traffic is greatly attacks, and monitoring of Neighbor Discovery traffic is greatly
skipping to change at page 10, line 43 skipping to change at page 10, line 43
February 2011. February 2011.
[NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor",
<http://ndpmon.sourceforge.net/>. <http://ndpmon.sourceforge.net/>.
[ramond] "ramond", <http://ramond.sourceforge.net/>. [ramond] "ramond", <http://ramond.sourceforge.net/>.
[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-04 (work in draft-ietf-v6ops-ra-guard-implementation-05 (work in
progress), May 2012. progress), October 2012.
[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).
[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>.
Author's Address Author's Address
Fernando Gont Fernando Gont
Centre for the Protection of National Infrastructure SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Email: fernando@gont.com.ar Phone: +54 11 4650 8472
URI: http://www.cpni.gov.uk Email: fgont@si6networks.com
URI: http://www.si6networks.com
 End of changes. 20 change blocks. 
41 lines changed or deleted 78 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/