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