idnits 2.17.1 draft-krishnan-ipv6-hopbyhop-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 255. 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 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 (February 24, 2008) is 5878 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 (==), 7 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 February 24, 2008 5 Expires: August 27, 2008 7 The case against Hop-by-Hop options 8 draft-krishnan-ipv6-hopbyhop-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 27, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The Hop-by-Hop option header is a type of IPv6 extension header that 42 has been defined in the IPv6 protocol specification. The contents of 43 this header need to be processed by every node along the path of an 44 IPv6 datagram.This draft highlights the characteristics of this 45 extension header which make it prone to Denial of Service attacks and 46 proposes solutions to minimize such attacks. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Conventions used in this document . . . . . . . . . . . . 3 52 2. Details of the attack . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Effects of the attack . . . . . . . . . . . . . . . . . . 4 54 3. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Skipping . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.3. Rate limiting . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Impact on deployed IPv6 nodes . . . . . . . . . . . . . . . . 6 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Intellectual Property and Copyright Statements . . . . . . . . . . 11 65 1. Introduction 67 The IPv6 base specification [RFC2460] defines the hop-by-hop 68 extension header. This extension header carries the options which 69 need to be processed by every node along the path of the datagram. 70 Certain characteristics of the specification make it especially 71 vulnerable to Denial of Service attacks. The characteristics are: 73 o All the ipv6 nodes on the path need to process the options in this 74 header 76 o The option TLVs in the hop-by-hop options header need to be 77 processed in order 79 o A sub range of option types in this header will not cause any 80 errors even if the node does not recognize them. 82 o There is no restriction as to how many occurences of an option 83 type can be present in the hop-by-hop header. 85 This document details a low bandwidth Denial of Service attack on 86 ipv6 routers/hosts using the hop-by-hop options extension header and 87 possible ways of mitigating these attacks. 89 1.1. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Details of the attack 97 The denial of service attack can be carried out by forming an IP 98 datagram with a large number of TLV encoded options with random 99 option type identifiers in the hop-by-hop options header. The option 100 type is a 8 bit field with special meaning attached to the three most 101 significant bits. The attack is most effective when all the nodes in 102 the path are affected, meaning we do not want any node to drop the 103 packet and send ICMP errors regarding unrecognized options. If the 104 two most significant bits are cleared(0), the receiving node will 105 silently ignore the option if it does not recognize the option type. 106 The third most significant bit is used to denote whether the option 107 data can change en-route. If the bit is set to 1 the option data can 108 change en route. The attack is equally effective whether or not an 109 IPSec Authentication Header(AH) treats the option data as zero valued 110 octets. Hence we can include this bit in generating option types. 111 The acceptable option types would be laid out like below 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 114 | Option Type | Opt Data Len | Option Data 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 116 |0 0 x x x x x x|...............|................. 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 119 Figure 1: Option type layout 121 Since the option types 0(0x00) and 1(0x01) are reserved for the Pad1 122 and PadN options in [RFC2460] we exclude these from the acceptable 123 range as well. So we choose the option type identifiers for each of 124 these options to be in the range 0x02-0x63. More option types 125 defined by other RFCs can be excluded from the attack as and when 126 they are allocated by the IANA. Examples are Tunnel Encapsulation 127 limit (0x04) and Router Alert (0x05). 129 2.1. Effects of the attack 131 The attack can be used to cripple the routers by attacking the 132 control processor rather than the forwarding plane. Since the 133 control traffic, like the routing protocols, shares the same 134 resources with this traffic, this kind of attack may be hard to 135 control. On routers having separate Control and Forwarding elements 136 only the Control traffic would be affected. For routers whose the 137 Control and Forwarding elements are fused together this would lead to 138 problems with forwarding packets as well. 140 3. Proposed Solutions 142 There are at least three possible solutions to handle the DoS attack 143 mentioned in this draft. The first one is to get rid of the feature 144 altogether and prevent the attacks. The second one is to limit the 145 attacks to nodes that need to process hop-by-hop options. The third 146 is to let the attacks occur, but limit the damage. 148 3.1. Deprecation 150 The first solution is to deprecate hop-by-hop options from the IPv6 151 specification and to stop allocation of any new ones. The existing 152 hop-by-hop options MAY be grandfathered but new ones MUST NOT be 153 allocated. This allows existing protocols depending on hop-by-hop 154 options to continue working, but discourages the development of new 155 solutions based on hop-by-hop options. 157 3.2. Skipping 159 This option allows nodes to skip over the hop-by-hop extension header 160 without processing any of the options contained in the header. If a 161 node receives an IPv6 datagram with a hop-by-hop header, and it does 162 not support any hop-by-hop options at all, it can just skip over the 163 header. 165 3.3. Rate limiting 167 A less severe (and less effective) solution is to simply rate limit 168 packets with hop-by-hop option headers and start dropping them 169 randomly when the CPU load becomes very high. While this solution is 170 very simple and has no impact on deployed IPv6 nodes, it is sub- 171 optimal. A legitimate packet with a hop-by-hop option header has the 172 same probability of being dropped as an attack packet. Implementing 173 the solution proposed in this draft does not preclude the use of rate 174 limiting. In fact it gives a legitimate packet a lower probability 175 of being dropped, since most of the obvious attack traffic would have 176 been dropped by the receiving algorithm. 178 4. Impact on deployed IPv6 nodes 180 The proposed changes can affect all currently IPv6 nodes which need 181 to send and receive packets with hop-by-hop options. If the 182 deprecation option is chosen, the IPv6 stack on both sending and 183 receiving nodes needs to be modified to not send or receive hop-by- 184 hop options. In addition, transit nodes need to be modified as well 185 in order to not inspect these options. 187 5. Security Considerations 189 This document highlights the possible security issues with the IPv6 190 hop-by-hop option header specified in [RFC2460] which can lead to 191 denial of service attacks and suggests some changes to reduce the 192 effect of the DoS attacks. 194 6. IANA Considerations 196 This requests IANA to stop allocation of new entries for IPv6 hop-by- 197 hop option types. 199 7. Normative References 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", RFC 2119, March 1997. 204 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 205 (IPv6) Specification", RFC 2460, December 1998. 207 Author's Address 209 Suresh Krishnan 210 Ericsson 211 8400 Decarie Blvd. 212 Town of Mount Royal, QC 213 Canada 215 Email: suresh.krishnan@ericsson.com 217 Full Copyright Statement 219 Copyright (C) The IETF Trust (2008). 221 This document is subject to the rights, licenses and restrictions 222 contained in BCP 78, and except as set forth therein, the authors 223 retain all their rights. 225 This document and the information contained herein are provided on an 226 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 227 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 228 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 229 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 230 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 231 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 233 Intellectual Property 235 The IETF takes no position regarding the validity or scope of any 236 Intellectual Property Rights or other rights that might be claimed to 237 pertain to the implementation or use of the technology described in 238 this document or the extent to which any license under such rights 239 might or might not be available; nor does it represent that it has 240 made any independent effort to identify any such rights. Information 241 on the procedures with respect to rights in RFC documents can be 242 found in BCP 78 and BCP 79. 244 Copies of IPR disclosures made to the IETF Secretariat and any 245 assurances of licenses to be made available, or the result of an 246 attempt made to obtain a general license or permission for the use of 247 such proprietary rights by implementers or users of this 248 specification can be obtained from the IETF on-line IPR repository at 249 http://www.ietf.org/ipr. 251 The IETF invites any interested party to bring to its attention any 252 copyrights, patents or patent applications, or other proprietary 253 rights that may cover technology that may be required to implement 254 this standard. Please address the information to the IETF at 255 ietf-ipr@ietf.org. 257 Acknowledgment 259 Funding for the RFC Editor function is provided by the IETF 260 Administrative Support Activity (IASA).