idnits 2.17.1 draft-savola-ipv6-rtheader-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 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 374. 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 lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 2. A host MUST not insert more than one source route option, but behavior on receipt is specified as unspecified. -- 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 8, 2007) is 6197 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 1883 (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 WG P. Savola 3 Internet-Draft CSC/FUNET 4 Intended status: Standards Track G. Neville-Neil 5 Expires: November 9, 2007 Neville-Neil Consulting 6 May 8, 2007 8 IPv6 Type 0 Routing Header Processing 9 draft-savola-ipv6-rtheader-00.txt 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 9, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 IPv6 type 0 routing header has been demonstrated to be a very 43 powerful mechanism as currently specified in RFC 2460. This memo 44 refers to description of problems associated with the use of type 0 45 routing header and specifies that implementations should disable type 46 0 routing header processing by default. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Routing Header and Source Routing Specification . . . . . . . . 3 53 2.1. IPv6 Routing Header Specification . . . . . . . . . . . . . 4 54 2.2. IPv4 Source Routing Specification . . . . . . . . . . . . . 4 55 3. Updated Specification . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. IPv6 Specification . . . . . . . . . . . . . . . . . . . . 5 57 3.2. IPv4 Specification . . . . . . . . . . . . . . . . . . . . 5 58 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Details . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. High-level . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . . . . 9 70 1. Introduction 72 The IPv6 core specification [RFC2460] introduces a generic routing 73 header mechanism and also describes a specific type of routing header 74 (type 0) that IPv6-compliant stacks must implement. This specific 75 extension allows the sender of the packet to bypass the natural 76 routing by controlling the packet's path through the network. 78 RFC 2460 requires that all nodes (including hosts) process type 0 79 routing headers. Further, the specification does not impose very 80 many constraints on its use; for example, the number of waypoints and 81 the number of routing headers in a packet are not restricted. 83 Potential problems with the routing header extension identified in 84 2001 [I-D.savola-ipv6-rh-ha-security]. In 2002, a proposal was made 85 to restrict routing header processing in hosts 86 [I-D.savola-ipv6-rh-hosts]. These efforts didn't gain sufficient 87 momentum to change IPv6 specifications, but resulted in the Mobile 88 IPv6 specification being redesigned to use a more restricted version, 89 type 2 routing header [RFC3775]. The routing header issues were 90 later documented in a document giving an overview of IPv6 security 91 considerations [I-D.ietf-v6ops-security-overview]. 93 In April 2007, a CanSecWest presentation brought up the issues again 94 [CANSECW]. The presentation included a detailed description of 95 problems associated with having all nodes process the type 0 96 extension, gave test results, and described tools which provided a 97 number of ways to exploit routing header for denial-of-service and 98 other attacks. This resulted in a number of people realizing that 99 the routing header part of the IPv6 specification needed to be 100 revisited. 102 This document summarizes the current IPv6 routing header and IPv4 103 source routing specification and proposes changes to IPv6 type 0 104 routing header processing specification. On the other hand, type 2 105 routing header [RFC3775] and generic routing header processing is not 106 changed. 108 1.1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Routing Header and Source Routing Specification 116 This section is not normative. 118 2.1. IPv6 Routing Header Specification 120 At a higher level, RFC 2460 specifies about routing header as 121 follows: 123 1. All IPv6 nodes are required to process type 0 routing headers. 124 This includes both hosts and routers. 126 2. RFC 2460 specifies (in Section 4.1) that "Each extension header 127 should occur at most once, except [...]", yet two paragraphs 128 later, "IPv6 nodes must accept and attempt to process extension 129 headers in any order and occurring any number of times in the 130 same packet, except [...]". As a result, there is no specified 131 limit for the number of routing headers in a single packet. 133 3. RFC 2460 does not specify a strict limit on the number of 134 addresses in a type 0 routing header. The only limit is implicit 135 and results from the limited packet size. (The predecessor of 136 RFC 2460, [RFC1883], specified the upper limit of 23 addresses in 137 a type 0 routing header.) 139 4. RFC 2460 (Section 8.4) specifies that when responding to a packet 140 with a routing header, an IPv6 node should respond with a 141 "reversed" routing header only if the integrity and authenticity 142 of the routing header was verified. 144 5. RFC 2460 Section 4.4 includes type 0 routing header processing 145 algorithm that applies to all nodes. The final step includes 146 decrementing the Hop Limit and "resubmit[ting] the packet to the 147 IPv6 module for transmission to the new destination". This could 148 be interpreted as a replacement for a typical forwarding 149 function, but the algorithm makes no distinction between hosts 150 and routers. As such it is not clear whether routing header 151 processing (whether out on the wire or internal to the node) 152 requires forwarding to be enabled or not. 154 These can be exploited in a number of ways [CANSECW]. 156 2.2. IPv4 Source Routing Specification 158 In contrast, at a higher level, IPv4 Loose/Strict Source Routing has 159 been specified as follows: 161 1. Routers MUST implement support for source route option 162 ([RFC1812], Section 5.3.13.4), MAY have a toggle to discard, but 163 MUST default to [enable processing]. Hosts MAY perform source- 164 route forwarding as long as they honor generic forwarding 165 specifications ([RFC1122], Section 3.3.5); "local" (out over the 166 same interface as in) is not restricted but "non-local" MUST have 167 a toggle, and MUST default to disabled. 169 2. A host MUST not insert more than one source route option, but 170 behavior on receipt is specified as unspecified. 172 3. IP Header length restrictions in [RFC0791] limit the number of 173 addresses to 9. 175 4. Hosts MUST reverse the routing header when they're a final 176 recipient ([RFC1122], Section 3.2.1.c). 178 As required, most deployed IPv4 router implementations allow source 179 routing by default, but most network operators have used the toggle 180 to disable source route processing on most routers. 182 IPv4 source route processing behaviour on hosts vary significantly. 184 3. Updated Specification 186 3.1. IPv6 Specification 188 Both IPv6 hosts and routers MUST disable type 0 routing header 189 processing by default. Routers SHOULD have toggle to enable type 0 190 routing header processing. 192 If routing header type processing is disabled or not implemented, the 193 implementation MUST respond as specified in RFC 2460 Section 4.4. 195 3.2. IPv4 Specification 197 IPv4 specification is not changed in this memo. 199 4. Open Issues 201 4.1. Details 203 o Does the RFC 2460 requirement that hosts must also "process 204 routing header" also imply "forwarding"? Consider that the 205 algorithm applies to both hosts and routers, there is no mention 206 of forwarding, and the algorithm decrements Hop Limit even for 207 "internal" next-hops (implying that it supplants the regular 208 forwarding procedure.) 210 o Should we change IPv4 specification, e.g., also Update RFC 1812 211 and 1122? E.g., to disable by default on routers, disable routing 212 header reversing by default? Suggestion has been to do this in a 213 separate draft. 215 o Is the current RFC 2460 specification about routing header types 216 (practically ICMP parameter problem generated) appropriate? Would 217 it be OK for an implemented but disabled routing header type 218 processing node to do silent discard? 220 o Is a SHOULD on routers to have a type 0 routing header processing 221 toggle reasonable? Should this be stronger or weaker? 223 4.2. High-level 225 If the intent of the draft is to disable by default, would we need to 226 provide a more constrained specification for type 0? (Currently, the 227 draft does not; see Security Considerations.) 229 The main approaches to disabling or deprecating type 0 routing 230 headers seem to be as follows (this draft doing the first): 232 o Disable type 0 by default. Generic routing header processing and 233 type 0 in particular is still a mandatory part of IPv6 234 specifications. 236 o Disable type 0 by default. Make type 0 routing header processing 237 an OPTIONAL part of IPv6 specifications. 239 o Remove type 0 processing. More strongly suggest that it should 240 not be supported (e.g., SHOULD NOT or MUST NOT). 242 Further, if type 0 routing header processing would be OPTIONAL or 243 completely deprecated, one could also consider if the generic routing 244 header processing should be revisited. 246 If type 0 routing header were deprecated, one could also consider 247 whether the host should -- instead of ignoring type 0 routing header 248 and proceed to the next header as specified in RFC 2460 -- just 249 simply drop the packet. 251 5. Acknowledgments 253 Many people participated in discussions relating to this on IPv6 and 254 v6ops WG mailing lists since April 2007. Special thanks go to Jari 255 Arkko, Arnaud Ebalard, Itojun Hagino, David Malone, and Dave Thaler. 257 6. Security Considerations 259 This memo includes references to the threats on the use of routing 260 headers, and specifies that IPv6 type 0 routing header processing 261 should be disabled by default. 263 However, this document does not provide "tighter" specification for 264 type 0 routing header, e.g., the number of addresses or the number of 265 routing headers. It is expected that the people who enable routing 266 header processing will appropriately restrict its use to trusted 267 parties (e.g., using IPsec or IP access lists). 269 7. IANA Considerations 271 This document requires no action from IANA. 273 8. References 275 8.1. Normative References 277 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 278 September 1981. 280 [RFC1122] Braden, R., "Requirements for Internet Hosts - 281 Communication Layers", STD 3, RFC 1122, October 1989. 283 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 284 RFC 1812, June 1995. 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 290 (IPv6) Specification", RFC 2460, December 1998. 292 8.2. Informative References 294 [CANSECW] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security. 295 CanSecWest 2007 presentation", April 2007, 296 . 298 [I-D.ietf-v6ops-security-overview] 299 Davies, E., "IPv6 Transition/Co-existence Security 300 Considerations", draft-ietf-v6ops-security-overview-06 301 (work in progress), October 2006. 303 [I-D.savola-ipv6-rh-ha-security] 304 Savola, P., "Security of IPv6 Routing Header and Home 305 Address Options", draft-savola-ipv6-rh-ha-security-02 306 (work in progress), March 2002. 308 [I-D.savola-ipv6-rh-hosts] 309 Savola, P., "Note about Routing Header Processing on IPv6 310 Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress), 311 February 2002. 313 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 314 (IPv6) Specification", RFC 1883, December 1995. 316 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 317 in IPv6", RFC 3775, June 2004. 319 Authors' Addresses 321 Pekka Savola 322 CSC/FUNET 323 Espoo 324 Finland 326 Email: psavola@funet.fi 328 George Neville-Neil 329 Neville-Neil Consulting 330 2261 Market St. #239 331 San Francisco, CA 94114 332 USA 334 Email: gnn@neville-neil.com 336 Full Copyright Statement 338 Copyright (C) The IETF Trust (2007). 340 This document is subject to the rights, licenses and restrictions 341 contained in BCP 78, and except as set forth therein, the authors 342 retain all their rights. 344 This document and the information contained herein are provided on an 345 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 346 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 347 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 348 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 349 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 350 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 352 Intellectual Property 354 The IETF takes no position regarding the validity or scope of any 355 Intellectual Property Rights or other rights that might be claimed to 356 pertain to the implementation or use of the technology described in 357 this document or the extent to which any license under such rights 358 might or might not be available; nor does it represent that it has 359 made any independent effort to identify any such rights. Information 360 on the procedures with respect to rights in RFC documents can be 361 found in BCP 78 and BCP 79. 363 Copies of IPR disclosures made to the IETF Secretariat and any 364 assurances of licenses to be made available, or the result of an 365 attempt made to obtain a general license or permission for the use of 366 such proprietary rights by implementers or users of this 367 specification can be obtained from the IETF on-line IPR repository at 368 http://www.ietf.org/ipr. 370 The IETF invites any interested party to bring to its attention any 371 copyrights, patents or patent applications, or other proprietary 372 rights that may cover technology that may be required to implement 373 this standard. Please address the information to the IETF at 374 ietf-ipr@ietf.org. 376 Acknowledgment 378 Funding for the RFC Editor function is provided by the IETF 379 Administrative Support Activity (IASA).