[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/