One document matched: draft-narayanan-rtg-router-alert-extension-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
]>
<rfc category="std" docName="draft-narayanan-rtg-router-alert-extension-00"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Router Alert Option Extension">IP Router Alert Option
    Extension</title>

    <author fullname="Ashok Narayanan" initials="A." surname="Narayanan">
      <organization abbrev="Cisco">Cisco Systems</organization>

      <address>
        <postal>
          <street>1414 Mass Ave</street>

          <city>Boxborough</city>

          <region>MA</region>

          <code>01719</code>

          <country>USA</country>
        </postal>

        <email>ashokn@cisco.com</email>
      </address>
    </author>

    <author fullname="Francois Le Faucheur" initials="F."
            surname="Le Faucheur">
      <organization abbrev="Cisco">Cisco Systems</organization>

      <address>
        <postal>
          <street>Greenside, 400 Avenue de Roumanille</street>

          <city>Sophia Antipolis</city>

          <region></region>

          <code>06410</code>

          <country>France</country>
        </postal>

        <email>flefauch@cisco.com</email>
      </address>
    </author>

    <author fullname="David Ward" initials="D." surname="Ward">
      <organization abbrev="Cisco">Cisco Systems</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <email>dward@cisco.com</email>
      </address>
    </author>

    <author fullname="Reshad Rahman" initials="R." surname="Rahman">
      <organization abbrev="Cisco">Cisco Systems</organization>

      <address>
        <postal>
          <street>2000 Innovation Dr.</street>

          <city>Kanata</city>

          <region>Ontario</region>

          <code>K2K 3E8</code>

          <country>Canada</country>
        </postal>

        <email>rrahman@cisco.com</email>
      </address>
    </author>

    <date day="3" month="March" year="2009" />

    <area>Routing</area>

    <abstract>
      <t>The IP Router Alert Option is an IP option that alerts transit
      routers to more closely examine the contents of an IP packet. RSVP, PGM
      and IGMP are some of the protocols which make use of the IP Router Alert
      option. The current specification for the IP Router Alert Option does
      not define mechanisms to facilitate discriminating across different
      users of Router Alert. As a result, networks using router Alert may have
      more secuity exposure than necessary and/or may unnecessarily block some
      transit Router Alert packets. This document describes new rules for the
      IP Router-Alert Option that aid routers to process these packets more
      selectively.</t>
    </abstract>
  </front>

  <middle>
    <section title="Terminology">
      <t>For readability, this document uses the following loosely defined
      terms:<list style="symbols">
          <t>Slow path : Software processing path for packets</t>

          <t>Fast path : ASIC/Hardware processing path for packets</t>
        </list></t>

      <section title="Conventions Used in This Document">
        <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"></xref>.</t>
      </section>
    </section>

    <section title="Introduction">
      <t><xref target="RFC2113"></xref> and <xref target="RFC2711"></xref>
      respectively define the IPv4 and IPv6 Router Alert Option. In this
      document, we collectively refer to those as the IP Router Alert. RSVP
      (<xref target="RFC2205"></xref>, <xref target="RFC3209"></xref>), PGM
      (<xref target="RFC3208"></xref>) and IGMP (<xref
      target="RFC3376"></xref>) are but some of the protocols which make use
      of the IP Router Alert. Those protocols are used to support critical
      elements of the Internet infrastructure (e.g. RSVP-TE for traffic
      engineering within a service provider network) and as such they need to
      be protected.</t>

      <t>IP datagrams carrying the IP Router Alert are usually examined in a
      router’s "slow path" and an excess of such datagrams can cause
      performance degradation or packet drops in a router’s "slow path".
      (Note that a router’s "slow path” can potentially also be
      attacked with IP packets destined to one of the router’s local IP
      addresses and requires corresponding security protection.)</t>

      <t><xref target="RFC4081"></xref> and <xref target="RFC2711"></xref>
      mention the security risks associated with the use of the IP Router
      Alert: flooding a router with bogus IP datagrams which contain the IP
      Router Alert would cause a performance degradation of the router’s
      "slow path" and can also lead to packet drops in the "slow path".</t>

      <t><xref target="RFC2113"></xref> specifies no mechanism for identifying
      different users of IP Router Alert. As a result, many fast switching
      implementations of IP Router Alert punt most/all packets marked with IP
      Router Alert into the slow path. To protect against overloading routers
      which receive a large number of IP Router Alert packets that they do not
      need to process, many router implementations limit the rate of packets
      punted into the slow path, but once again the lack of discrimination of
      different protocols may hamper the smooth functioning of protocols that
      depend on IP Router Alert. Further, some network operators actively
      protect routers from IP Router Alert packets by discarding these packets
      at the edge, which is undesirable for end-to-end operation of protocols
      carrying this option. Details on these issues and some recommendations
      on best practices are described in <xref
      target="I-D.rahman-rtg-router-alert-considerations"></xref>. The
      specification of an efficient, general-purpose, protocol-independent
      mechanism for discriminating between different applications would aid
      router implementations to more efficiently select the protocol messages
      they need to punt and locally process, while ignoring and forwarding in
      the fast path the messages that they do not need to see.</t>

      <t>This document enhances the current specification of Router Alert to
      ensure that risks associated with unintentional interception of packets
      that are not of real interest to a given router are minimized (if not
      eliminated) by facilitating identification in the fast path of the
      subset of packets with router alert that are of interest to the router.
      A key aspect of the proposal is to facilitate finer grain identification
      of router alert packets of interest versus unwanted router alert packets
      while only requiring inspection of the router alert header. In
      particular:</t>

      <t><list style="symbols">
          <t>the enhancement allows the router to identify the application of
          packets marked with IP Router-Alert by simply examining the IP
          header, independent of any application packet format.</t>

          <t>the enhancement allows router alert packets from different
          application protocols to be easily distinguished even if they share
          the same transport protocol (i.e. the have the same IP PID).</t>

          <t>the enhancement allows router alert packets for the same
          application protocol but associated with different contexts (e.g.
          end to end RSVP vs internal RSVP-TE) to be easily distinguished.</t>
        </list>Note that this mechanism does not prevent attacks of the form
      of bogus protocol messages which may be of interest to the router. More
      details on this are presented in <xref target="security"></xref>.</t>
    </section>

    <section anchor="enhancement" title="IP Router Alert Option Enhancement">
      <t>We propose an extension to the specification and processing behaviour
      of the IP RAO header. <xref target="RFC2113"></xref> specifies a 2-octet
      value in the IP RAO option field. <xref target="RFC5350"></xref>
      specifies creation of an IANA registry for managing this 2-octet value,
      and proposes IPv4 RAO usage as follows:</t>

      <texttable>
        <ttcol>Value</ttcol>

        <ttcol>Description</ttcol>

        <ttcol>Reference</ttcol>

        <c>0</c>

        <c>Router Shall Examine Packet</c>

        <c>RFC2113</c>

        <c>1-32</c>

        <c>Aggregated Reservation Nesting Level</c>

        <c>RFC3175</c>

        <c>33-65502</c>

        <c>Available for assignment by the IANA</c>

        <c>RFC5350</c>

        <c>65503-65534</c>

        <c>Available for experimental use</c>

        <c>RFC5350</c>

        <c>65535</c>

        <c>Reserved</c>

        <c>RFC5350</c>
      </texttable>

      <t>An IANA-maintained IPv6 RAO registry is specified in <xref
      target="RFC2711"></xref> and clarified in <xref
      target="RFC5350"></xref>. The current IPv6 RAO usage is:</t>

      <texttable>
        <ttcol>Value</ttcol>

        <ttcol>Description</ttcol>

        <ttcol>Reference</ttcol>

        <c>0</c>

        <c>Multicast Listener Discovery</c>

        <c>RFC2711</c>

        <c>1</c>

        <c>RSVP</c>

        <c>RFC2711</c>

        <c>2</c>

        <c>Active Networks</c>

        <c>RFC2711</c>

        <c>3</c>

        <c>Reserved</c>

        <c>RFC5350</c>

        <c>4-35</c>

        <c>RSVP Aggregation</c>

        <c>RFC3175</c>

        <c>36-65535</c>

        <c>Available for assignment by the IANA</c>

        <c>RFC2711</c>
      </texttable>

      <t></t>

      <t>We propose to extend the definition of IP Router-Alert Option values.
      The 2-octet Option Value field will now be used to identify the protocol
      and context from an IP RAO perspective. For IANA assignment purposes,
      this value will be split into two fields as follows:</t>

      <texttable>
        <ttcol>service selector (10 bits)</ttcol>

        <ttcol>context selector (6 bits)</ttcol>
      </texttable>

      <t>The service selector will be assigned to different applications by
      IANA and the context selector will be specific to the application
      protocol. Service selector 0 is reserved for backward compatibility and
      service selector 1023 is reserved for experimental use. Depending on
      requirements, a single protocol or application may be assigned multiple
      service selectors. All currently assigned option values of IPv4 and IPv6
      RAO have service selector 0. The experimental use range is extended to
      be 65472-65534.</t>

      <t>All new protocols using IP RAO MUST request allocations of new
      service and context selector values, and MUST follow this format for the
      Option Value in the IP header. Additionally, new service and context
      selector values will be allocated for legacy protocols using IP RAO.
      Existing implementations of these legacy protocols SHOULD be updated to
      use the new selector values. The use of new option values for legacy
      protocols SHOULD be configurable by the user, and SHOULD be on by
      default. However, extensions to legacy protocols that require new option
      values MUST follow the new option format. For the purposes of this
      requirement, "legacy protocols" are defined as those already
      standardized in the IETF as using IP Router-Alert - specifically:</t>

      <t><list style="symbols">
          <t>RSVP - IPv4: 0-32, IPv6: 1, 4-35 (<xref
          target="RFC2205"></xref>,<xref target="RFC3175"></xref>)</t>

          <t>RSVP/TE - IPv4: 0, IPv6: 1 (<xref target="RFC3209"></xref>)</t>

          <t>IGMPv2 - IPv4: 0 (<xref target="RFC2236"></xref>)</t>

          <t>IGMPv3 - IPv4: 0 (<xref target="RFC3376"></xref>)</t>

          <t>MLDv1 - IPv6: 0 (<xref target="RFC2710"></xref>)</t>

          <t>MLDv2 - IPv6: 0 (<xref target="RFC3810"></xref>)</t>

          <t>Multicast Router Discovery - IPv4: 0, IPv6: unspecified (<xref
          target="RFC4286"></xref>)</t>

          <t>PGM - IPv4: 0 (<xref target="RFC3208"></xref>)</t>

          <t>Active Network - IPv6: 2 (cited in <xref
          target="RFC2711"></xref>)</t>
        </list>Correspondingly, "new protocols" are those for which the use of
      IP Router-Alert has not yet been standardized.</t>

      <t>For service selector 1-1022, the value of the service and context
      selector fields MUST be assigned in a manner such that the content of
      the IP RAO option is sufficient to determine whether a packet is of
      interest to a node, with a reasonable level of granularity. For example,
      having the <xref target="RFC3175"></xref> aggregate reservation nesting
      level in the context selector allows P routers to quickly separate out
      RSVP messages for aggregate vs. end-to-end flows. Or, a separate context
      (or service) selector for RSVP-IPv4 vs. RSVP-TE sessions allows nodes to
      efficiently ignore one session type while processing another. Also,
      service and context selectors SHOULD be assigned the same for IPv4 and
      IPv6 versions of the same application.</t>

      <t>Fast path switching implementations SHOULD first look at the service
      selector and context selector fields to determine whether they wish to
      select a packet with IP RAO for local processing. A table of in-use
      service and context selector values can be looked up during packet
      switching to determine whether the packet is to be locally processed.
      Thus, for packets marked with service selectors 1-1022, the value of the
      IP RAO value field is sufficient to rapidly determine whether the packet
      may be forwarded unmodified or whether it should be examined further for
      local processing. If the protocol/context selector of the packet does
      not match those that are of interest to currently running protocols, the
      router SHOULD forward these packets unmodified in the fast path. By
      extension, if no applications that use IP Router-Alert are currently
      running on the router, the router SHOULD forward all packets with IP
      Router-Alert Option in the fast path, unmodified.</t>

      <t>The service selector 0 is reserved for backwards compatibility. For
      packets marked with service selector 0, the packet MUST be examined
      further to determine whether it is of local interest, in compliance with
      current protocol requirements. The context selector may be ignored for
      these packets.</t>

      <t>All the practices described in <xref
      target="I-D.rahman-rtg-router-alert-considerations"></xref> regarding
      protecting router control plane resources from attacks based on IP RAO,
      and protecting different protocols using IP RAO from each other,
      continue to apply in this context.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This document describes an efficient mechanism for router
      implementations to identify packets marked with the IP Router-Alert
      Option but which are not of interest to this router, and forward them
      unprocessed.</t>

      <t>It is important to note that the use of this extension does not
      change in any way the security properties of the IP Router-Alert Option.
      Specifically, no claim is made of enhancing the security of IP
      Router-Alert Option usage. An attacker can always consume excess
      resources on a router's control plane and/or slow path by sending it
      bogus packets with IP RAO protocol/context selector values that are of
      interest to the router. However, the network operator now has the option
      to selectively suppress incoming IP RAO packets at the edge for
      protocols they are using in their network, while still permitting other
      applications with IP RAO to transit efficiently across their network.
      For example, a network operator could choose to suppress incoming IP RAO
      packets at the edge corresponding to RSVP/TE if they are using RSVP/TE
      in their network, but still transit end-to-end IPv4 RSVP sessions
      efficiently.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document requires an extension to the IP RAO IANA registry
      established in <xref target="RFC5350"></xref>. IP Router-Alert Option
      values will be assigned as described in <xref
      target="enhancement"></xref>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgments">
      <t>We would like to thank Dave Oran, Magnus Westerlund, John Scudder,
      Ron Bonica, Ross Callon, and Alfred Hines for their comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2113"?>

      <?rfc include="reference.RFC.2711"?>

      <?rfc include="reference.RFC.0791"?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.dasmith-mpls-ip-options'?>

      <?rfc include="reference.RFC.4081"?>

      <?rfc include="reference.RFC.3209"?>

      <?rfc include="reference.RFC.2205"?>

      <?rfc include="reference.RFC.3208"?>

      <?rfc include="reference.RFC.2236"?>

      <?rfc include="reference.RFC.3376"?>

      <?rfc include="reference.RFC.2710"?>

      <?rfc include="reference.RFC.3810"?>

      <?rfc include="reference.RFC.4782"?>

      <?rfc include="reference.RFC.4286"?>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.5350"?>

      <?rfc include="reference.RFC.3175"?>

      <?rfc include='reference.I-D.rahman-rtg-router-alert-considerations'?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>
    </references>
  </back>
</rfc>