idnits 2.17.1 draft-krishnan-ipv6-hopbyhop-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 -- 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 (March 8, 2010) is 5155 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Informational March 8, 2010 5 Expires: September 9, 2010 7 The case against Hop-by-Hop options 8 draft-krishnan-ipv6-hopbyhop-04 10 Abstract 12 The Hop-by-Hop option header is a type of IPv6 extension header that 13 has been defined in the IPv6 protocol specification. The contents of 14 this header need to be processed by every node along the path of an 15 IPv6 datagram.This draft highlights the characteristics of this 16 extension header which make it prone to Denial of Service attacks and 17 proposes solutions to minimize such attacks. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 9, 2010. 42 Copyright Notice 44 Copyright (c) 2010 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 BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions used in this document . . . . . . . . . . . . 3 61 2. Details of the attack . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Effects of the attack . . . . . . . . . . . . . . . . . . 4 63 3. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Skipping . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Rate limiting . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Recommendation to protocol designers . . . . . . . . . . . . . 6 68 5. Impact on deployed IPv6 nodes . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 The IPv6 base specification [RFC2460] defines the hop-by-hop 77 extension header. This extension header carries the options which 78 need to be processed by every node along the path of the datagram. 79 Certain characteristics of the specification make it especially 80 vulnerable to Denial of Service attacks. The characteristics are: 82 o All the ipv6 nodes on the path need to process the options in this 83 header 85 o The option TLVs in the hop-by-hop options header need to be 86 processed in order 88 o A sub range of option types in this header will not cause any 89 errors even if the node does not recognize them. 91 o There is no restriction as to how many occurences of an option 92 type can be present in the hop-by-hop header. 94 This document details a low bandwidth Denial of Service attack on 95 ipv6 routers/hosts using the hop-by-hop options extension header and 96 possible ways of mitigating these attacks. 98 1.1. Conventions used in this document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Details of the attack 106 The denial of service attack can be carried out by forming an IP 107 datagram with a large number of TLV encoded options with random 108 option type identifiers in the hop-by-hop options header. The option 109 type is a 8 bit field with special meaning attached to the three most 110 significant bits. The attack is most effective when all the nodes in 111 the path are affected, meaning we do not want any node to drop the 112 packet and send ICMP errors regarding unrecognized options. If the 113 two most significant bits are cleared(0), the receiving node will 114 silently ignore the option if it does not recognize the option type. 115 The third most significant bit is used to denote whether the option 116 data can change en-route. If the bit is set to 1 the option data can 117 change en route. The attack is equally effective whether or not an 118 IPSec Authentication Header(AH) treats the option data as zero valued 119 octets. Hence we can include this bit in generating option types. 120 The acceptable option types would be laid out like below 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 123 | Option Type | Opt Data Len | Option Data 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 125 |0 0 x x x x x x|...............|................. 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 128 Figure 1: Option type layout 130 Since the option types 0(0x00) and 1(0x01) are reserved for the Pad1 131 and PadN options in [RFC2460] we exclude these from the acceptable 132 range as well. So we choose the option type identifiers for each of 133 these options to be in the range 0x02-0x63. More option types 134 defined by other RFCs can be excluded from the attack as and when 135 they are allocated by the IANA. Examples are Tunnel Encapsulation 136 limit (0x04) and Router Alert (0x05). 138 2.1. Effects of the attack 140 The attack can be used to cripple the routers by attacking the 141 control processor rather than the forwarding plane. Since the 142 control traffic, like the routing protocols, shares the same 143 resources with this traffic, this kind of attack may be hard to 144 control. On routers having separate Control and Forwarding elements 145 only the Control traffic would be affected. For routers whose the 146 Control and Forwarding elements are fused together this would lead to 147 problems with forwarding packets as well. 149 3. Proposed Solutions 151 There are at least three possible solutions to handle the DoS attack 152 mentioned in this draft. The first one is to get rid of the feature 153 altogether and prevent the attacks. The second one is to limit the 154 attacks to nodes that need to process hop-by-hop options. The third 155 is to let the attacks occur, but limit the damage. 157 3.1. Deprecation 159 The first solution is to deprecate hop-by-hop options from the IPv6 160 specification and to stop allocation of any new ones. The existing 161 hop-by-hop options MAY be grandfathered but new ones MUST NOT be 162 allocated. This allows existing protocols depending on hop-by-hop 163 options to continue working, but discourages the development of new 164 solutions based on hop-by-hop options. 166 3.2. Skipping 168 This option allows nodes to skip over the hop-by-hop extension header 169 without processing any of the options contained in the header. If a 170 node receives an IPv6 datagram with a hop-by-hop header, and it does 171 not support any hop-by-hop options at all, it can just skip over the 172 header. 174 3.3. Rate limiting 176 A less severe (and less effective) solution is to simply rate limit 177 packets with hop-by-hop option headers and start dropping them 178 randomly when the CPU load becomes very high. While this solution is 179 very simple and has no impact on deployed IPv6 nodes, it is sub- 180 optimal. A legitimate packet with a hop-by-hop option header has the 181 same probability of being dropped as an attack packet. Implementing 182 the solution proposed in this draft does not preclude the use of rate 183 limiting. In fact it gives a legitimate packet a lower probability 184 of being dropped, since most of the obvious attack traffic would have 185 been dropped by the receiving algorithm. 187 4. Recommendation to protocol designers 189 This document recommends protocol designers to avoid using hop-by-hop 190 options in any new protocols. An effect similar to hop-by-hop 191 options can be achieved by using extension headers instead. 192 Extension headers act similar to hop-by-hop options where the first 193 two bits of the option type are "11". 195 5. Impact on deployed IPv6 nodes 197 The proposed changes can affect all currently IPv6 nodes which need 198 to send and receive packets with hop-by-hop options. If the 199 deprecation option is chosen, the IPv6 stack on both sending and 200 receiving nodes needs to be modified to not send or receive hop-by- 201 hop options. In addition, transit nodes need to be modified as well 202 in order to not inspect these options. 204 6. Security Considerations 206 This document highlights the possible security issues with the IPv6 207 hop-by-hop option header specified in [RFC2460] which can lead to 208 denial of service attacks and suggests some changes to reduce the 209 effect of the DoS attacks. 211 7. IANA Considerations 213 This requests IANA to stop allocation of new entries for IPv6 hop-by- 214 hop option types. 216 8. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", RFC 2119, March 1997. 221 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 222 (IPv6) Specification", RFC 2460, December 1998. 224 Author's Address 226 Suresh Krishnan 227 Ericsson 228 8400 Decarie Blvd. 229 Town of Mount Royal, QC 230 Canada 232 Email: suresh.krishnan@ericsson.com