idnits 2.17.1 draft-gont-6man-ipv6-smurf-amplifier-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- 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 (December 14, 2011) is 4515 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: 2460 (if approved) December 14, 2011 5 Intended status: Standards Track 6 Expires: June 16, 2012 8 Security Implications of IPv6 options of Type 10xxxxxx 9 draft-gont-6man-ipv6-smurf-amplifier-00 11 Abstract 13 When an IPv6 node processing an IPv6 packet does not support an IPv6 14 option whose two-highest-order bits of the Option Type are '10', it 15 is required to respond with an ICMPv6 Parameter Problem error 16 message, even if the Destination Address of the packet was a 17 multicast address. This feature provides an amplification vector, 18 opening the door to an IPv6 version of the 'Smurf' Denial-of-Service 19 (DoS) attack found in IPv4 networks. This document discusses the 20 security implications of the aforementioned options, and formally 21 updates RFC 2460 such that this attack vector is eliminated. 22 Additionally, it describes a number of operational mitigations that 23 could be deployed against this attack vector. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may not be modified, 29 and derivative works of it may not be created, and it may not be 30 published except as an Internet-Draft. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 16, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Proposed countermeasures . . . . . . . . . . . . . . . . . . . 4 63 2.1. Updating RFC 2460 . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Operational mitigations . . . . . . . . . . . . . . . . . . 4 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 As described in Section 4.2 of [RFC2460], when a node processing an 76 IPv6 packet does not support an IPv6 option whose two-highest-order 77 bits of the Option Type are '10', it should respond with an ICMPv6 78 Parameter Problem error message, even if the Destination Address of 79 the packet was a multicast address. This feature provides an 80 amplification vector, opening the door to an IPv6 version of the 81 'Smurf' Denial-of-Service (DoS) attack [CERT1998] [RFC6274] found in 82 IPv4 networks. 84 An attacker could exploit the aforementioned amplification vector by 85 sending forged IPv6 packets with the IPv6 address of the victim 86 system as the Source Address of his packets, a multicast address as 87 the Destination Address, and an unsupported option (with an Option 88 Type of '10xxxxxx') in a Destination Options Header. Upon receipt of 89 the forged packet, each processing node would respond with an ICMPv6 90 Parameter Problem, code 2, error message, pointing to the unsupported 91 option type. Thus, the systems belonging to the multicast group 92 specified by the multicast address contained in the Destination 93 Address field would serve as an 'amplifier network'. 95 It should be noted that if the multicast RPF check is used (e.g. 96 to prevent routing loops), this would prevent an attacker from 97 forging the Source Address of a packet to an arbitrary value, thus 98 preventing an attacker from launching this attack against a remote 99 network. 101 Chapter 5 of [Juniper2010] discusses multicast RPF configuration 102 for Juniper routers. 104 Section 2.1 updates RFC 2460 [RFC2460], such that the aforementioned 105 attack vector is eliminated. Section 2.2 describes a number of 106 operational mitigations for the aforementioned attack vector. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Proposed countermeasures 114 2.1. Updating RFC 2460 116 Considering the security implications discussed in Section 1, and 117 since there are no known legitimate uses of IPv6 options of type 118 '10xxxxxx', this document updates RFC 2460 [RFC2460] as follows: 120 A node that receives a packet containing an unsupported IPv6 option 121 of type '10xxxxxx', MUST process the packet as if the two-highest- 122 order bits of the option were '11'. That is, the packet should be 123 dropped, and an ICMPv6 Parameter Problem error message should be sent 124 to the Source Address of the packet subject to the ICMPv6 error 125 sending rules specified in [RFC4443] (which means that no ICMPv6 126 error message must be sent if the Destination Address of the 127 offending packet is a multicast address). 129 2.2. Operational mitigations 131 This section describes a number of operational mitigations that could 132 be implemented for the aforementioned attack vector: 134 o Firstly, IPv6 nodes should limit their ICMPv6 traffic. This is a 135 general mitigation technique for any bandwidth-exhaustion attack 136 that relies on ICMPv6 traffic. This could be enforced at the 137 hosts themselves, or at any router connecting such hosts to the 138 public network. 140 o Secondly, as noted in Section 1 of this document, the multicast 141 RPF check enabled such that an attacker cannot forge the Source 142 Address of a packet to an arbitrary value, thus preventing an 143 attacker from launching this attack against a remote network. 145 3. IANA Considerations 147 There are no IANA registries within this document. The RFC-Editor 148 can remove this section before publication of this document as an 149 RFC. 151 4. Security Considerations 153 This document describes how IPv6 options whose two-highest-order bits 154 of the Option Type are '10' could possibly be exploited to perform an 155 IPv6 version of the 'Smurf' Denial-of-Service (DoS) attack [CERT1998] 156 [RFC6274] found in IPv4 networks. It formally updates RFC 2460 157 [RFC2460] such that this attack vector is eliminated., and also 158 describes a number of operational mitigations that could be deployed 159 against this attack vector. 161 5. Acknowledgements 163 This document is based on the technical report "Security Assessment 164 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 165 Fernando Gont on behalf of the UK Centre for the Protection of 166 National Infrastructure (CPNI). 168 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 169 their continued support. 171 6. References 173 6.1. Normative References 175 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 176 (IPv6) Specification", RFC 2460, December 1998. 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 182 Message Protocol (ICMPv6) for the Internet Protocol 183 Version 6 (IPv6) Specification", RFC 4443, March 2006. 185 6.2. Informative References 187 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 188 Version 4", RFC 6274, July 2011. 190 [CPNI-IPv6] 191 Gont, F., "Security Assessment of the Internet Protocol 192 version 6 (IPv6)", UK Centre for the Protection of 193 National Infrastructure, (available on request). 195 [CERT1998] 196 CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of- 197 Service Attacks", 1998, 198 . 200 [Juniper2010] 201 Juniper, "JunosE Software for E Series Broadband Services 202 Routers Multicast Routing Configuration Guide", 2010, . 207 Author's Address 209 Fernando Gont 210 UK CPNI 212 Email: fgont@si6networks.com 213 URI: http://www.cpni.gov.uk