<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc2460 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
  <!ENTITY rfc2827 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml'>
  <!ENTITY rfc3704 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3704.xml'>
  <!ENTITY rfc3775 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
  <!ENTITY rfc4294 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4294.xml'>
  <!ENTITY draft-savola-ipv6-rh-ha-security PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.savola-ipv6-rh-ha-security.xml'>
  <!ENTITY draft-savola-ipv6-rh-hosts PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.savola-ipv6-rh-hosts.xml'>
  <!ENTITY rfc4942 PUBLIC ''
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4942.xml'>
]>

<rfc number="5095" category="std" updates="2460, 4294">


<?rfc rfcedstyle="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc subcompact="no" ?>

  <front>
    <title abbrev="Deprecation of RH0">Deprecation of Type 0 Routing
      Headers in IPv6</title>

    <author initials='J.' surname="Abley" fullname='Joe Abley'>
      <organization abbrev="Afilias">Afilias Canada Corp.</organization>
      <address>
        <postal>
          <street>Suite 204, 4141 Yonge Street</street>
          <city>Toronto</city>
          <region>ON</region>
          <code>M2P 2A8</code>
          <country>Canada</country>
        </postal>
        <phone>+1 416 673 4176</phone>
        <email>jabley@ca.afilias.info</email>
      </address>
    </author>

    <author initials='P.' surname="Savola" fullname='Pekka Savola'>
      <organization>CSC/FUNET</organization>
      <address>
        <postal>
          <street/>
          <city>Espoo</city>
          <region/>
          <country>Finland</country>
        </postal>
        <email>psavola@funet.fi</email>
      </address>
    </author>

    <author initials='G.' surname="Neville-Neil" fullname='George Neville-Neil'>
      <organization>Neville-Neil Consulting</organization>
      <address>
        <postal>
          <street>2261 Market St. #239</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94114</code>
          <country>USA</country>
        </postal>
        <email>gnn@neville-neil.com</email>
      </address>
    </author>


    <date month="November" year="2007"/>

    <abstract>
      <t>The functionality provided by IPv6's Type 0 Routing Header can be
	exploited in order to achieve traffic amplification over a
	remote path for the purposes of generating denial-of-service
	traffic.  This document updates the IPv6 specification to
	deprecate the use of IPv6 Type 0 Routing Headers, in
	light of this security concern.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" anchor="introduction">
      <t><xref target="RFC2460"/> defines an IPv6 extension header
        called "Routing Header", identified by a Next Header value
        of 43 in the immediately preceding header. A particular
        Routing Header subtype denoted as "Type 0" is also defined.
        Type 0 Routing Headers are referred to as "RH0" in this
        document.</t>

      <t>A single RH0 may contain multiple intermediate node
	addresses, and the same address may be included more than
	once in the same RH0.  This allows a packet to be constructed
	such that it will oscillate between two RH0-processing hosts
	or routers many times. This allows a stream of packets from
	an attacker to be amplified along the path between two
	remote routers, which could be used to cause congestion
	along arbitrary remote paths and hence act as a denial-of-service
	mechanism.  An 88-fold amplification has been demonstrated
	using this technique <xref target="CanSecWest07"/>.</t>

      <t>This attack is particularly serious in that it affects the
	entire path between the two exploited nodes, not only the
	nodes themselves or their local networks. Analogous
	functionality may be found in the IPv4 source route option,
	but the opportunities for abuse are greater with RH0 due
	to the ability to specify many more intermediate node
	addresses in each packet.</t>

      <t>The severity of this threat is considered to be sufficient
	to warrant deprecation of RH0 entirely. A side effect is
	that this also eliminates benign RH0 use-cases; however,
	such applications may be facilitated by future Routing
	Header specifications.</t>

      <t>Potential problems with RH0 were identified in 2001 <xref
	target="Security"/>. In 2002 a proposal
	was made to restrict Routing Header processing in hosts
	<xref target="Hosts"/>. These efforts
	resulted in the modification of the
	Mobile IPv6 specification to use the type 2 Routing Header
	instead of RH0 <xref target="RFC3775"/>. Vishwas Manral
	identified various risks associated with RH0 in 2006 including
	the amplification attack; several of these vulnerabilities
	(together with other issues) were later documented in <xref
	target="RFC4942"/>.</t>

      <t>A treatment of the operational security implications of
	RH0 was presented by Philippe Biondi and Arnaud Ebalard at
	the CanSecWest conference in Vancouver, 2007 <xref
	target="CanSecWest07"/>. This presentation resulted in
	widespread publicity for the risks associated with RH0.</t>

      <t>This document updates <xref target="RFC2460"/> and
        <xref target="RFC4294"/>.</t>
    </section>

    <section title="Definitions">
      <t>RH0 in this document denotes the IPv6 Extension Header
        type 43 ("Routing Header") variant 0 ("Type 0 Routing Header"),
        as defined in <xref target="RFC2460"/>.</t>

      <t>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
        <xref target="RFC2119"/>.</t>
    </section>

    <section title="Deprecation of RH0" anchor="implementation">
      <t>An IPv6 node that receives a packet with a destination
      address assigned to it and that contains an RH0 extension header
      MUST NOT execute the algorithm specified in the latter part of
      Section 4.4 of <xref target="RFC2460"/> for RH0.  Instead, such packets MUST be
      processed according to the behaviour specified in Section 4.4 of
      <xref target="RFC2460"/> for a datagram that includes an
      unrecognised Routing Type value, namely:

      <list style="empty">
        <t>If Segments Left is zero, the node must ignore the
          Routing header and proceed to process the next header
          in the packet, whose type is identified by the Next
          Header field in the Routing header.</t>

        <t>If Segments Left is non-zero, the node must discard
          the packet and send an ICMP Parameter Problem, Code 0,
          message to the packet's Source Address, pointing to the
          unrecognized Routing Type.</t>
	</list></t>

      <t>IPv6 implementations are no longer required to implement
        RH0 in any way.</t>
    </section>

    <section title="Operations" anchor="operations">
      <section title="Ingress Filtering" anchor="urpf">
        <t>It is to be expected that it will take some time before all
          IPv6 nodes are updated to remove support for RH0.
          Some of the uses of RH0 described in <xref target="CanSecWest07"/>
          can be mitigated using ingress filtering, as recommended in
          <xref target="RFC2827"/> and <xref target="RFC3704"/>.</t>

        <t>A site security policy intended to protect against attacks
          using RH0 SHOULD include the implementation of ingress filtering
          at the site border.</t>
      </section>

      <section title="Firewall Policy" anchor="filtering">
	<t>Blocking all IPv6 packets that carry Routing Headers
	  (rather than specifically blocking Type 0 and permitting
	  other types) has very serious implications for the future
	  development of IPv6.  If even a small percentage of
	  deployed firewalls block other types of Routing Headers
	  by default, it will become impossible in practice to
	  extend IPv6 Routing Headers. For example, Mobile IPv6
	  <xref target="RFC3775"/> relies upon a Type 2 Routing Header; wide-scale,
	  indiscriminate blocking of Routing Headers will make
	  Mobile IPv6 undeployable.</t>

	<t>Firewall policy intended to protect against packets
	  containing RH0 MUST NOT simply filter all traffic with a
	  Routing Header; it must be possible to disable forwarding
	  of Type 0 traffic without blocking other types of Routing
	  Headers. In addition, the default configuration MUST
	  permit forwarding of traffic using a Routing Header other than 0.</t>
      </section>
    </section>

    <section title="Security Considerations" anchor="security">
      <t>The purpose of this document is to deprecate a feature
	of IPv6 that has been shown to have undesirable security
	implications.  Specific examples of vulnerabilities that
	are facilitated by the availability of RH0 can be found in
	<xref target="CanSecWest07"/>. In particular, RH0 provides
	a mechanism for traffic amplification, which might be used
	as a denial-of-service attack. A description of this
	functionality can be found in <xref target="introduction"/>.</t>
    </section>

    <section title="IANA Considerations">
      <t>The IANA registry "Internet Protocol Version 6 (IPv6)
	Parameters" should be updated to reflect that variant 0 of
	IPv6 header-type 43 ("Routing Header") is deprecated.</t>
    </section>

    <section title="Acknowledgements" anchor="acknowledgements">
      <t>This document benefits from the contributions of many
        IPV6 and V6OPS working group participants, including
          Jari Arkko, Arnaud Ebalard,
          Tim Enos, Brian Haberman,
          Jun-ichiro itojun Hagino, Bob Hinden, Thomas Narten,
          Jinmei Tatuya,
          David Malone, Jeroen Massar, Dave Thaler, and
          Guillaume Valadon.</t>
    </section>
  </middle>
<?rfc needLines="15" ?>
  <back>
    <references title="Normative References">
        &rfc2119;
        &rfc2460;
        &rfc4294;
    </references>

    <references title="Informative References">
      &rfc2827;
      &rfc3704;
      &rfc3775;
      
<reference anchor="Security">
	<front>
	<title>
Security of IPv6 Routing Header and Home Address Options
</title>
	<author initials="P" surname="Savola" fullname="Pekka Savola">
<organization/>
</author>
<date month="March" year="2002"/>
</front>
<seriesInfo name="Work in" value="Progress"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-02.txt"/>
</reference>


<reference anchor="Hosts">
	<front>
<title>Note about Routing Header Processing on IPv6 Hosts</title>
	<author initials="P" surname="Savola" fullname="Pekka Savola">
<organization/>
</author>
<date month="February" year="2002"/>
</front>
<seriesInfo name="Work in" value="Progress"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-hosts-00.txt"/>
</reference>

      &rfc4942;

      <reference anchor="CanSecWest07">
        <front>
          <title>IPv6 Routing Header Security</title>
          <author initials="P." surname="Biondi"
            fullname="Philippe Biondi">
            <organization>EADS Innovation Works</organization>
          </author>
          <author initials="A." surname="Ebalard"
            fullname="Arnaud Ebalard">
            <organization>EADS Innovation Works</organization>
          </author>
          <date month="April" year="2007"/>
        </front>
        <seriesInfo name="CanSecWest Security Conference" value="2007"/>
        <format type="PDF"
          target="http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf"/>
        <annotation>http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf</annotation>
      </reference>
    </references>

  </back>
</rfc>