idnits 2.17.1 draft-ietf-ipv6-deprecate-rh0-00.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 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 293. 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 (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 (May 16, 2007) is 6183 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) == 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 (if approved) P. Savola 5 Intended status: Standards Track CSC/FUNET 6 Expires: November 17, 2007 G. Neville-Neil 7 Neville-Neil Consulting 8 May 16, 2007 10 Deprecation of Type 0 Routing Headers in IPv6 11 draft-ietf-ipv6-deprecate-rh0-00 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 November 17, 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 perform remote network discovery, to bypass 46 firewalls and to achieve packet amplification for the purposes of 47 generating denial-of-service traffic. This document updates the IPv6 48 specification to deprecate the use of IPv6 Type 0 Routing Headers, in 49 the light of these security concerns. 51 This document updates RFC 2460. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Origination . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Processing . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 3 62 4.2. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 4 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 65 7. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . . 4 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 69 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Intellectual Property and Copyright Statements . . . . . . . . . . 7 73 1. Introduction 75 [RFC2460] defines an IPv6 extension header called "Routing Header", 76 identified by a Next Header value of 43 in the immediately preceding 77 header. A particular Routing Header subtype denoted as "Type 0" is 78 also defined. Type 0 Routing Headers are referred to as "RH0" in 79 this document. 81 Use of RH0 has been shown to have unpleasant security implications, 82 some of which are summarised in Section 5. This document deprecates 83 the use of RH0. 85 This document updates [RFC2460]. 87 2. Definitions 89 RH0 in this document denotes the IPv6 Extension Header type 43 90 ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in 91 [RFC2460]. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Deprecation of RH0 99 3.1. Origination 101 IPv6 nodes MUST NOT originate IPv6 packets containing RH0. 103 3.2. Processing 105 IPv6 nodes MUST NOT process RH0 in packets addressed to them. Such 106 packets MUST be processed according to the behaviour specified in 107 Section 4.4 of [RFC2460] for a datagram which includes an 108 unrecognised Routing Type value. 110 4. Operations 112 4.1. Ingress Filtering 114 It is to be expected that it will take some time before all IPv6 115 nodes are updated to remove support for RH0. Some of the uses of RH0 116 described in [CanSecWest07] can be mitigated using ingress filtering, 117 as recommended in [RFC2827] and [RFC3704]. 119 4.2. Packet Filtering 121 Firewall policy intended to protect against packets containing RH0 122 should be constructed such that routing headers of other types (which 123 may well have legitimate and benign applications) are handled on 124 their own merits. For example, discarding all packets with any type 125 of routing header simply as a reaction to the problems with RH0 is 126 inappropriate, and may hamper future functionality designed using 127 non-type 0 routing headers. For example, Mobile IPv6 uses the type 2 128 Routing Header [RFC3775]. 130 Where filtering capabilities do not facilitate matching specific 131 types of Routing Headers, filtering based on the presence of any 132 Routing Headers on IPv6 routers, regardless of type, is strongly 133 discouraged. 135 5. Security Considerations 137 The purpose of this document is to deprecate a feature of IPv6 which 138 has been shown to have serious security implications. 140 Specific examples of vulnerabilities which are facilitated by the 141 availability of RH0 can be found in [CanSecWest07]. 143 6. IANA Considerations 145 The IANA registry "Internet Protocol Version 6 (IPv6) Parameters" 146 should be updated to reflect that variant 0 of IPv6 header-type 43 147 ("Routing Header") is deprecated. 149 7. Acknowlegements 151 Potential problems with Routing Headers were identified in 2001 152 [I-D.savola-ipv6-rh-ha-security]. In 2002 a proposal was made to 153 restrict Routing Header processing in hosts 154 [I-D.savola-ipv6-rh-hosts]. These efforts did not gain sufficient 155 momentum to change the IPv6 specification, but resulted in the 156 modification of the Mobile IPv6 specification to use the type 2 157 Routing Header instead of RH0 [RFC3775]. Routing Header issues were 158 later documented in [I-D.ietf-v6ops-security-overview]. 160 An eloquent and useful description of the operational security 161 implications of RH0 was presented by Philippe Biondi and Arnaud 162 Ebalard at the CanSecWest conference in Vancouver, 2007 163 [CanSecWest07]. This presentation resulted in widespread publicity 164 for the risks associated with RH0. 166 This document also benefits from the contributions of IPv6 and V6OPS 167 orking group participants, including Jari Arkko, Arbaud Ebalard, Tim 168 Enos, Brian Haberman, Jun-ichiro itojun HAGINO, Bob Hinden, JINMEI 169 Tatuya, David Malone, Jeroen Massar, Dave Thaler and Guillaume 170 Valadon. 172 8. References 174 8.1. Normative References 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 180 (IPv6) Specification", RFC 2460, December 1998. 182 8.2. Informative References 184 [CanSecWest07] 185 BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security", 186 April 2007. 188 http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf 190 [I-D.ietf-v6ops-security-overview] 191 Davies, E., "IPv6 Transition/Co-existence Security 192 Considerations", draft-ietf-v6ops-security-overview-06 193 (work in progress), October 2006. 195 [I-D.savola-ipv6-rh-ha-security] 196 Savola, P., "Security of IPv6 Routing Header and Home 197 Address Options", draft-savola-ipv6-rh-ha-security-02 198 (work in progress), March 2002. 200 [I-D.savola-ipv6-rh-hosts] 201 Savola, P., "Note about Routing Header Processing on IPv6 202 Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress), 203 February 2002. 205 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 206 Defeating Denial of Service Attacks which employ IP Source 207 Address Spoofing", BCP 38, RFC 2827, May 2000. 209 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 210 Networks", BCP 84, RFC 3704, March 2004. 212 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 213 in IPv6", RFC 3775, June 2004. 215 Appendix A. Change History 217 This section to be removed prior to publication. 219 00 Strawman, draft-jabley-ipv6-rh0-is-evil, circulated to provoke 220 discussion. 222 01 Clarified Section 3; presented more options in Section 4; added 223 Pekka and George as authors. This document version was not widely 224 circulated. 226 00 Renamed, draft-ietf-ipv6-deprecate-rh0, a candidate working group 227 document. 229 Authors' Addresses 231 Joe Abley 232 Afilias Canada Corp. 233 Suite 204, 4141 Yonge Street 234 Toronto, ON M2P 2A8 235 Canada 237 Phone: +1 416 673 4176 238 Email: jabley@ca.afilias.info 240 Pekka Savola 241 CSC/FUNET 242 Espoo, 243 Finland 245 Email: psavola@funet.fi 247 George Neville-Neil 248 Neville-Neil Consulting 249 2261 Market St. #239 250 San Francisco, CA 94114 251 USA 253 Email: gnn@neville-neil.com 255 Full Copyright Statement 257 Copyright (C) The IETF Trust (2007). 259 This document is subject to the rights, licenses and restrictions 260 contained in BCP 78, and except as set forth therein, the authors 261 retain all their rights. 263 This document and the information contained herein are provided on an 264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 266 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 267 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 268 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 271 Intellectual Property 273 The IETF takes no position regarding the validity or scope of any 274 Intellectual Property Rights or other rights that might be claimed to 275 pertain to the implementation or use of the technology described in 276 this document or the extent to which any license under such rights 277 might or might not be available; nor does it represent that it has 278 made any independent effort to identify any such rights. Information 279 on the procedures with respect to rights in RFC documents can be 280 found in BCP 78 and BCP 79. 282 Copies of IPR disclosures made to the IETF Secretariat and any 283 assurances of licenses to be made available, or the result of an 284 attempt made to obtain a general license or permission for the use of 285 such proprietary rights by implementers or users of this 286 specification can be obtained from the IETF on-line IPR repository at 287 http://www.ietf.org/ipr. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary 291 rights that may cover technology that may be required to implement 292 this standard. Please address the information to the IETF at 293 ietf-ipr@ietf.org. 295 Acknowledgment 297 Funding for the RFC Editor function is provided by the IETF 298 Administrative Support Activity (IASA).