draft-ietf-intarea-router-alert-considerations-07.txt   draft-ietf-intarea-router-alert-considerations-08.txt 
Network Working Group F. Le Faucheur, Ed. Network Working Group F. Le Faucheur, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: BCP July 25, 2011 Intended status: BCP August 2, 2011
Expires: January 26, 2012 Expires: February 3, 2012
IP Router Alert Considerations and Usage IP Router Alert Considerations and Usage
draft-ietf-intarea-router-alert-considerations-07 draft-ietf-intarea-router-alert-considerations-08
Abstract Abstract
The IP Router Alert Option is an IP option that alerts transit The IP Router Alert Option is an IP option that alerts transit
routers to more closely examine the contents of an IP packet. routers to more closely examine the contents of an IP packet.
Resource reSerVation Protocol (RSVP), Pragmatic General Multicast Resource reSerVation Protocol (RSVP), Pragmatic General Multicast
(PGM), Internet Group Management Protocol (IGMP), Multicast Listener (PGM), Internet Group Management Protocol (IGMP), Multicast Listener
Discovery (MLD), Multicast Router Discovery (MRD) and General Discovery (MLD), Multicast Router Discovery (MRD) and General
Internet Signalling Transport (GIST) are some of the protocols that Internet Signalling Transport (GIST) are some of the protocols that
make use of the IP Router Alert Option. This document discusses make use of the IP Router Alert Option. This document discusses
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2012. This Internet-Draft will expire on February 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 10, line 26 skipping to change at page 10, line 26
4.2. Use of Router Alert In Controlled Environments 4.2. Use of Router Alert In Controlled Environments
4.2.1. Use of Router Alert Within an Administrative Domain 4.2.1. Use of Router Alert Within an Administrative Domain
In some controlled environments, such as within a given In some controlled environments, such as within a given
Administrative Domain, the network administrator can determine that Administrative Domain, the network administrator can determine that
IP Router Alert packets will only be received from trusted well- IP Router Alert packets will only be received from trusted well-
behaved devices or can establish that specific protection mechanisms behaved devices or can establish that specific protection mechanisms
(e.g., RAO filtering and rate-limiting) against the plausible RAO- (e.g., RAO filtering and rate-limiting) against the plausible RAO-
based DoS attacks are sufficient. In that case, an application based DoS attacks are sufficient. In that case, an application
relying on exchange and handling of RAO packets (e.g., RSVP) MAY be relying on exchange and handling of RAO packets (e.g., RSVP) can be
safely deployed within the controlled network. A private enterprise safely deployed within the controlled network. A private enterprise
network firewalled from the Internet and using RSVP reservations for network firewalled from the Internet and using RSVP reservations for
voice and video flows might be an example of such controlled voice and video flows might be an example of such controlled
environment. Such an environment is illustrated in Figure 2. environment. Such an environment is illustrated in Figure 2.
------------------------- -------- -------- ------------------------- -------- --------
/ A \ / B \ / C \ / A \ / B \ / C \
| (*) (*) | -- | | | | | (*) (*) | -- | | | |
| | |<============>| | |--|FW|--| |--------| | | | |<============>| | |--|FW|--| |--------| |
| - - | -- | | | | | - - | -- | | | |
skipping to change at page 11, line 11 skipping to change at page 11, line 11
In some controlled environments, several Administrative Domains have In some controlled environments, several Administrative Domains have
a special relationship whereby they cooperate very tightly and a special relationship whereby they cooperate very tightly and
effectively operate as a single trust domain. In that case, one effectively operate as a single trust domain. In that case, one
domain is willing to trust another with respect to the traffic domain is willing to trust another with respect to the traffic
injected across the boundary. In other words, a downstream domain is injected across the boundary. In other words, a downstream domain is
willing to trust that the traffic injected at the boundary has been willing to trust that the traffic injected at the boundary has been
properly validated/filtered by the upstream domain. Where it has properly validated/filtered by the upstream domain. Where it has
been established that such trust can be applied to router alert been established that such trust can be applied to router alert
option packets, an application relying on exchange and handling of option packets, an application relying on exchange and handling of
RAO packets (e.g., RSVP) MAY be safely deployed within such a RAO packets (e.g., RSVP) can be safely deployed within such a
controlled environment. The entity within a company responsible for controlled environment. The entity within a company responsible for
operating multimedia endpoints and the entity within the same company operating multimedia endpoints and the entity within the same company
responsible for operating the network might be an example of such responsible for operating the network might be an example of such
controlled environment. For example, they might collaborate so that controlled environment. For example, they might collaborate so that
RSVP reservations can be used for video flows from endpoints to RSVP reservations can be used for video flows from endpoints to
endpoints through the network. endpoints through the network.
In some environments, the network administrator can reliably ensure In some environments, the network administrator can reliably ensure
that router alert packets from any untrusted device (e.g., from that router alert packets from any untrusted device (e.g., from
external routers) are prevented from entering a trusted area (e.g., external routers) are prevented from entering a trusted area (e.g.,
the internal routers). For example, this might be achieved by the internal routers). For example, this might be achieved by
ensuring that routers straddling the trust boundary (e.g., edge ensuring that routers straddling the trust boundary (e.g., edge
routers) always encapsulate those packets (without setting IP Router routers) always encapsulate those packets (without setting IP Router
Alert -or equivalent- in the encapsulating header) through the Alert -or equivalent- in the encapsulating header) through the
trusted area (as discussed in [RFC6178]). In such environments, the trusted area (as discussed in [RFC6178]). In such environments, the
risks of DoS attacks through the IP Router Alert vector is removed in 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 the trusted area (or greatly reduced) even if IP Router Alert is used
inside the trusted area (say for RSVP-TE). Thus an application inside the trusted area (say for RSVP-TE). Thus an application
relying on IP Router Alert MAY be safely deployed within the trusted relying on IP Router Alert can be safely deployed within the trusted
area. A Service Provider running RSVP-TE within his network might be area. A Service Provider running RSVP-TE within his network might be
an example of such protected environment. Such an environment is an example of such protected environment. Such an environment is
illustrated in Figure 3. illustrated in Figure 3.
-------- -------------------------- -------- -------- -------------------------- --------
/ A \ / B \ / C \ / A \ / B \ / C \
| | | (*) (*) | | | | | | (*) (*) | | |
| |-------TT | |<=============>| | TT------- | | | |-------TT | |<=============>| | TT------- | |
| | | - - | | | | | | - - | | |
\ / \ / \ / \ / \ / \ /
skipping to change at page 13, line 31 skipping to change at page 13, line 31
(*) closer examination of Router Alert Option datagrams (*) closer examination of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams <==> flow of Router Alert Option datagrams
TT Tunneling of Router Alert Option datagrams TT Tunneling of Router Alert Option datagrams
Figure 4: Use of Router Alert In Water-tight Overlay Figure 4: Use of Router Alert In Water-tight Overlay
In the controlled environment described above, an application relying In the controlled environment described above, an application relying
on exchange and handling of RAO packets (e.g. RSVP-TE) in the on exchange and handling of RAO packets (e.g. RSVP-TE) in the
service provider network B (but not in network A) MAY also be safely service provider network B (but not in network A) can also be safely
deployed simultaneously. Such an environment with independent, deployed simultaneously. Such an environment with independent,
isolated, deployment of router alert in overlay at two levels is isolated, deployment of router alert in overlay at two levels is
illustrated in Figure 5. illustrated in Figure 5.
-------- -------- -------- --------
/ A \ / A \ / A \ / A \
| (*) | | (*) | | (*) | | (*) |
| | |<=====================================>| | | | | |<=====================================>| | |
| - | | - | | - | | - |
\ / \ / \ / \ /
skipping to change at page 14, line 46 skipping to change at page 14, line 46
using mechanisms such as (possibly per port) RAO rate limiting and using mechanisms such as (possibly per port) RAO rate limiting and
filtering filtering
o the service provider network B protects its core routers from o the service provider network B protects its core routers from
Router Alert messages without dropping those when they transit Router Alert messages without dropping those when they transit
over the transit network (for example using mechanisms discussed over the transit network (for example using mechanisms discussed
in [RFC6178]) in [RFC6178])
In such controlled environment, an application relying on exchange In such controlled environment, an application relying on exchange
and handling of RAO packets (e.g., RSVP) in the network A sites and and handling of RAO packets (e.g., RSVP) in the network A sites and
in network B Edges (but not in the core of network B) MAY be safely in network B Edges (but not in the core of network B) can be safely
deployed. We refer to such a deployment as a use of Router Alert in deployed. We refer to such a deployment as a use of Router Alert in
a Leak-Controlled Overlay. "Overlay" because Router Alert Option a Leak-Controlled Overlay. "Overlay" because Router Alert Option
datagrams are used in network A on top of, and completely datagrams are used in network A on top of, and completely
transparently to, network B core. "Leak-Controlled" because router transparently to, network B core. "Leak-Controlled" because router
alert option datagrams from A leak inside network B's B edges but not alert option datagrams from A leak inside network B's B edges but not
inside network B's core. A private enterprise intranet, whose sites inside network B's core. A private enterprise intranet, whose sites
are interconnected through a Service Prover network, using RSVP for are interconnected through a Service Prover network, using RSVP for
voice and video within network A sites as well as on Network B's edge voice and video within network A sites as well as on Network B's edge
to extend the reservation onto the attachment links between A and B to extend the reservation onto the attachment links between A and B
(as specified in [RFC6016]) might be an example of such controlled (as specified in [RFC6016]) might be an example of such controlled
skipping to change at page 15, line 36 skipping to change at page 15, line 36
<==> flow of Router Alert Option datagrams <==> flow of Router Alert Option datagrams
TT Tunneling of Router Alert Option datagrams TT Tunneling of Router Alert Option datagrams
Figure 6: Use of Router Alert In Leak-Controlled Overlay Figure 6: Use of Router Alert In Leak-Controlled Overlay
4.3. Router Alert Protection Approaches for Service Providers 4.3. Router Alert Protection Approaches for Service Providers
Section 3 discusses the security risks associated with the use of the Section 3 discusses the security risks associated with the use of the
IP Router Alert and how it opens up a DoS vector in the router IP Router Alert and how it opens up a DoS vector in the router
control plane. Thus, it is RECOMMENDED that a Service Provider control plane. Thus, a Service Provider MUST implement strong
implements strong protection of his network against attacks based on protection of his network against attacks based on IP Router Alert.
IP Router Alert.
As discussed in Section 4.2.2 some applications can benefit from the As discussed in Section 4.2.2 some applications can benefit from the
use of IP Router Alert packets in an Overlay model (i.e. Where use of IP Router Alert packets in an Overlay model (i.e. Where
Router Alert packets are exchanged transparently on top of a Service Router Alert packets are exchanged transparently on top of a Service
Provider). Thus, it is RECOMMENDED that a Service Provider protects Provider). Thus, a Service Provider MUST protect his network from
his network from attacks based on IP Router Alert using mechanisms attacks based on IP Router Alert. In doing so, the Service Provider
that avoid (or at least minimize) dropping of end to end IP Router SHOULD use mechanisms that avoid (or at least minimize) dropping of
Alert packets (other than those involved in an attack). end to end IP Router Alert packets (other than those involved in an
attack).
For example, if the Service Provider does not run any protocol For example, if the Service Provider does not run any protocol
depending on IP Router Alert within his network, he might elect to depending on IP Router Alert within his network, he might elect to
simply turn-off punting/processing of IP Router Alert packet on his simply turn-off punting/processing of IP Router Alert packet on his
routers; this will ensure that end-to-end IP Router Alert packet routers; this will ensure that end-to-end IP Router Alert packet
transit transparently and safely through his network. transit transparently and safely through his network.
As another example, using protection mechanisms such selective As another example, using protection mechanisms such selective
filtering and rate-limiting (that Section 5 suggests be supported by filtering and rate-limiting (that Section 5 suggests be supported by
IP Router Alert implementations) a Service Provider can protect the IP Router Alert implementations) a Service Provider can protect the
skipping to change at page 16, line 37 skipping to change at page 16, line 37
(e.g., IPv4/IPv6 RSVP). We observe that while tunneling of Router (e.g., IPv4/IPv6 RSVP). We observe that while tunneling of Router
Alert Option datagrams over an MPLS backbone as discussed in Alert Option datagrams over an MPLS backbone as discussed in
[RFC6178] is well understood, tunneling Router Alert Option datagrams [RFC6178] is well understood, tunneling Router Alert Option datagrams
over an non-MPLS IP backbone presents a number of issues (and in over an non-MPLS IP backbone presents a number of issues (and in
particular for determining where to forward the encapsulated particular for determining where to forward the encapsulated
datagram) and is not common practice at the time of writing this datagram) and is not common practice at the time of writing this
document. document.
As a last resort, if the SP does not have any means to safely As a last resort, if the SP does not have any means to safely
transport end to end IP Router Alert Option packets over his network, transport end to end IP Router Alert Option packets over his network,
the SP MAY drop those packets. It must be noted that this has the the SP can drop those packets. It must be noted that this has the
undesirable consequence of preventing the use of the Router Alert undesirable consequence of preventing the use of the Router Alert
Option in the Overlay Model on top of this network, and therefore Option in the Overlay Model on top of this network, and therefore
prevents users of that network from deploying a number of valid prevents users of that network from deploying a number of valid
applications/protocols in their environment. applications/protocols in their environment.
5. Guidelines for Router Alert Implementation 5. Guidelines for Router Alert Implementation
It is RECOMMENDED that router implementations of IP Router Alert A router implementation of IP Router Alert Option SHOULD include
Option include protection mechanisms against Router Alert based DoS protection mechanisms against Router Alert based DoS attacks
attacks appropriate for their targeted deployment environments. For appropriate for their targeted deployment environments. For example,
example, this can include ability on an edge router to "tunnel" IP this can include ability on an edge router to "tunnel" IP Router
Router Alert Option of received packets when forwarding those over Alert Option of received packets when forwarding those over the core
the core as discussed in [RFC6178]. As another example, although not as discussed in [RFC6178]. As another example, although not always
always available from current implementations, new implementations available from current implementations, new implementations MAY
MAY include protection mechanisms such as selective (possibly include protection mechanisms such as selective (possibly dynamic)
dynamic) filtering and rate-limiting of IP Router Alert Option filtering and rate-limiting of IP Router Alert Option packets.
packets.
In particular, it is RECOMMENDED that router implementations of IP In particular, router implementations of IP Router Alert Option
Router Alert Option offer the configuration option simply to ignore SHOULD offer the configuration option simply to ignore the presence
the presence of "IP Router Alert" in IPv4 and IPv6 packets. As of "IP Router Alert" in IPv4 and IPv6 packets. As discussed in
discussed in Section 4.3, that permits IP Router Alert packets to Section 4.3, that permits IP Router Alert packets to transit a
transit a network segment without presenting an adverse operational network segment without presenting an adverse operational security
security risk to that particular network segment, provided the risk to that particular network segment, provided the operator of
operator of that network segment does not ever use the IP Router that network segment does not ever use the IP Router Alert messages
Alert messages for any purpose. for any purpose.
If an IP packet contains the IP Router Alert Option, but the next If an IP packet contains the IP Router Alert Option, but the next
level protocol is not explicitly identified as a protocol of interest level protocol is not explicitly identified as a protocol of interest
by the router examining the packet, the behavior is not explicitly by the router examining the packet, the behavior is not explicitly
defined by [RFC2113]. However, the behavior is implied and, for defined by [RFC2113]. However, the behavior is implied and, for
example, the definition of RSVP in [RFC2205] assumes that the packet example, the definition of RSVP in [RFC2205] assumes that the packet
will be forwarded using normal forwarding based on the destination IP will be forwarded using normal forwarding based on the destination IP
address. Thus, a router implementation SHOULD forward within the address. Thus, a router implementation SHOULD forward within the
"fast path" (subject to all normal policies and forwarding rules) a "fast path" (subject to all normal policies and forwarding rules) a
packet carrying the IP Router Alert Option containing a next level packet carrying the IP Router Alert Option containing a next level
skipping to change at page 18, line 8 skipping to change at page 18, line 8
"the fast path" (subject to all normal policies and forwarding rules) "the fast path" (subject to all normal policies and forwarding rules)
or punting of a packet with the IP Router Alert Option, based on the or punting of a packet with the IP Router Alert Option, based on the
Value field of the Router Alert Option. This would allow router Value field of the Router Alert Option. This would allow router
protection against DoS attacks using IP Router Alert packets with protection against DoS attacks using IP Router Alert packets with
value that is not relevant for that router (e.g. Nesting levels of value that is not relevant for that router (e.g. Nesting levels of
Aggregated RSVP Reservation [RFC5350]). Aggregated RSVP Reservation [RFC5350]).
6. Security Considerations 6. Security Considerations
This document discusses security risks associated with current usage This document discusses security risks associated with current usage
of the IP Router Alert Option and associated practices. of the IP Router Alert Option and associated practices. This
document expands the security considerations of [RFC2113] and
[RFC2711], which defined the RAO, to discuss security risks
associated with current usage of the IP Router Alert Option and
associated practices. See [RFC4081] for additional security
considerations.
7. IANA Considerations 7. IANA Considerations
None. None.
8. Contributors 8. Contributors
The contributors to this document (in addition to the editors) are: The contributors to this document (in addition to the editors) are:
o Reshad Rahman: o Reshad Rahman:
 End of changes. 14 change blocks. 
36 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/