idnits 2.17.1 draft-jabley-ipv6-rh0-is-evil-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 167. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 178. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 191. 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. 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 6, 2007) is 6200 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 (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley, Ed. 3 Internet-Draft Afilias 4 Updates: 2460 (if approved) May 6, 2007 5 Intended status: Standards Track 6 Expires: November 7, 2007 8 Deprecation of Type 0 Routing Headers in IPv6 9 draft-jabley-ipv6-rh0-is-evil-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 7, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The functionality provided by IPv6's Type 0 Routing Header can be 43 exploited in order to perform remote network discovery, to bypass 44 firewalls and to achieve packet amplification for the purposes of 45 generating denial-of-service traffic. This document updates the IPv6 46 specification to deprecate the use of IPv6 Type 0 Routing Headers, in 47 the light of these security concerns. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 57 7. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 9 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 60 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 61 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 11 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 Intellectual Property and Copyright Statements . . . . . . . . . . 13 65 1. Introduction 67 [RFC2460] defines an IPv6 extension header called "Routing Header", 68 identified by a Next Header value of 43 in the immediately preceding 69 header. A particular Routing Header subtype denoted as "Type 0" is 70 also defined. Type 0 Routing Headers are referred to as "RH0" in 71 this document. 73 Use of RH0 has been shown to have unpleasant security implications. 74 This document deprecates the use of RH0. 76 2. Definitions 78 RH0 in this document denotes the IPv6 Extension Header type 43 79 ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in 80 [RFC2460]. 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. Implementation 88 Compliant IPv6 hosts and routers MUST NOT transmit IPv6 datagrams 89 containing RH0. 91 4. Operations 93 Compliant IPv6 hosts and routers which receive IPv6 datagrams 94 containing RH0 MUST silently discard those datagrams without further 95 processing. 97 5. Security Considerations 99 The purpose of this document is to deprecate a feature of IPv6 which 100 has been shown to have serious security implications. 102 Specific examples of vulnerabilities which are facilitated by the 103 availability of RH0 can be found in [BiondiEbalard]. 105 6. IANA Considerations 107 This document requests that IANA update the description of variant 0 108 of IPv6 header-type 43 ("Routing Header") to indicate that the use of 109 RH0 is deprecated. 111 7. Acknowlegements 113 An eloquent and useful description of the operational security 114 implications of RH0 was presented by Philippe Biondi and Arnaud 115 Ebalard at the CanSecWest conference in Vancouver, 2007 116 [BiondiEbalard]. This presentation resulted in widespread publicity 117 for the risks associated with RH0, and that in turn led to much 118 discussion in the IETF. 120 8. References 122 8.1. Normative References 124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 125 Requirement Levels", BCP 14, RFC 2119, March 1997. 127 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 128 (IPv6) Specification", RFC 2460, December 1998. 130 8.2. Informative References 132 [BiondiEbalard] 133 BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security", 134 April 2007. 136 Appendix A. Change History 138 This section to be removed prior to publication. 140 00 Strawman, circulated to provoke discussion. 142 Author's Address 144 Joe Abley (editor) 145 Afilias Canada Corp. 146 Suite 204, 4141 Yonge Street 147 Toronto, ON M2P 2A8 148 Canada 150 Phone: +1 416 673 4176 151 Email: jabley@ca.afilias.info 153 Full Copyright Statement 155 Copyright (C) The IETF Trust (2007). 157 This document is subject to the rights, licenses and restrictions 158 contained in BCP 78, and except as set forth therein, the authors 159 retain all their rights. 161 This document and the information contained herein are provided on an 162 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 163 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 164 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 165 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 166 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 167 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 169 Intellectual Property 171 The IETF takes no position regarding the validity or scope of any 172 Intellectual Property Rights or other rights that might be claimed to 173 pertain to the implementation or use of the technology described in 174 this document or the extent to which any license under such rights 175 might or might not be available; nor does it represent that it has 176 made any independent effort to identify any such rights. Information 177 on the procedures with respect to rights in RFC documents can be 178 found in BCP 78 and BCP 79. 180 Copies of IPR disclosures made to the IETF Secretariat and any 181 assurances of licenses to be made available, or the result of an 182 attempt made to obtain a general license or permission for the use of 183 such proprietary rights by implementers or users of this 184 specification can be obtained from the IETF on-line IPR repository at 185 http://www.ietf.org/ipr. 187 The IETF invites any interested party to bring to its attention any 188 copyrights, patents or patent applications, or other proprietary 189 rights that may cover technology that may be required to implement 190 this standard. Please address the information to the IETF at 191 ietf-ipr@ietf.org. 193 Acknowledgment 195 Funding for the RFC Editor function is provided by the IETF 196 Administrative Support Activity (IASA).