IPv6 WG P. Savola Internet-Draft CSC/FUNET Intended status: Standards Track G. Neville-Neil Expires: November 9, 2007 Neville-Neil Consulting May 8, 2007 IPv6 Type 0 Routing Header Processing draft-savola-ipv6-rtheader-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 9, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract IPv6 type 0 routing header has been demonstrated to be a very powerful mechanism as currently specified in RFC 2460. This memo refers to description of problems associated with the use of type 0 routing header and specifies that implementations should disable type 0 routing header processing by default. Savola & Neville-Neil Expires November 9, 2007 [Page 1] Internet-Draft IPv6 Type 0 Routing Header Processing May 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Routing Header and Source Routing Specification . . . . . . . . 3 2.1. IPv6 Routing Header Specification . . . . . . . . . . . . . 4 2.2. IPv4 Source Routing Specification . . . . . . . . . . . . . 4 3. Updated Specification . . . . . . . . . . . . . . . . . . . . . 5 3.1. IPv6 Specification . . . . . . . . . . . . . . . . . . . . 5 3.2. IPv4 Specification . . . . . . . . . . . . . . . . . . . . 5 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Details . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. High-level . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Savola & Neville-Neil Expires November 9, 2007 [Page 2] Internet-Draft IPv6 Type 0 Routing Header Processing May 2007 1. Introduction The IPv6 core specification [RFC2460] introduces a generic routing header mechanism and also describes a specific type of routing header (type 0) that IPv6-compliant stacks must implement. This specific extension allows the sender of the packet to bypass the natural routing by controlling the packet's path through the network. RFC 2460 requires that all nodes (including hosts) process type 0 routing headers. Further, the specification does not impose very many constraints on its use; for example, the number of waypoints and the number of routing headers in a packet are not restricted. Potential problems with the routing header extension identified in 2001 [I-D.savola-ipv6-rh-ha-security]. In 2002, a proposal was made to restrict routing header processing in hosts [I-D.savola-ipv6-rh-hosts]. These efforts didn't gain sufficient momentum to change IPv6 specifications, but resulted in the Mobile IPv6 specification being redesigned to use a more restricted version, type 2 routing header [RFC3775]. The routing header issues were later documented in a document giving an overview of IPv6 security considerations [I-D.ietf-v6ops-security-overview]. In April 2007, a CanSecWest presentation brought up the issues again [CANSECW]. The presentation included a detailed description of problems associated with having all nodes process the type 0 extension, gave test results, and described tools which provided a number of ways to exploit routing header for denial-of-service and other attacks. This resulted in a number of people realizing that the routing header part of the IPv6 specification needed to be revisited. This document summarizes the current IPv6 routing header and IPv4 source routing specification and proposes changes to IPv6 type 0 routing header processing specification. On the other hand, type 2 routing header [RFC3775] and generic routing header processing is not changed. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Routing Header and Source Routing Specification This section is not normative. Savola & Neville-Neil Expires November 9, 2007 [Page 3] Internet-Draft IPv6 Type 0 Routing Header Processing May 2007 2.1. IPv6 Routing Header Specification At a higher level, RFC 2460 specifies about routing header as follows: 1. All IPv6 nodes are required to process type 0 routing headers. This includes both hosts and routers. 2. RFC 2460 specifies (in Section 4.1) that "Each extension header should occur at most once, except [...]", yet two paragraphs later, "IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except [...]". As a result, there is no specified limit for the number of routing headers in a single packet. 3. RFC 2460 does not specify a strict limit on the number of addresses in a type 0 routing header. The only limit is implicit and results from the limited packet size. (The predecessor of RFC 2460, [RFC1883], specified the upper limit of 23 addresses in a type 0 routing header.) 4. RFC 2460 (Section 8.4) specifies that when responding to a packet with a routing header, an IPv6 node should respond with a "reversed" routing header only if the integrity and authenticity of the routing header was verified. 5. RFC 2460 Section 4.4 includes type 0 routing header processing algorithm that applies to all nodes. The final step includes decrementing the Hop Limit and "resubmit[ting] the packet to the IPv6 module for transmission to the new destination". This could be interpreted as a replacement for a typical forwarding function, but the algorithm makes no distinction between hosts and routers. As such it is not clear whether routing header processing (whether out on the wire or internal to the node) requires forwarding to be enabled or not. These can be exploited in a number of ways [CANSECW]. 2.2. IPv4 Source Routing Specification In contrast, at a higher level, IPv4 Loose/Strict Source Routing has been specified as follows: 1. Routers MUST implement support for source route option ([RFC1812], Section 5.3.13.4), MAY have a toggle to discard, but MUST default to [enable processing]. Hosts MAY perform source- route forwarding as long as they honor generic forwarding specifications ([RFC1122], Section 3.3.5); "local" (out over the Savola & Neville-Neil Expires November 9, 2007 [Page 4] Internet-Draft IPv6 Type 0 Routing Header Processing May 2007 same interface as in) is not restricted but "non-local" MUST have a toggle, and MUST default to disabled. 2. A host MUST not insert more than one source route option, but behavior on receipt is specified as unspecified. 3. IP Header length restrictions in [RFC0791] limit the number of addresses to 9. 4. Hosts MUST reverse the routing header when they're a final recipient ([RFC1122], Section 3.2.1.c). As required, most deployed IPv4 router implementations allow source routing by default, but most network operators have used the toggle to disable source route processing on most routers. IPv4 source route processing behaviour on hosts vary significantly. 3. Updated Specification 3.1. IPv6 Specification Both IPv6 hosts and routers MUST disable type 0 routing header processing by default. Routers SHOULD have toggle to enable type 0 routing header processing. If routing header type processing is disabled or not implemented, the implementation MUST respond as specified in RFC 2460 Section 4.4. 3.2. IPv4 Specification IPv4 specification is not changed in this memo. 4. Open Issues 4.1. Details o Does the RFC 2460 requirement that hosts must also "process routing header" also imply "forwarding"? Consider that the algorithm applies to both hosts and routers, there is no mention of forwarding, and the algorithm decrements Hop Limit even for "internal" next-hops (implying that it supplants the regular forwarding procedure.) o Should we change IPv4 specification, e.g., also Update RFC 1812 and 1122? E.g., to disable by default on routers, disable routing Savola & Neville-Neil Expires November 9, 2007 [Page 5] Internet-Draft IPv6 Type 0 Routing Header Processing May 2007 header reversing by default? Suggestion has been to do this in a separate draft. o Is the current RFC 2460 specification about routing header types (practically ICMP parameter problem generated) appropriate? Would it be OK for an implemented but disabled routing header type processing node to do silent discard? o Is a SHOULD on routers to have a type 0 routing header processing toggle reasonable? Should this be stronger or weaker? 4.2. High-level If the intent of the draft is to disable by default, would we need to provide a more constrained specification for type 0? (Currently, the draft does not; see Security Considerations.) The main approaches to disabling or deprecating type 0 routing headers seem to be as follows (this draft doing the first): o Disable type 0 by default. Generic routing header processing and type 0 in particular is still a mandatory part of IPv6 specifications. o Disable type 0 by default. Make type 0 routing header processing an OPTIONAL part of IPv6 specifications. o Remove type 0 processing. More strongly suggest that it should not be supported (e.g., SHOULD NOT or MUST NOT). Further, if type 0 routing header processing would be OPTIONAL or completely deprecated, one could also consider if the generic routing header processing should be revisited. If type 0 routing header were deprecated, one could also consider whether the host should -- instead of ignoring type 0 routing header and proceed to the next header as specified in RFC 2460 -- just simply drop the packet. 5. Acknowledgments Many people participated in discussions relating to this on IPv6 and v6ops WG mailing lists since April 2007. Special thanks go to Jari Arkko, Arnaud Ebalard, Itojun Hagino, David Malone, and Dave Thaler. Savola & Neville-Neil Expires November 9, 2007 [Page 6] Internet-Draft IPv6 Type 0 Routing Header Processing May 2007 6. Security Considerations This memo includes references to the threats on the use of routing headers, and specifies that IPv6 type 0 routing header processing should be disabled by default. However, this document does not provide "tighter" specification for type 0 routing header, e.g., the number of addresses or the number of routing headers. It is expected that the people who enable routing header processing will appropriately restrict its use to trusted parties (e.g., using IPsec or IP access lists). 7. IANA Considerations This document requires no action from IANA. 8. References 8.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 8.2. Informative References [CANSECW] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security. CanSecWest 2007 presentation", April 2007, . [I-D.ietf-v6ops-security-overview] Davies, E., "IPv6 Transition/Co-existence Security Considerations", draft-ietf-v6ops-security-overview-06 (work in progress), October 2006. Savola & Neville-Neil Expires November 9, 2007 [Page 7] Internet-Draft IPv6 Type 0 Routing Header Processing May 2007 [I-D.savola-ipv6-rh-ha-security] Savola, P., "Security of IPv6 Routing Header and Home Address Options", draft-savola-ipv6-rh-ha-security-02 (work in progress), March 2002. [I-D.savola-ipv6-rh-hosts] Savola, P., "Note about Routing Header Processing on IPv6 Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress), February 2002. [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Authors' Addresses Pekka Savola CSC/FUNET Espoo Finland Email: psavola@funet.fi George Neville-Neil Neville-Neil Consulting 2261 Market St. #239 San Francisco, CA 94114 USA Email: gnn@neville-neil.com Savola & Neville-Neil Expires November 9, 2007 [Page 8] Internet-Draft IPv6 Type 0 Routing Header Processing May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Savola & Neville-Neil Expires November 9, 2007 [Page 9]