idnits 2.17.1 draft-ietf-ipv6-deprecate-rh0-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2460, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4294, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (June 26, 2007) is 6143 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) ** Obsolete normative reference: RFC 4294 (Obsoleted by RFC 6434) == Outdated reference: A later version (-03) exists of draft-savola-ipv6-rh-ha-security-02 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Afilias 4 Updates: 2460, 4294 P. Savola 5 (if approved) CSC/FUNET 6 Intended status: Standards Track G. Neville-Neil 7 Expires: December 28, 2007 Neville-Neil Consulting 8 June 26, 2007 10 Deprecation of Type 0 Routing Headers in IPv6 11 draft-ietf-ipv6-deprecate-rh0-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 28, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The functionality provided by IPv6's Type 0 Routing Header can be 45 exploited in order to achieve traffic amplification over a remote 46 path for the purposes of generating denial-of-service traffic. This 47 document updates the IPv6 specification to deprecate the use of IPv6 48 Type 0 Routing Headers, in light of this security concern. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . . . 9 68 1. Introduction 70 [RFC2460] defines an IPv6 extension header called "Routing Header", 71 identified by a Next Header value of 43 in the immediately preceding 72 header. A particular Routing Header subtype denoted as "Type 0" is 73 also defined. Type 0 Routing Headers are referred to as "RH0" in 74 this document. 76 A single RH0 may contain multiple intermediate node addresses, and 77 the same address may be included more than once in the same RH0. 78 This allows a packet to be constructed such that it will oscillate 79 between two RH0-processing hosts or routers many times. This allows 80 a stream of packets from an attacker to be amplified along the path 81 between two remote routers, which could be used to cause congestion 82 along arbitrary remote paths and hence act as a denial-of-service 83 mechanism. 88-fold amplification has been demonstrated using this 84 technique [CanSecWest07]. 86 This attack is particularly serious in that it affects the entire 87 path between the two exploited nodes, not only the nodes themselves 88 or their local networks. Analogous functionality may be found in the 89 IPv4 source route option, but the opportunities for abuse are greater 90 with RH0 due to the ability to specify many more intermediate node 91 addresses in each packet. 93 The severity of this threat is considered to be sufficient to warrant 94 deprecation of RH0 entirely. A side-effect is that this also 95 eliminates benign RH0 use-cases; however, such applications may be 96 facilitated by future Routing Header specifications. 98 Potential problems with RH0 were identified in 2001 99 [I-D.savola-ipv6-rh-ha-security]. In 2002 a proposal was made to 100 restrict Routing Header processing in hosts 101 [I-D.savola-ipv6-rh-hosts]. These efforts resulted in the 102 modification of the Mobile IPv6 specification to use the type 2 103 Routing Header instead of RH0 [RFC3775]. Vishwas Manral identified 104 various risks associated with RH0 in 2006 including the amplification 105 attack; several of these vulnerabilities (together with other issues) 106 were later documented in [I-D.ietf-v6ops-security-overview]. 108 A treatment of the operational security implications of RH0 was 109 presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest 110 conference in Vancouver, 2007 [CanSecWest07]. This presentation 111 resulted in widespread publicity for the risks associated with RH0. 113 This document updates [RFC2460] and [RFC4294]. 115 2. Definitions 117 RH0 in this document denotes the IPv6 Extension Header type 43 118 ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in 119 [RFC2460]. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Deprecation of RH0 127 IPv6 nodes MUST NOT process RH0 in packets whose destination address 128 in the IPv6 header is an address assigned to them. Such packets MUST 129 be processed according to the behaviour specified in Section 4.4 of 130 [RFC2460] for a datagram which includes an unrecognised Routing Type 131 value, namely: 133 If Segments Left is zero, the node must ignore the Routing header 134 and proceed to process the next header in the packet, whose type 135 is identified by the Next Header field in the Routing header. 137 If Segments Left is non-zero, the node must discard the packet and 138 send an ICMP Parameter Problem, Code 0, message to the packet's 139 Source Address, pointing to the unrecognised Routing Type. 141 IPv6 implementations are no longer required to implement RH0 in any 142 way. 144 4. Operations 146 4.1. Ingress Filtering 148 It is to be expected that it will take some time before all IPv6 149 nodes are updated to remove support for RH0. Some of the uses of RH0 150 described in [CanSecWest07] can be mitigated using ingress filtering, 151 as recommended in [RFC2827] and [RFC3704]. 153 A site security policy intended to protect against attacks using RH0 154 SHOULD include the implementation of ingress filtering at the site 155 border. 157 4.2. Firewall Policy 159 Blocking all IPv6 packets which carry Routing Headers (rather than 160 specifically blocking type 0, and permitting other types) has very 161 serious implications for the future development of IPv6. If even a 162 small percentage of deployed firewalls block other types of routing 163 headers by default, it will become impossible in practice to extend 164 IPv6 routing headers. For example, Mobile IPv6 [RFC3775] relies upon 165 a type-2 RH; wide-scale, indescriminate blocking of Routing Headers 166 will make Mobile IPv6 undeployable. 168 Firewall policy intended to protect against packets containing RH0 169 MUST NOT simply filter all traffic with a routing header; it must be 170 possible to disable forwarding of type 0 traffic without blocking 171 other types of routing headers. In addition, the default 172 configuration MUST permit forwarding of traffic using a RH other than 173 0. 175 5. Security Considerations 177 The purpose of this document is to deprecate a feature of IPv6 which 178 has been shown to have undesirable security implications. Specific 179 examples of vulnerabilities which are facilitated by the availability 180 of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a 181 mechanism for traffic amplification, which might be used as a denial- 182 of-service attack. A description of this functionality can be found 183 in Section 1. 185 6. IANA Considerations 187 The IANA registry "Internet Protocol Version 6 (IPv6) Parameters" 188 should be updated to reflect that variant 0 of IPv6 header-type 43 189 ("Routing Header") is deprecated. 191 7. Acknowlegements 193 This document benefits from the contributions of many IPV6 and V6OPS 194 working group participants, including Jari Arkko, Arnaud Ebalard, Tim 195 Enos, Brian Haberman, Jun-ichiro itojun HAGINO, Bob Hinden, Thomas 196 Narten, JINMEI Tatuya, David Malone, Jeroen Massar, Dave Thaler and 197 Guillaume Valadon. 199 8. References 201 8.1. Normative References 203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, March 1997. 206 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 207 (IPv6) Specification", RFC 2460, December 1998. 209 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 210 April 2006. 212 8.2. Informative References 214 [CanSecWest07] 215 BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security", 216 CanSecWest Security Conference 2007, April 2007. 218 http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf 220 [I-D.ietf-v6ops-security-overview] 221 Davies, E., "IPv6 Transition/Co-existence Security 222 Considerations", draft-ietf-v6ops-security-overview-06 223 (work in progress), October 2006. 225 [I-D.savola-ipv6-rh-ha-security] 226 Savola, P., "Security of IPv6 Routing Header and Home 227 Address Options", draft-savola-ipv6-rh-ha-security-02 228 (work in progress), March 2002. 230 [I-D.savola-ipv6-rh-hosts] 231 Savola, P., "Note about Routing Header Processing on IPv6 232 Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress), 233 February 2002. 235 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 236 Defeating Denial of Service Attacks which employ IP Source 237 Address Spoofing", BCP 38, RFC 2827, May 2000. 239 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 240 Networks", BCP 84, RFC 3704, March 2004. 242 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 243 in IPv6", RFC 3775, June 2004. 245 Appendix A. Change History 247 This section to be removed prior to publication. 249 00 Strawman, draft-jabley-ipv6-rh0-is-evil, circulated to provoke 250 discussion. 252 01 Clarified Section 3; presented more options in Section 4; added 253 Pekka and George as authors. This document version was not widely 254 circulated. 256 00 Renamed, draft-ietf-ipv6-deprecate-rh0, a candidate working group 257 document. 259 01-candidate-00 Incorporated text summarising some of the unwelcome 260 uses of RH0; added some clariying text describing deprecation; 261 modified some ambiguous text in Section 4.2; added "Updates: 262 4294". 264 01-candidate-01 Incorporated contributions from working group: 265 substantially reduced Section 5; clarified wording in Section 3. 267 01-candidate-02 Moved description of traffic amplification to 268 Section 1, and inserted a corresponding cross-reference in 269 Section 5. Strengthened the language in Section 4.2 along the 270 lines suggested by Thomas Narten. Small typos corrected. Added a 271 further sentence in Section 4.1 intended to act as further 272 encouragement for operators to implement [RFC3704]. 274 01 Minor wordsmithing; removed some subjective language; adopted 275 "intermediate node" nomenclature instead of "waypoint"; shifted 276 some history from Section 7 to Section 1. 278 Authors' Addresses 280 Joe Abley 281 Afilias Canada Corp. 282 Suite 204, 4141 Yonge Street 283 Toronto, ON M2P 2A8 284 Canada 286 Phone: +1 416 673 4176 287 Email: jabley@ca.afilias.info 288 Pekka Savola 289 CSC/FUNET 290 Espoo, 291 Finland 293 Email: psavola@funet.fi 295 George Neville-Neil 296 Neville-Neil Consulting 297 2261 Market St. #239 298 San Francisco, CA 94114 299 USA 301 Email: gnn@neville-neil.com 303 Full Copyright Statement 305 Copyright (C) The IETF Trust (2007). 307 This document is subject to the rights, licenses and restrictions 308 contained in BCP 78, and except as set forth therein, the authors 309 retain all their rights. 311 This document and the information contained herein are provided on an 312 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 313 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 314 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 315 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 316 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 317 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 319 Intellectual Property 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org. 343 Acknowledgment 345 Funding for the RFC Editor function is provided by the IETF 346 Administrative Support Activity (IASA).