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