idnits 2.17.1
draft-gont-6man-nd-extension-headers-02.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 (January 12, 2012) is 4487 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 (-01) exists of
draft-gont-v6ops-ra-guard-implementation-00
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) January 12, 2012
5 Intended status: Standards Track
6 Expires: July 15, 2012
8 Security Implications of the Use of IPv6 Extension Headers with IPv6
9 Neighbor Discovery
10 draft-gont-6man-nd-extension-headers-02
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 July 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-01 . . . 12
72 A.2. Changes from draft-gont-6man-nd-extension-headers-00 . . . 12
73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
75 1. Introduction
77 The Neighbor Discovery Protocol (NDP) is specified in RFC 4861
78 [RFC4861] and RFC 4862 [RFC4862]. It is used by both hosts and
79 routers. Its functions include Neighbor Discovery (ND), Router
80 Discovery (RD), Address Autoconfiguration, Address Resolution,
81 Neighbor Unreachability Detection (NUD), Duplicate Address Detection
82 (DAD), and Redirection.
84 Many of the possible attacks against the Neighbor Discovery Protocol
85 are discussed in detail in [RFC3756]. In order to mitigate the
86 aforementioned possible attacks, the SEcure Neighbor Discovery (SEND)
87 was standardized. SEND employs a number of mechanisms to certify the
88 origin of Neighbor Discovery packets and the authority of routers,
89 and to protect Neighbor Discovery packets from being the subject of
90 modification or replay attacks.
92 However, a number of factors, such as the use of trust anchors and
93 the unavailability of SEND implementations for many widely-deployed
94 operating systems, make SEND hard to deploy [Gont-DEEPSEC2011].
95 Thus, in many general scenarios it may be necessary and/or convenient
96 to use other mitigation techniques for NDP-based attacks. The
97 following "lightweight" mitigations are currently available for NDP
98 attacks:
100 o Layer-2 filtering of Neighbor Discovery packets (such as RA-Guard
101 [RFC6105])
103 o Neighbor Discovery monitoring tools (e.g., such as NDPMon
104 [NDPMon])
106 IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique
107 for attack vectors based on ICMPv6 Router Advertisement messages. It
108 is meant to block attack packets at a layer-2 device before the
109 attack packets actually reach the target nodes. [RFC6104] describes
110 the problem statement of "Rogue IPv6 Router Advertisements", and
111 [RFC6105] specifies the "IPv6 Router Advertisement Guard"
112 functionality.
114 Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring
115 Neighbor Discovery traffic in the hopes of detecting possible attacks
116 when there are discrepancies between the information advertised in
117 Neighbor Discovery packets and the information stored on a local
118 database.
120 A key challenge that these mitigation or monitoring techniques face
121 is that introduced by IPv6 fragmentation, since it is trivial for an
122 attacker to conceal his attack by fragmenting his packets into
123 multiple fragments. This may limit or even eliminate the
124 effectiveness of the aforementioned mitigation or monitoring
125 techniques. Recent work [CPNI-IPv6] indicates that current
126 implementations of the aforementioned "lightweight" mitigations for
127 NDP attacks can be trivially evaded. For example, as noted in
128 [I-D.gont-v6ops-ra-guard-implementation], current RA-Guard
129 implementations can be trivially evaded by fragmenting the attack
130 packets into multiple fragments, such that the layer-2 device cannot
131 find all the necessary information to perform packet filtering in the
132 same packet. While Neighbor Discovery monitoring tools could (in
133 theory implement IPv6 fragment reassembly, this is usually an arms-
134 race with the attacker (an attacker generate lots of forged fragments
135 to "confuse" the monitoring tools), and therefore the aforementioned
136 tools are unreliable for the detection of such attacks.
138 Section 2 analyzes the use of IPv6 fragmentation in traditional
139 Neighbor discovery. Section 3 analyzes the use of IPv6 fragmentation
140 in SEcure Neighbor Discovery (SEND). Section 4 formally updates RFC
141 4861 such that use of the IPv6 Fragment Header with traditional
142 Neighbor Discovery is forbidden, and provides advice on the use of
143 IPv6 fragmentation with SEND.
145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
147 document are to be interpreted as described in RFC 2119 [RFC2119].
149 2. Traditional Neighbor Discovery and IPv6 Fragmentation
151 The only potential use case for IPv6 fragmentation with traditional
152 (i.e., non-SEND) IPv6 Neighbor Discovery would be that in which a
153 Router Advertisement must include a large number of options (Prefix
154 Information Options, Route Information Options, etc.). However, this
155 could still be achieved without employing fragmentation, by splitting
156 the aforementioned information into multiple Router Advertisement
157 messages.
159 Some Neighbor Discovery implementations are known to silently
160 ignore Router Advertisement messages that employ fragmentation.
161 Therefore, splitting the necessary information into multiple RA
162 messages (rather than sending a large RA message that is
163 fragmented into multiple IPv6 fragments) is probably desirable
164 even from an interoperability point of view.
166 As a result of the aforementioned considerations, and since avoiding
167 the use of IPv6 fragmentation in traditional Neighbor Discovery would
168 greatly simplify and improve the effectiveness of monitoring and
169 filtering ND, Section 4 specifies that hosts silently ignore
170 traditional Neighbor Discovery messages (i.e., those specified in
171 [RFC4861]) that employ IPv6 fragmentation.
173 3. SEcure Neighbor Discovery (SEND) and IPv6 Fragmentation
175 SEND packets typically carry more information than traditional
176 Neighbor Discovery packets: for example, they include additional
177 options such as the CGA option and the RSA signature option.
179 In the case of Neighbor Discovery messages specified in [RFC4861],
180 the situation is roughly the same: if more information than would fit
181 in a non-fragmented Neighbor Discovery packet needs to be sent, it
182 should be split into multiple Neighbor Discovery messages (such that
183 IPv6 fragmentation is avoided).
185 However, Certification Path Advertisement messages (specified in
186 [RFC3971]) pose a different situation, since the Certificate Option
187 they include contain much more information than any other Neighbor
188 Discovery option. For example, Appendix C of [RFC3971] reports
189 Certification Path Advertisement messages from 1050 to 1066 bytes on
190 an Ethernet link layer. Since the aforementioned packet sizes are
191 close to the minimum IPv6 MTU (1280 bytes), we note that IPv6
192 fragmentation must still be allowed for Certificate Path
193 Advertisement messages.
195 It should be noted that relying on fragmentation opens the door to a
196 variety of IPv6 fragmentation-based attacks. In particular, if an
197 attacker is located on the same broadcast domain as the victim host,
198 and Certification Path Advertisement messages employ IPv6
199 fragmentation, it would be trivial for the attacker to forge IPv6
200 fragment such that they result in "Fragment ID collisions", causing
201 both the attack fragments and the legitimate fragments to be
202 discarded by the victim node. This would eventually cause the
203 Authorization Delegation Discovery to fail, thus leading the host to
204 fall back (depending to local configuration) either to unsecured
205 mode, or to reject the corresponding Router Advertisement messages
206 (possibly resulting in a Denial of Service).
208 4. Specification
210 Nodes SHOULD NOT employ IPv6 fragmentation for sending any of the
211 following Neighbor Discovery and SEcure Neighbor Discovery messages:
212 Neighbor Solicitation, Neighbor Advertisement, Router Solicitation,
213 Router Advertisement, Redirect, Certification Path Solicitation, and
214 Certification Path Advertisement.
216 Nodes SHOULD silently ignore the following Neighbor Discovery and
217 SEcure Neighbor Discovery messages if the packets carrying them
218 include an IPv6 Fragmentation Header: Neighbor Solicitation, Neighbor
219 Advertisement, Router Solicitation, Router Advertisement, Redirect,
220 and Certification Path Solicitation.
222 Nodes SHOULD normally process Certification Path Advertisement
223 messages that employ IPv6 fragmentation.
225 5. Security Considerations
227 The IPv6 Fragmentation Header can be leveraged to circumvent network
228 monitoring tools and current implementations of mechanisms such as
229 RA-Guard [I-D.gont-v6ops-ra-guard-implementation]. By updating the
230 relevant specifications such that the IPv6 Fragment Header is not
231 allowed in any Neighbor Discovery messages except "Certification Path
232 Advertisement", protection of local nodes against Neighbor Discovery
233 attacks, and monitoring of Neighbor Discovery traffic is greatly
234 simplified.
236 [I-D.gont-v6ops-ra-guard-implementation] discusses an improvement to
237 the RA-Guard mechanism that can mitigate Neighbor Discovery attacks
238 that employ IPv6 Fragmentation. However, it should be noted that
239 unless [RFC4861] is updated (as proposed in this document), Neighbor
240 Discovery monitoring tools (such as NDPMon [NDPMon]) would remain
241 unreliable and trivial to circumvent by a skilled attacker.
243 As noted in Section 3, use of SEND could potentially result in
244 fragmented "Certification Path Advertisement" messages, thus allowing
245 an attacker to employ IPv6 fragmentation-based attacks against such
246 messages. Therefore, to the extent that is possible, such use of
247 fragmentation should be avoided.
249 6. Acknowledgements
251 The author would like to thank (in alphabetical order) Mikael
252 Abrahamsson, Ran Atkinson, Jean-Michel Combes, David Farmer, Bob
253 Hinden, Philip Homburg, Ray Hunter, Arturo Servin, and Mark Smith,
254 for providing valuable comments on earlier versions of this document.
256 This document resulted from the project "Security Assessment of the
257 Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by
258 Fernando Gont on behalf of the UK Centre for the Protection of
259 National Infrastructure (CPNI). The author would like to thank the
260 UK CPNI, for their continued support.
262 7. References
264 7.1. Normative References
266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
267 Requirement Levels", BCP 14, RFC 2119, March 1997.
269 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
270 Neighbor Discovery (SEND)", RFC 3971, March 2005.
272 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
273 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
274 September 2007.
276 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
277 Address Autoconfiguration", RFC 4862, September 2007.
279 7.2. Informative References
281 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
282 Discovery (ND) Trust Models and Threats", RFC 3756,
283 May 2004.
285 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
286 Problem Statement", RFC 6104, February 2011.
288 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
289 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
290 February 2011.
292 [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor",
293 .
295 [ramond] "ramond", .
297 [I-D.gont-v6ops-ra-guard-implementation]
298 Gont, F., "Implementation Advice for IPv6 Router
299 Advertisement Guard (RA-Guard)",
300 draft-gont-v6ops-ra-guard-implementation-00 (work in
301 progress), January 2012.
303 [CPNI-IPv6]
304 Gont, F., "Security Assessment of the Internet Protocol
305 version 6 (IPv6)", UK Centre for the Protection of
306 National Infrastructure, (available on request).
308 [Gont-DEEPSEC2011]
309 Gont, "Results of a Security Assessment of the Internet
310 Protocol version 6 (IPv6)", DEEPSEC 2011 Conference,
311 Vienna, Austria, November 2011, .
315 Appendix A. Changes from previous versions of the draft (to be removed
316 by the RFC Editor before publication of this document as a
317 RFC
319 A.1. Changes from draft-gont-6man-nd-extension-headers-01
321 o The I-D now forbids only the Fragment Header (rather than all
322 Extension Headers) with most ND packets.
324 o A discussion of the use of IPv6 fragmentation with ND and SEND was
325 added.
327 o Text was added noting that if SEND traffic is fragmented, this
328 would open the door to fragmentation-based attacks, which would
329 lead to trivial DoS attacks.
331 o Minor editorial changes
333 A.2. Changes from draft-gont-6man-nd-extension-headers-00
335 o The Security Considerations section now notes that unless IPv6
336 extension headers are not allowed with Neighbor Discovery
337 messages, monitoring ND traffic and/or mitigating ND
338 vulnerabilities might result in increased complexity and/or
339 reduced performance.
341 o Minor editorial changes
343 Author's Address
345 Fernando Gont
346 Centre for the Protection of National Infrastructure
348 Email: fernando@gont.com.ar
349 URI: http://www.cpni.gov.uk