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,
<http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
[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]