Network Working Group F. Le Faucheur, Ed.
Internet-Draft Cisco
Intended status: BCP March 9, 2009
Expires: September 10, 2009
IP Router Alert Considerations and Usage
draft-rahman-rtg-router-alert-considerations-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 10, 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
Le Faucheur Expires September 10, 2009 [Page 1]
Internet-Draft Router Alert Considerations March 2009
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.
Le Faucheur Expires September 10, 2009 [Page 2]
Internet-Draft Router Alert Considerations 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, IGMP/MLD and MRD are some of the protocols which make use of the
IP Router Alert option. This document discusses security aspects and
common practices around the use of the current IP Router Alert option
and discusses consequences on the use of IP Router Alert by existing
or new applications. Common practices in IP Router Alert
implementation facilitating router protection are also discussed.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Guidelines for use of Router Alert . . . . . . . . . . . . . . 7
3.1. Reliance on Router Alert by Applications . . . . . . . . . 7
3.2. When Consenting Adults Exchange IP Router Alert Packets . 8
4. Example Protection Mechanisms in a Router Alert
Implementation . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Handling Packets Carrying the Router Alert Option . . . . 10
4.2. Applying Rate Limiting . . . . . . . . . . . . . . . . . . 10
4.3. Router Alert in Congested Systems . . . . . . . . . . . . 11
4.4. Handling Unknown Payload Protocols . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Le Faucheur Expires September 10, 2009 [Page 3]
Internet-Draft Router Alert Considerations 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].
Le Faucheur Expires September 10, 2009 [Page 4]
Internet-Draft Router Alert Considerations 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], [RFC3175], [RFC3209]), PGM
([RFC3208]), IGMP ([RFC2236] [RFC3376]), MLD ([RFC2710], [RFC3810])
and MRD ([RFC4286]) are 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. Some IP Router Alert implementations may be able
to take into account the IP PID [RFC0791] as a discriminator for the
punting decision for different protocols using IP Router Alert.
However, this still only allows very coarse triage among various
protocols using IP Router Alert for two reasons. First, the IP PID
is the same when IP Router Alert is used for different applications
of the same protocol (e.g., RSVP vs. RSVP-TE), or when IP Router
Alert is used for different contexts of the same application (e.g.,
different levels of RSVP aggregation [RFC3175]). Thus, it is not
possible to achieve the necessary triage in the fast path across IP
Router Alert packets from different applications or from different
contexts of an application. Secondly, some protocols requiring
punting may be carried over a transport protocol (e.g., TCP or UDP)
possibly because they require the services of that transport protocol
or perhaps because the protocol does not justify allocation of a
scarce IP PID value. Thus, considering the PID does not allow triage
in the fast path of IP Router Alert packets from different protocols
sharing the same transport protocol. Therefore, It is generally not
possible to ensure that only the IP Router Alert packets of interest
are punted to the slow path while other IP Router Alert packets are
Le Faucheur Expires September 10, 2009 [Page 5]
Internet-Draft Router Alert Considerations March 2009
efficiently forwarded (i.e., in fast path). This means that an
operator will often have to choose between a mode where the routers
ignore IP Router Alert and forwards all packets in fast path and a
mode where the routers honor IP Router Alert but then punt to slow
path all/most of the IP Router Alert packets including those that are
not of interest to the router.
[RFC2711] mentions that limiting, by rate or some other means, the
use of IP Router Alert option is a way of protecting against a
potential attack. However, if rate limiting is used as a protection
mechanism but if the granularity of the rate limiting is not fine
enough to distinguish among IP Router Alert packet of interest from
unwanted IP Router Alert packet, a IP Router Alert attack could still
severely degrade operation of protocols of interest that depend on
the use of IP Router Alert. Section 4 discusses examples of
protection mechanisms that may be available from a router
implementation of the IP Router Alert.
In some environments where it is not possible to accurately and
reliably distinguish between IP Router Alert packets of interest and
unwanted IP Router Alert packets, operators have resorted to actively
protecting themselves against externally generated IP Router Alert
packets in ways that result in end to end IP Router Alert packets
being (occasionally or systematically) dropped and/or ignored on a
segment. The consequences of such practises on the use of IP Router
Alert by existing or new applications are discussed in Section 3 of
the present document. Section 3 also discusses environments where IP
Router Alert can be used effectively.
The present document discusses considerations and practises based on
the current specification of IP Router Alert ([RFC2113], [RFC2711]).
Possible future enhancements to the specification of IP Router Alert
(in view of reducing the security risks associated with the use of IP
Router Alert) are outside the scope of this document. A proposal for
such enhancements can be found in [I-D.narayanan-rtg-router-alert-
extension] .
Le Faucheur Expires September 10, 2009 [Page 6]
Internet-Draft Router Alert Considerations March 2009
3. Guidelines for use of Router Alert
3.1. Reliance on Router Alert by Applications
First, as mentioned earlier, some networks actively protect
themselves against externally generated IP Router Alert packets.
This may be by tunneling IP Router Alert packets
[I-D.dasmith-mpls-ip-options] so that the IP Router Alert option is
hidden through that network or it may be via mechanisms resulting in
occasional (e.g., rate limiting) or systematic drop of IP Router
Alert packets.
Secondly, application protocols are often not carried directly on top
of IP but rather are carried by a transport protocol such as UDP,
TCP, or SCTP that in turns runs over IP. In these cases, the
application protocol is not visible in the IP header (that only
contains information about the transport protocol) and could not be
determined without further "deep packet" inspection. In the event of
the IP Router Alert option being used for an application protocol
carried in a transport protocol, the intercepted IP packet would be
delivered to the transport protocol for processing in accordance with
[RFC2113] (as opposed to being delivered directly to the application
protocol). However, the behavior of the transport protocol in these
circumstances is not defined, and may cause rejection of the packet
for various reasons.
As a consequence, in the general case of open networks, applications
can not safely rely on IP Router Alert packets being visible to all
nodes on the path today, and importantly can not even rely on IP
Router Alert packets being transported end to end.
[RFC2113] implies that the router may examine other fields of a
received packet that contains the IP Router Alert option to decide
whether that packet needs further processing, but no further advice
is given. Examination of other fields of the received IP packet that
carries the IP Router Alert to help determine what to do with the
packet would result in implementation-specific behavior that is
unpredictable to the sender of the packet. Therefore applications
cannot depend on IP Router Alert interception involving inspection of
fields in the packet outside the IP header.
Thus, creating a new application or end-to-end protocol that depends
on use of the current IP Router Alert ([RFC2113], [RFC2711]) is
considered harmful and it is RECOMMENDED that such new application or
protocol be developed without using IP Router Alert. A different
mechanism SHOULD be used in order to increase likelihood of operation
of that application/protocol end-to-end and to decrease the risk of
impacting existing protocols that use the IP Router Alert option.
Le Faucheur Expires September 10, 2009 [Page 7]
Internet-Draft Router Alert Considerations March 2009
3.2. When Consenting Adults Exchange IP Router Alert Packets
In some controlled environments, the network administrator can
determine that IP Router Alert packets will only be received from
trusted well-behaved devices or can establish that the protection
mechanisms discussed in the present document against the plausible
RAO-based DoS attacks (e.g., RAO filtering and rate-limiting) are
sufficient. In that case, an application relying on exchange and
handling of RAO packets (e.g., RSVP) may be safely deployed within
the controlled network. In other words, a network that feels
appropriately protected against the risks associated with his
environment, may decide to freely and openly partake in IP Router
Alert message exchange with consenting entities. A private
enterprise network firewalled from the Internet and using RSVP for
voice and video reservation/admission control may be an example of
such controlled environment.
In some environments, the network administrator can reliably ensure
that router alert packets from any untrusted device (e.g., from
external routers) are prevented from entering a trusted area (e.g.,
the internal routers). For example, this may be achieved by ensuring
that routers straddling the trust boundary (e.g., edge routers)
always encapsulate those packets (without setting IP Router Alert -or
equivalent- in the encapsulating header) through the trusted area (as
discussed in [I-D.dasmith-mpls-ip-options]). In such environments,
the risks of DOS attacks through the IP Router Alert vector is
removed in the trusted area (or greatly reduced) even if IP Router
Alert is used inside the trusted area (say for RSVP-TE). Thus an
application relying on IP Router Alert may be safely deployed within
the trusted area. In other words, the network protects itself from
the risks of partaking in IP Router Alert exchange with strangers but
feels free to exchange IP Router Alert messages among trusted
parties. A Service Provider running RSVP-TE within his network may
be an example of such protected environment.
When a controlled environment requires RAO packet exchange across his
routers for some application (e.g., RSVP) and transits via a Service
Provider network (that is not part of the controlled environment),
the administrator of the controlled environment needs to ensure with
the Service Provider that the IP Router Alert messages will not be
dropped when transiting the Service Provider network. In other
words, the network ought to ensure that another network that needs to
be involved in the exchange of IP Router Alert packets is consenting.
[Editor's Note: the authors of this document are seeking feedback on
the recommendations suggested below]
Since some existing applications would benefit from end-to-end
Le Faucheur Expires September 10, 2009 [Page 8]
Internet-Draft Router Alert Considerations March 2009
transport of IP Router Alert packets, it is RECOMMENDED that a
Service Provider protects his network from attacks based on IP Router
Alert using mechanisms that avoid (or at least minimize) dropping of
end to end IP Router Alert packets (other than those involved in the
attack). For example, if the Service Provider does not run any
protocol depending on IP Router Alert within his network, he may
elect to simply turn-off punting of IP Router Alert packet on his
routers; this will ensure that end-to-end IP Router Alert packet
transit transparently and safely through his network. As another
example, using protection mechanisms such as those described in
Section 4 a Service Provider can protect the operation of a protocol
depending on IP Router Alert within his network (e.g., RSVP-TE) while
at the same time transporting IP Router Alert packets carrying
another protocol that may be used end to end. As yet another
example, using mechanisms such as those discussed in
[I-D.dasmith-mpls-ip-options] a Service Provider can safely protect
the operation of a protocol depending on IP Router Alert within his
network (e.g., RSVP-TE) while at the same time safely transporting IP
Router Alert packets carrying another protocol that may be used end
to end (e.g., IPv4/IPv6 RSVP).
As a last resort, if the Service Provider does not have any means to
safely transport end to end IP Router Alert packets over his network,
it is RECOMMENDED that, rather than dropping those packets, the
Service Provider forwards these packets through his network after
removing the IP Router Alert option from the IP header on ingress/
receipt of the packet. This ensures that the packet will, at least,
make it through the Service Provider network allowing the packet to
be potentially intercepted on the other side via other means than the
IP Router Alert.
Where the Service Provider does not ensure reliable transport of IP
Router Alert packets (i.e., those are systematically or likely
dropped) for an end to end protocol of interest to a user, the user
can consider removing the IP Router Alert option from the IP header
before sending the packet to the Service Provider and may then
intercept the packet on the other side using some other interception
technique (and then possibly restore the IP Router alert option).
Le Faucheur Expires September 10, 2009 [Page 9]
Internet-Draft Router Alert Considerations March 2009
4. Example Protection Mechanisms in a Router Alert Implementation
Implementations of IP Router Alert on routers generally include
mechanisms for protection against the associated security risk. This
section provides examples of behaviors that may be supported by
router implementations to help protect the router.
[Editor's Note: the authors of this document are seeking feedback
about whether such mechanisms (or a subset/superset of those) ought
to be elevated to BCP requirements, recommendations and options
instead of simply described as examples.]
4.1. Handling Packets Carrying the Router Alert Option
o a router implementation may elect to perform packet inspection to
see whether they carry the IP Router Alert option in the "fast
path". This avoids punting all packets to the slow path when the
router is interested in some IP Router Alert packets.
o a router implementation may elect to not send to the "slow path"
IP packets carrying the IP Router Alert option unless IP Router
Alert interception is explicitly enabled on the router (or
interface). This avoids punting any IP Router Alert packet when
the router is not interested in any of those.
o a router implementation may elect to not send to the "slow path"
IP packets carrying the IP Router Alert option unless there is at
least one protocol explicitly enabled on the router (or interface)
which is defined to use the IP Router Alert option. This avoids
punting any IP Router Alert packet when the router is not
interested in any of those.
o a router implementation may elect to allow configuration of which
protocol is "of interest" for the IP Router Alert option
interception (on router or interface level). The router
implementation may then elect to not send packets carrying the
Router Alert option to the "slow path" unless the payload protocol
carried in the packet (as identified by the Protocol ID) is
configured as "protocol of interest". This avoids punting IP
Router Alert packet carrying a protocol in which the router is not
interested.
4.2. Applying Rate Limiting
o a router implementation may elect to support (in the fast path)
rate limiting of the number of IP Router Alert IP datagrams (e.g.,
at router or interface level) which go to the "slow path". The
benefits of rate limiting is described in [RFC2711].
Le Faucheur Expires September 10, 2009 [Page 10]
Internet-Draft Router Alert Considerations March 2009
o a router implementation may elect to support (in the fast path)
separate rate limiting per payload protocol. This allows one
protocol relying on IP Router Alert to be protected from DOS
attacks using IP Router Alert with a different protocol.
4.3. Router Alert in Congested Systems
o a router implementation may elect to support selective dropping of
packets carrying the IP Router Alert option (rather than pass them
to the "slow path") in preference to dropping other control plane
packets, in the face of control plane congestion. This protects
other control plane protocols from IP Router Alert attacks.
4.4. Handling Unknown Payload Protocols
If an IP packet contains the IP Router Alert option, but the payload
protocol is not explicitly identified as a Payload of interest by the
router examining the packet, the behavior is not defined by
[RFC2113]. However, the definition of RSVP in [RFC2205] assumes that
the packet will be forwarded using normal forwarding based on the
destination IP address.
o a router implementation may elect to forward within the "fast
path" (subject to all normal policies and forwarding rules) a
packet carrying the IP Router Alert option containing a payload
that is not a payload of interest to that router. The "not
passing" behavior protects the router from DOS attacks using IP
Router Alert packets of a protocol unknown to the router. The
"forwarding" behavior contributes to transparent end to end
transport of IP Router Alert packets (e.g., to facilitate their
use by end to end application).
Le Faucheur Expires September 10, 2009 [Page 11]
Internet-Draft Router Alert Considerations March 2009
5. Security Considerations
This document discusses security risks associated with current usage
of the IP Router Alert Option and associated practices.
Le Faucheur Expires September 10, 2009 [Page 12]
Internet-Draft Router Alert Considerations March 2009
6. IANA Considerations
None.
Le Faucheur Expires September 10, 2009 [Page 13]
Internet-Draft Router Alert Considerations March 2009
7. Contributors
The contributors to this document (in addition to the editors) are:
o Reshad Rahman:
* Cisco Systems
* rrahman@cisco.com
o David Ward:
* Cisco Systems
* wardd@cisco.com
o Ashok Narayanan:
* Cisco Systems
* ashokn@cisco.com
o Adrian Farrell:
* OldDog Consulting
* adrian@olddog.co.uk
o Tony Li:
* tony.li@tony.li
Le Faucheur Expires September 10, 2009 [Page 14]
Internet-Draft Router Alert Considerations March 2009
8. Acknowledgments
We would like to thank Dave Oran, Magnus Westerlund, John Scudder,
Ron Bonica, Ross Callon and Alfred Hines for their comments.
Le Faucheur Expires September 10, 2009 [Page 15]
Internet-Draft Router Alert Considerations March 2009
9. References
9.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.
9.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.
[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
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.
Le Faucheur Expires September 10, 2009 [Page 16]
Internet-Draft Router Alert Considerations March 2009
[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.
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the
IPv4 and IPv6 Router Alert Options", RFC 5350,
September 2008.
Le Faucheur Expires September 10, 2009 [Page 17]
Internet-Draft Router Alert Considerations March 2009
Author's Address
Francois Le Faucheur (editor)
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Le Faucheur Expires September 10, 2009 [Page 18]