idnits 2.17.1
draft-gont-6man-nd-extension-headers-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
-- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii)
Publication Limitation clause. If this document is intended for
submission to the IESG for publication, this constitutes an error.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
-- The draft header indicates that this document updates RFC3971, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC3971, updated by this document, for
RFC5378 checks: 2003-10-17)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 13, 2012) is 4307 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-07) exists of
draft-ietf-v6ops-ra-guard-implementation-04
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 IPv6 maintenance Working Group (6man) F. Gont
3 Internet-Draft UK CPNI
4 Updates: 3971, 4861 (if approved) June 13, 2012
5 Intended status: Standards Track
6 Expires: December 15, 2012
8 Security Implications of the Use of IPv6 Extension Headers with IPv6
9 Neighbor Discovery
10 draft-gont-6man-nd-extension-headers-03
12 Abstract
14 This document analyzes the security implications of using IPv6
15 Extension Headers with Neighbor Discovery (ND) messages. It updates
16 RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden
17 in all Neighbor Discovery messages, thus allowing for simple and
18 effective counter-measures for Neighbor Discovery attacks. Finally,
19 it discusses the security implications of using IPv6 fragmentation
20 with SEcure Neighbor Discovery (SEND), and provides advice such that
21 the aforementioned security implications are mitigated.
23 Status of this Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79. This document may not be modified,
27 and derivative works of it may not be created, and it may not be
28 published except as an Internet-Draft.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on December 15, 2012.
42 Copyright Notice
44 Copyright (c) 2012 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2. Traditional Neighbor Discovery and IPv6 Fragmentation . . . . 5
61 3. SEcure Neighbor Discovery (SEND) and IPv6 Fragmentation . . . 6
62 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7
63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
67 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
68 Appendix A. Changes from previous versions of the draft (to
69 be removed by the RFC Editor before publication
70 of this document as a RFC . . . . . . . . . . . . . . 12
71 A.1. Changes from draft-gont-6man-nd-extension-headers-02 . . . 12
72 A.2. Changes from draft-gont-6man-nd-extension-headers-01 . . . 12
73 A.3. Changes from draft-gont-6man-nd-extension-headers-00 . . . 12
74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
76 1. Introduction
78 The Neighbor Discovery Protocol (NDP) is specified in RFC 4861
79 [RFC4861] and RFC 4862 [RFC4862]. It is used by both hosts and
80 routers. Its functions include Neighbor Discovery (ND), Router
81 Discovery (RD), Address Autoconfiguration, Address Resolution,
82 Neighbor Unreachability Detection (NUD), Duplicate Address Detection
83 (DAD), and Redirection.
85 Many of the possible attacks against the Neighbor Discovery Protocol
86 are discussed in detail in [RFC3756]. In order to mitigate the
87 aforementioned possible attacks, the SEcure Neighbor Discovery (SEND)
88 was standardized. SEND employs a number of mechanisms to certify the
89 origin of Neighbor Discovery packets and the authority of routers,
90 and to protect Neighbor Discovery packets from being the subject of
91 modification or replay attacks.
93 However, a number of factors, such as the use of trust anchors and
94 the unavailability of SEND implementations for many widely-deployed
95 operating systems, make SEND hard to deploy [Gont-DEEPSEC2011].
96 Thus, in many general scenarios it may be necessary and/or convenient
97 to use other mitigation techniques for NDP-based attacks. The
98 following "lightweight" mitigations are currently available for NDP
99 attacks:
101 o Layer-2 filtering of Neighbor Discovery packets (such as RA-Guard
102 [RFC6105])
104 o Neighbor Discovery monitoring tools (e.g., such as NDPMon
105 [NDPMon])
107 IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique
108 for attack vectors based on ICMPv6 Router Advertisement messages. It
109 is meant to block attack packets at a layer-2 device before the
110 attack packets actually reach the target nodes. [RFC6104] describes
111 the problem statement of "Rogue IPv6 Router Advertisements", and
112 [RFC6105] specifies the "IPv6 Router Advertisement Guard"
113 functionality.
115 Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring
116 Neighbor Discovery traffic in the hopes of detecting possible attacks
117 when there are discrepancies between the information advertised in
118 Neighbor Discovery packets and the information stored on a local
119 database.
121 A key challenge that these mitigation or monitoring techniques face
122 is that introduced by IPv6 fragmentation, since it is trivial for an
123 attacker to conceal his attack by fragmenting his packets into
124 multiple fragments. This may limit or even eliminate the
125 effectiveness of the aforementioned mitigation or monitoring
126 techniques. Recent work [CPNI-IPv6] indicates that current
127 implementations of the aforementioned "lightweight" mitigations for
128 NDP attacks can be trivially evaded. For example, as noted in
129 [I-D.ietf-v6ops-ra-guard-implementation], current RA-Guard
130 implementations can be trivially evaded by fragmenting the attack
131 packets into multiple fragments, such that the layer-2 device cannot
132 find all the necessary information to perform packet filtering in the
133 same packet. While Neighbor Discovery monitoring tools could (in
134 theory implement IPv6 fragment reassembly, this is usually an arms-
135 race with the attacker (an attacker generate lots of forged fragments
136 to "confuse" the monitoring tools), and therefore the aforementioned
137 tools are unreliable for the detection of such attacks.
139 Section 2 analyzes the use of IPv6 fragmentation in traditional
140 Neighbor discovery. Section 3 analyzes the use of IPv6 fragmentation
141 in SEcure Neighbor Discovery (SEND). Section 4 formally updates RFC
142 4861 such that use of the IPv6 Fragment Header with traditional
143 Neighbor Discovery is forbidden, and provides advice on the use of
144 IPv6 fragmentation with SEND.
146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
148 document are to be interpreted as described in RFC 2119 [RFC2119].
150 2. Traditional Neighbor Discovery and IPv6 Fragmentation
152 The only potential use case for IPv6 fragmentation with traditional
153 (i.e., non-SEND) IPv6 Neighbor Discovery would be that in which a
154 Router Advertisement must include a large number of options (Prefix
155 Information Options, Route Information Options, etc.). However, this
156 could still be achieved without employing fragmentation, by splitting
157 the aforementioned information into multiple Router Advertisement
158 messages.
160 Some Neighbor Discovery implementations are known to silently
161 ignore Router Advertisement messages that employ fragmentation.
162 Therefore, splitting the necessary information into multiple RA
163 messages (rather than sending a large RA message that is
164 fragmented into multiple IPv6 fragments) is probably desirable
165 even from an interoperability point of view.
167 As a result of the aforementioned considerations, and since avoiding
168 the use of IPv6 fragmentation in traditional Neighbor Discovery would
169 greatly simplify and improve the effectiveness of monitoring and
170 filtering ND, Section 4 specifies that hosts silently ignore
171 traditional Neighbor Discovery messages (i.e., those specified in
172 [RFC4861]) that employ IPv6 fragmentation.
174 3. SEcure Neighbor Discovery (SEND) and IPv6 Fragmentation
176 SEND packets typically carry more information than traditional
177 Neighbor Discovery packets: for example, they include additional
178 options such as the CGA option and the RSA signature option.
180 In the case of Neighbor Discovery messages specified in [RFC4861],
181 the situation is roughly the same: if more information than would fit
182 in a non-fragmented Neighbor Discovery packet needs to be sent, it
183 should be split into multiple Neighbor Discovery messages (such that
184 IPv6 fragmentation is avoided).
186 However, Certification Path Advertisement messages (specified in
187 [RFC3971]) pose a different situation, since the Certificate Option
188 they include contain much more information than any other Neighbor
189 Discovery option. For example, Appendix C of [RFC3971] reports
190 Certification Path Advertisement messages from 1050 to 1066 bytes on
191 an Ethernet link layer. Since the size of CPA messages could
192 potentially exceed the MTU of the local link, we recommend that
193 fragmented CPA messages be normally processed (although *sending*
194 fragmented CPA messages is discouraged).
196 It should be noted that relying on fragmentation opens the door to a
197 variety of IPv6 fragmentation-based attacks. In particular, if an
198 attacker is located on the same broadcast domain as the victim host,
199 and Certification Path Advertisement messages employ IPv6
200 fragmentation, it would be trivial for the attacker to forge IPv6
201 fragment such that they result in "Fragment ID collisions", causing
202 both the attack fragments and the legitimate fragments to be
203 discarded by the victim node. This would eventually cause the
204 Authorization Delegation Discovery to fail, thus leading the host to
205 fall back (depending to local configuration) either to unsecured
206 mode, or to reject the corresponding Router Advertisement messages
207 (possibly resulting in a Denial of Service).
209 4. Specification
211 Nodes MUST NOT employ IPv6 fragmentation for sending any of the
212 following Neighbor Discovery and SEcure Neighbor Discovery messages:
213 Neighbor Solicitation, Neighbor Advertisement, Router Solicitation,
214 Router Advertisement, Redirect, and Certification Path Solicitation.
215 SEND nodes SHOULD NOT employ IPv6 fragmentation for sending
216 Certification Path Advertisement messages.
218 Nodes MUST silently ignore the following Neighbor Discovery and
219 SEcure Neighbor Discovery messages if the packets carrying them
220 include an IPv6 Fragmentation Header: Neighbor Solicitation, Neighbor
221 Advertisement, Router Solicitation, Router Advertisement, Redirect,
222 and Certification Path Solicitation.
224 Nodes SHOULD normally process Certification Path Advertisement
225 messages that employ IPv6 fragmentation.
227 5. Security Considerations
229 The IPv6 Fragmentation Header can be leveraged to circumvent network
230 monitoring tools and current implementations of mechanisms such as
231 RA-Guard [I-D.ietf-v6ops-ra-guard-implementation]. By updating the
232 relevant specifications such that the IPv6 Fragment Header is not
233 allowed in any Neighbor Discovery messages except "Certification Path
234 Advertisement", protection of local nodes against Neighbor Discovery
235 attacks, and monitoring of Neighbor Discovery traffic is greatly
236 simplified.
238 [I-D.ietf-v6ops-ra-guard-implementation] discusses an improvement to
239 the RA-Guard mechanism that can mitigate Neighbor Discovery attacks
240 that employ IPv6 Fragmentation. However, it should be noted that
241 unless [RFC4861] is updated (as proposed in this document), Neighbor
242 Discovery monitoring tools (such as NDPMon [NDPMon]) would remain
243 unreliable and trivial to circumvent by a skilled attacker.
245 As noted in Section 3, use of SEND could potentially result in
246 fragmented "Certification Path Advertisement" messages, thus allowing
247 an attacker to employ IPv6 fragmentation-based attacks against such
248 messages. Therefore, to the extent that is possible, such use of
249 fragmentation should be avoided.
251 6. Acknowledgements
253 The author would like to thank (in alphabetical order) Mikael
254 Abrahamsson, Ran Atkinson, Ron Bonica, Jean-Michel Combes, David
255 Farmer, Roque Gagliano, Bob Hinden, Philip Homburg, Ray Hunter,
256 Arturo Servin, and Mark Smith, for providing valuable comments on
257 earlier versions of this document.
259 This document resulted from the project "Security Assessment of the
260 Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by
261 Fernando Gont on behalf of the UK Centre for the Protection of
262 National Infrastructure (CPNI). The author would like to thank the
263 UK CPNI, for their continued support.
265 7. References
267 7.1. Normative References
269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
270 Requirement Levels", BCP 14, RFC 2119, March 1997.
272 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
273 Neighbor Discovery (SEND)", RFC 3971, March 2005.
275 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
276 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
277 September 2007.
279 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
280 Address Autoconfiguration", RFC 4862, September 2007.
282 7.2. Informative References
284 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
285 Discovery (ND) Trust Models and Threats", RFC 3756,
286 May 2004.
288 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
289 Problem Statement", RFC 6104, February 2011.
291 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
292 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
293 February 2011.
295 [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor",
296 .
298 [ramond] "ramond", .
300 [I-D.ietf-v6ops-ra-guard-implementation]
301 Gont, F., "Implementation Advice for IPv6 Router
302 Advertisement Guard (RA-Guard)",
303 draft-ietf-v6ops-ra-guard-implementation-04 (work in
304 progress), May 2012.
306 [CPNI-IPv6]
307 Gont, F., "Security Assessment of the Internet Protocol
308 version 6 (IPv6)", UK Centre for the Protection of
309 National Infrastructure, (available on request).
311 [Gont-DEEPSEC2011]
312 Gont, "Results of a Security Assessment of the Internet
313 Protocol version 6 (IPv6)", DEEPSEC 2011 Conference,
314 Vienna, Austria, November 2011, .
318 Appendix A. Changes from previous versions of the draft (to be removed
319 by the RFC Editor before publication of this document as a
320 RFC
322 A.1. Changes from draft-gont-6man-nd-extension-headers-02
324 o Makes the requirement a "MUST" (rather than a "SHOULD").
326 o Clarifies the implications for SEND.
328 o This rev addresses feedback received from Ran Atkinson, Ron
329 Bonica, and Roque Gagliano.
331 A.2. Changes from draft-gont-6man-nd-extension-headers-01
333 o The I-D now forbids only the Fragment Header (rather than all
334 Extension Headers) with most ND packets.
336 o A discussion of the use of IPv6 fragmentation with ND and SEND was
337 added.
339 o Text was added noting that if SEND traffic is fragmented, this
340 would open the door to fragmentation-based attacks, which would
341 lead to trivial DoS attacks.
343 o Minor editorial changes
345 A.3. Changes from draft-gont-6man-nd-extension-headers-00
347 o The Security Considerations section now notes that unless IPv6
348 extension headers are not allowed with Neighbor Discovery
349 messages, monitoring ND traffic and/or mitigating ND
350 vulnerabilities might result in increased complexity and/or
351 reduced performance.
353 o Minor editorial changes
355 Author's Address
357 Fernando Gont
358 Centre for the Protection of National Infrastructure
360 Email: fernando@gont.com.ar
361 URI: http://www.cpni.gov.uk