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

Versions: 00

Network Working Group                                       A. Narayanan
Internet-Draft                                            F. Le Faucheur
Intended status: Standards Track                                 D. Ward
Expires: September 4, 2009                                     R. Rahman
                                                                   Cisco
                                                           March 3, 2009


                    IP Router Alert Option Extension
             draft-narayanan-rtg-router-alert-extension-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 September 4, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.







Narayanan, et al.       Expires September 4, 2009               [Page 1]


Internet-Draft        Router Alert Option Extension           March 2009


Abstract

   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.


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IP Router Alert Option Enhancement . . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
























Narayanan, et al.       Expires September 4, 2009               [Page 2]


Internet-Draft        Router Alert Option Extension           March 2009


1.  Terminology

   For readability, this document uses the following loosely defined
   terms:

   o  Slow path : Software processing path for packets

   o  Fast path : ASIC/Hardware processing path for packets

1.1.  Conventions Used in This Document

   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 [RFC2119].





































Narayanan, et al.       Expires September 4, 2009               [Page 3]


Internet-Draft        Router Alert Option Extension           March 2009


2.  Introduction

   [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router
   Alert Option.  In this document, we collectively refer to those as
   the IP Router Alert.  RSVP ([RFC2205], [RFC3209]), PGM ([RFC3208])
   and IGMP ([RFC3376]) 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.

   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.)

   [RFC4081] and [RFC2711] 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".

   [RFC2113] 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 [I-D.rahman-rtg-router-alert-considerations].  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.

   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



Narayanan, et al.       Expires September 4, 2009               [Page 4]


Internet-Draft        Router Alert Option Extension           March 2009


   (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:

   o  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.

   o  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).

   o  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.

   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 Section 4.





























Narayanan, et al.       Expires September 4, 2009               [Page 5]


Internet-Draft        Router Alert Option Extension           March 2009


3.  IP Router Alert Option Enhancement

   We propose an extension to the specification and processing behaviour
   of the IP RAO header.  [RFC2113] specifies a 2-octet value in the IP
   RAO option field.  [RFC5350] specifies creation of an IANA registry
   for managing this 2-octet value, and proposes IPv4 RAO usage as
   follows:

    +-------------+--------------------------------------+-----------+
    | Value       | Description                          | Reference |
    +-------------+--------------------------------------+-----------+
    | 0           | Router Shall Examine Packet          | RFC2113   |
    |             |                                      |           |
    | 1-32        | Aggregated Reservation Nesting Level | RFC3175   |
    |             |                                      |           |
    | 33-65502    | Available for assignment by the IANA | RFC5350   |
    |             |                                      |           |
    | 65503-65534 | Available for experimental use       | RFC5350   |
    |             |                                      |           |
    | 65535       | Reserved                             | RFC5350   |
    +-------------+--------------------------------------+-----------+

   An IANA-maintained IPv6 RAO registry is specified in [RFC2711] and
   clarified in [RFC5350].  The current IPv6 RAO usage is:

      +----------+--------------------------------------+-----------+
      | Value    | Description                          | Reference |
      +----------+--------------------------------------+-----------+
      | 0        | Multicast Listener Discovery         | RFC2711   |
      |          |                                      |           |
      | 1        | RSVP                                 | RFC2711   |
      |          |                                      |           |
      | 2        | Active Networks                      | RFC2711   |
      |          |                                      |           |
      | 3        | Reserved                             | RFC5350   |
      |          |                                      |           |
      | 4-35     | RSVP Aggregation                     | RFC3175   |
      |          |                                      |           |
      | 36-65535 | Available for assignment by the IANA | RFC2711   |
      +----------+--------------------------------------+-----------+

   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:





Narayanan, et al.       Expires September 4, 2009               [Page 6]


Internet-Draft        Router Alert Option Extension           March 2009

        +----------------------------+---------------------------+
        | service selector (10 bits) | context selector (6 bits) |
        +----------------------------+---------------------------+

   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.

   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:

   o  RSVP - IPv4: 0-32, IPv6: 1, 4-35 ([RFC2205],[RFC3175])

   o  RSVP/TE - IPv4: 0, IPv6: 1 ([RFC3209])

   o  IGMPv2 - IPv4: 0 ([RFC2236])

   o  IGMPv3 - IPv4: 0 ([RFC3376])

   o  MLDv1 - IPv6: 0 ([RFC2710])

   o  MLDv2 - IPv6: 0 ([RFC3810])

   o  Multicast Router Discovery - IPv4: 0, IPv6: unspecified
      ([RFC4286])

   o  PGM - IPv4: 0 ([RFC3208])

   o  Active Network - IPv6: 2 (cited in [RFC2711])

   Correspondingly, "new protocols" are those for which the use of IP
   Router-Alert has not yet been standardized.

   For service selector 1-1022, the value of the service and context



Narayanan, et al.       Expires September 4, 2009               [Page 7]


Internet-Draft        Router Alert Option Extension           March 2009


   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 [RFC3175] 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.

   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.

   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.

   All the practices described in
   [I-D.rahman-rtg-router-alert-considerations] 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.













Narayanan, et al.       Expires September 4, 2009               [Page 8]


Internet-Draft        Router Alert Option Extension           March 2009


4.  Security Considerations

   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.

   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.






























Narayanan, et al.       Expires September 4, 2009               [Page 9]


Internet-Draft        Router Alert Option Extension           March 2009


5.  IANA Considerations

   This document requires an extension to the IP RAO IANA registry
   established in [RFC5350].  IP Router-Alert Option values will be
   assigned as described in Section 3.














































Narayanan, et al.       Expires September 4, 2009              [Page 10]


Internet-Draft        Router Alert Option Extension           March 2009


6.  Acknowledgments

   We would like to thank Dave Oran, Magnus Westerlund, John Scudder,
   Ron Bonica, Ross Callon, and Alfred Hines for their comments.















































Narayanan, et al.       Expires September 4, 2009              [Page 11]


Internet-Draft        Router Alert Option Extension           March 2009


7.  References

7.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113,
              February 1997.

   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
              RFC 2711, October 1999.

7.2.  Informative References

   [I-D.dasmith-mpls-ip-options]
              Jaeger, W., Mullooly, J., Scholl, T., and D. Smith,
              "Requirements for Label Edge Router Forwarding of IPv4
              Option Packets", draft-dasmith-mpls-ip-options-01 (work in
              progress), October 2008.

   [I-D.rahman-rtg-router-alert-considerations]
              Rahman, R., "IP Router Alert Considerations and Usage",
              draft-rahman-rtg-router-alert-considerations-00 (work in
              progress), November 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC3175]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
              "Aggregation of RSVP for IPv4 and IPv6 Reservations",
              RFC 3175, September 2001.

   [RFC3208]  Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D.,
              Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo,
              L., Tweedly, A., Bhaskar, N., Edmonstone, R.,
              Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport



Narayanan, et al.       Expires September 4, 2009              [Page 12]


Internet-Draft        Router Alert Option Extension           March 2009


              Protocol Specification", RFC 3208, December 2001.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC4081]  Tschofenig, H. and D. Kroeselberg, "Security Threats for
              Next Steps in Signaling (NSIS)", RFC 4081, June 2005.

   [RFC4286]  Haberman, B. and J. Martin, "Multicast Router Discovery",
              RFC 4286, December 2005.

   [RFC4782]  Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
              Start for TCP and IP", RFC 4782, January 2007.

   [RFC5350]  Manner, J. and A. McDonald, "IANA Considerations for the
              IPv4 and IPv6 Router Alert Options", RFC 5350,
              September 2008.


























Narayanan, et al.       Expires September 4, 2009              [Page 13]


Internet-Draft        Router Alert Option Extension           March 2009


Authors' Addresses

   Ashok Narayanan
   Cisco Systems
   1414 Mass Ave
   Boxborough, MA  01719
   USA

   Email: ashokn@cisco.com


   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis,   06410
   France

   Email: flefauch@cisco.com


   David Ward
   Cisco Systems


   Email: dward@cisco.com


   Reshad Rahman
   Cisco Systems
   2000 Innovation Dr.
   Kanata, Ontario  K2K 3E8
   Canada

   Email: rrahman@cisco.com

















Narayanan, et al.       Expires September 4, 2009              [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/