idnits 2.17.1 draft-krishnan-ipv6-hopbyhop-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (July 14, 2009) is 5398 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: 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: Standards Track July 14, 2009 5 Expires: January 15, 2010 7 The case against Hop-by-Hop options 8 draft-krishnan-ipv6-hopbyhop-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 15, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The Hop-by-Hop option header is a type of IPv6 extension header that 47 has been defined in the IPv6 protocol specification. The contents of 48 this header need to be processed by every node along the path of an 49 IPv6 datagram.This draft highlights the characteristics of this 50 extension header which make it prone to Denial of Service attacks and 51 proposes solutions to minimize such attacks. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions used in this document . . . . . . . . . . . . 3 57 2. Details of the attack . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Effects of the attack . . . . . . . . . . . . . . . . . . 4 59 3. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Skipping . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Rate limiting . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Impact on deployed IPv6 nodes . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The IPv6 base specification [RFC2460] defines the hop-by-hop 72 extension header. This extension header carries the options which 73 need to be processed by every node along the path of the datagram. 74 Certain characteristics of the specification make it especially 75 vulnerable to Denial of Service attacks. The characteristics are: 77 o All the ipv6 nodes on the path need to process the options in this 78 header 80 o The option TLVs in the hop-by-hop options header need to be 81 processed in order 83 o A sub range of option types in this header will not cause any 84 errors even if the node does not recognize them. 86 o There is no restriction as to how many occurences of an option 87 type can be present in the hop-by-hop header. 89 This document details a low bandwidth Denial of Service attack on 90 ipv6 routers/hosts using the hop-by-hop options extension header and 91 possible ways of mitigating these attacks. 93 1.1. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Details of the attack 101 The denial of service attack can be carried out by forming an IP 102 datagram with a large number of TLV encoded options with random 103 option type identifiers in the hop-by-hop options header. The option 104 type is a 8 bit field with special meaning attached to the three most 105 significant bits. The attack is most effective when all the nodes in 106 the path are affected, meaning we do not want any node to drop the 107 packet and send ICMP errors regarding unrecognized options. If the 108 two most significant bits are cleared(0), the receiving node will 109 silently ignore the option if it does not recognize the option type. 110 The third most significant bit is used to denote whether the option 111 data can change en-route. If the bit is set to 1 the option data can 112 change en route. The attack is equally effective whether or not an 113 IPSec Authentication Header(AH) treats the option data as zero valued 114 octets. Hence we can include this bit in generating option types. 115 The acceptable option types would be laid out like below 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 118 | Option Type | Opt Data Len | Option Data 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 120 |0 0 x x x x x x|...............|................. 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 123 Figure 1: Option type layout 125 Since the option types 0(0x00) and 1(0x01) are reserved for the Pad1 126 and PadN options in [RFC2460] we exclude these from the acceptable 127 range as well. So we choose the option type identifiers for each of 128 these options to be in the range 0x02-0x63. More option types 129 defined by other RFCs can be excluded from the attack as and when 130 they are allocated by the IANA. Examples are Tunnel Encapsulation 131 limit (0x04) and Router Alert (0x05). 133 2.1. Effects of the attack 135 The attack can be used to cripple the routers by attacking the 136 control processor rather than the forwarding plane. Since the 137 control traffic, like the routing protocols, shares the same 138 resources with this traffic, this kind of attack may be hard to 139 control. On routers having separate Control and Forwarding elements 140 only the Control traffic would be affected. For routers whose the 141 Control and Forwarding elements are fused together this would lead to 142 problems with forwarding packets as well. 144 3. Proposed Solutions 146 There are at least three possible solutions to handle the DoS attack 147 mentioned in this draft. The first one is to get rid of the feature 148 altogether and prevent the attacks. The second one is to limit the 149 attacks to nodes that need to process hop-by-hop options. The third 150 is to let the attacks occur, but limit the damage. 152 3.1. Deprecation 154 The first solution is to deprecate hop-by-hop options from the IPv6 155 specification and to stop allocation of any new ones. The existing 156 hop-by-hop options MAY be grandfathered but new ones MUST NOT be 157 allocated. This allows existing protocols depending on hop-by-hop 158 options to continue working, but discourages the development of new 159 solutions based on hop-by-hop options. 161 3.2. Skipping 163 This option allows nodes to skip over the hop-by-hop extension header 164 without processing any of the options contained in the header. If a 165 node receives an IPv6 datagram with a hop-by-hop header, and it does 166 not support any hop-by-hop options at all, it can just skip over the 167 header. 169 3.3. Rate limiting 171 A less severe (and less effective) solution is to simply rate limit 172 packets with hop-by-hop option headers and start dropping them 173 randomly when the CPU load becomes very high. While this solution is 174 very simple and has no impact on deployed IPv6 nodes, it is sub- 175 optimal. A legitimate packet with a hop-by-hop option header has the 176 same probability of being dropped as an attack packet. Implementing 177 the solution proposed in this draft does not preclude the use of rate 178 limiting. In fact it gives a legitimate packet a lower probability 179 of being dropped, since most of the obvious attack traffic would have 180 been dropped by the receiving algorithm. 182 4. Impact on deployed IPv6 nodes 184 The proposed changes can affect all currently IPv6 nodes which need 185 to send and receive packets with hop-by-hop options. If the 186 deprecation option is chosen, the IPv6 stack on both sending and 187 receiving nodes needs to be modified to not send or receive hop-by- 188 hop options. In addition, transit nodes need to be modified as well 189 in order to not inspect these options. 191 5. Security Considerations 193 This document highlights the possible security issues with the IPv6 194 hop-by-hop option header specified in [RFC2460] which can lead to 195 denial of service attacks and suggests some changes to reduce the 196 effect of the DoS attacks. 198 6. IANA Considerations 200 This requests IANA to stop allocation of new entries for IPv6 hop-by- 201 hop option types. 203 7. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", RFC 2119, March 1997. 208 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 209 (IPv6) Specification", RFC 2460, December 1998. 211 Author's Address 213 Suresh Krishnan 214 Ericsson 215 8400 Decarie Blvd. 216 Town of Mount Royal, QC 217 Canada 219 Email: suresh.krishnan@ericsson.com