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]