idnits 2.17.1 draft-krishnan-ipv6-hopbyhop-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (October 22, 2010) is 4934 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 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 October 22, 2010 5 Expires: April 25, 2011 7 The case against Hop-by-Hop options 8 draft-krishnan-ipv6-hopbyhop-05 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 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). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 25, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 2. Details of the attack . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Effects of the attack . . . . . . . . . . . . . . . . . . 4 57 3. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Skipping . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Rate limiting . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Recommendation to protocol designers . . . . . . . . . . . . . 6 62 5. Impact on deployed IPv6 nodes . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 The IPv6 base specification [RFC2460] defines the hop-by-hop 71 extension header. This extension header carries the options which 72 need to be processed by every node along the path of the datagram. 73 Certain characteristics of the specification make it especially 74 vulnerable to Denial of Service attacks. The characteristics are: 76 o All the ipv6 nodes on the path need to process the options in this 77 header 79 o The option TLVs in the hop-by-hop options header need to be 80 processed in order 82 o A sub range of option types in this header will not cause any 83 errors even if the node does not recognize them. 85 o There is no restriction as to how many occurences of an option 86 type can be present in the hop-by-hop header. 88 This document details a low bandwidth Denial of Service attack on 89 ipv6 routers/hosts using the hop-by-hop options extension header and 90 possible ways of mitigating these attacks. 92 1.1. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Details of the attack 100 The denial of service attack can be carried out by forming an IP 101 datagram with a large number of TLV encoded options with random 102 option type identifiers in the hop-by-hop options header. The option 103 type is a 8 bit field with special meaning attached to the three most 104 significant bits. The attack is most effective when all the nodes in 105 the path are affected, meaning we do not want any node to drop the 106 packet and send ICMP errors regarding unrecognized options. If the 107 two most significant bits are cleared(0), the receiving node will 108 silently ignore the option if it does not recognize the option type. 109 The third most significant bit is used to denote whether the option 110 data can change en-route. If the bit is set to 1 the option data can 111 change en route. The attack is equally effective whether or not an 112 IPSec Authentication Header(AH) treats the option data as zero valued 113 octets. Hence we can include this bit in generating option types. 114 The acceptable option types would be laid out like below 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 117 | Option Type | Opt Data Len | Option Data 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 119 |0 0 x x x x x x|...............|................. 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 122 Figure 1: Option type layout 124 Since the option types 0(0x00) and 1(0x01) are reserved for the Pad1 125 and PadN options in [RFC2460] we exclude these from the acceptable 126 range as well. So we choose the option type identifiers for each of 127 these options to be in the range 0x02-0x63. More option types 128 defined by other RFCs can be excluded from the attack as and when 129 they are allocated by the IANA. Examples are Tunnel Encapsulation 130 limit (0x04) and Router Alert (0x05). 132 2.1. Effects of the attack 134 The attack can be used to cripple the routers by attacking the 135 control processor rather than the forwarding plane. Since the 136 control traffic, like the routing protocols, shares the same 137 resources with this traffic, this kind of attack may be hard to 138 control. On routers having separate Control and Forwarding elements 139 only the Control traffic would be affected. For routers whose the 140 Control and Forwarding elements are fused together this would lead to 141 problems with forwarding packets as well. 143 3. Proposed Solutions 145 There are at least three possible solutions to handle the DoS attack 146 mentioned in this draft. The first one is to get rid of the feature 147 altogether and prevent the attacks. The second one is to limit the 148 attacks to nodes that need to process hop-by-hop options. The third 149 is to let the attacks occur, but limit the damage. 151 3.1. Deprecation 153 The first solution is to deprecate hop-by-hop options from the IPv6 154 specification and to stop allocation of any new ones. The existing 155 hop-by-hop options MAY be grandfathered but new ones MUST NOT be 156 allocated. This allows existing protocols depending on hop-by-hop 157 options to continue working, but discourages the development of new 158 solutions based on hop-by-hop options. 160 3.2. Skipping 162 This option allows nodes to skip over the hop-by-hop extension header 163 without processing any of the options contained in the header. If a 164 node receives an IPv6 datagram with a hop-by-hop header, and it does 165 not support any hop-by-hop options at all, it can just skip over the 166 header. 168 3.3. Rate limiting 170 A less severe (and less effective) solution is to simply rate limit 171 packets with hop-by-hop option headers and start dropping them 172 randomly when the CPU load becomes very high. While this solution is 173 very simple and has no impact on deployed IPv6 nodes, it is sub- 174 optimal. A legitimate packet with a hop-by-hop option header has the 175 same probability of being dropped as an attack packet. Implementing 176 the solution proposed in this draft does not preclude the use of rate 177 limiting. In fact it gives a legitimate packet a lower probability 178 of being dropped, since most of the obvious attack traffic would have 179 been dropped by the receiving algorithm. 181 4. Recommendation to protocol designers 183 This document recommends protocol designers to avoid using hop-by-hop 184 options in any new protocols. An effect similar to hop-by-hop 185 options can be achieved by using extension headers instead. 186 Extension headers act similar to hop-by-hop options where the first 187 two bits of the option type are "11". 189 5. Impact on deployed IPv6 nodes 191 The proposed changes can affect all currently IPv6 nodes which need 192 to send and receive packets with hop-by-hop options. If the 193 deprecation option is chosen, the IPv6 stack on both sending and 194 receiving nodes needs to be modified to not send or receive hop-by- 195 hop options. In addition, transit nodes need to be modified as well 196 in order to not inspect these options. 198 6. Security Considerations 200 This document highlights the possible security issues with the IPv6 201 hop-by-hop option header specified in [RFC2460] which can lead to 202 denial of service attacks and suggests some changes to reduce the 203 effect of the DoS attacks. 205 7. IANA Considerations 207 This requests IANA to stop allocation of new entries for IPv6 hop-by- 208 hop option types. 210 8. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", RFC 2119, March 1997. 215 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 216 (IPv6) Specification", RFC 2460, December 1998. 218 Author's Address 220 Suresh Krishnan 221 Ericsson 222 8400 Decarie Blvd. 223 Town of Mount Royal, QC 224 Canada 226 Email: suresh.krishnan@ericsson.com