draft-ietf-intarea-router-alert-considerations-00.txt   draft-ietf-intarea-router-alert-considerations-01.txt 
Network Working Group F. Le Faucheur, Ed. Network Working Group F. Le Faucheur, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: BCP March 1, 2010 Intended status: BCP JUly 8, 2010
Expires: September 2, 2010 Expires: January 9, 2011
IP Router Alert Considerations and Usage IP Router Alert Considerations and Usage
draft-ietf-intarea-router-alert-considerations-00 draft-ietf-intarea-router-alert-considerations-01
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. RSVP, routers to more closely examine the contents of an IP packet. RSVP,
PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use
of the IP Router Alert option. This document discusses security of the IP Router Alert option. This document discusses security
aspects and usage guidelines around the use of the current IP Router aspects and usage guidelines around the use of the current IP Router
Alert option. Specifically, it provides recommendation against using Alert option. Specifically, it provides recommendation against using
the Router Alert in the end-to-end open Internet as well as identify the Router Alert in the end-to-end open Internet as well as identify
controlled environments where protocols depending on Router Alert can controlled environments where protocols depending on Router Alert can
be used safely. It also provides recommendation about protection be used safely. It also provides recommendation about protection
approaches for Service Providers. Finally it provides brief approaches for Service Providers. Finally it provides brief
guidelines for Router Alert implementation on routers. guidelines for Router Alert implementation on routers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 9, 2011.
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 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 9
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 10, line 18 skipping to change at page 10, line 18
Peer Model) Peer Model)
Because of the security concerns associated with Router Alert Because of the security concerns associated with Router Alert
discussed in Section 3, network operators need to actively protect discussed in Section 3, network operators need to actively protect
themselves against externally generated IP Router Alert packets. themselves against externally generated IP Router Alert packets.
Because there is no convenient universal mechanisms to triage between Because there is no convenient universal mechanisms to triage between
desired and undesired router alert packets, network operators desired and undesired router alert packets, network operators
currently often protect themselves in ways that isolate them from currently often protect themselves in ways that isolate them from
externally generated IP Router Alert packets. This may (ideally) be externally generated IP Router Alert packets. This may (ideally) be
achieved by tunneling IP Router Alert packets achieved by tunneling IP Router Alert packets
[I-D.dasmith-mpls-ip-options] so that the IP Router Alert option is [I-D.ietf-mpls-ip-options] so that the IP Router Alert option is
hidden through that network, or it may be achieved via mechanisms hidden through that network, or it may be achieved via mechanisms
resulting in occasional (e.g., rate limiting) or systematic drop of resulting in occasional (e.g., rate limiting) or systematic drop of
IP Router Alert packets. IP Router Alert packets.
Thus, it is RECOMMENDED that applications and protocols not be Thus, it is RECOMMENDED that applications and protocols not be
deployed with a dependency on processing of the Router Alert option deployed with a dependency on processing of the Router Alert option
(as currently specified) across independent administrative domains in (as currently specified) across independent administrative domains in
the Internet. Figure 1 illustrates such a hypothetical use of Router the Internet. Figure 1 illustrates such a hypothetical use of Router
Alert end-to-end in the Internet. We refer to such a model of Router Alert end-to-end in the Internet. We refer to such a model of Router
Alert option use as a "Peer Model" Router Alert option use, since Alert option use as a "Peer Model" Router Alert option use, since
skipping to change at page 12, line 27 skipping to change at page 12, line 27
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 may be achieved by ensuring the internal routers). For example, this may be achieved by ensuring
that routers straddling the trust boundary (e.g., edge routers) that routers straddling the trust boundary (e.g., edge routers)
always encapsulate those packets (without setting IP Router Alert -or always encapsulate those packets (without setting IP Router Alert -or
equivalent- in the encapsulating header) through the trusted area (as equivalent- in the encapsulating header) through the trusted area (as
discussed in [I-D.dasmith-mpls-ip-options]). In such environments, discussed in [I-D.ietf-mpls-ip-options]). In such environments, the
the risks of DOS attacks through the IP Router Alert vector is risks of DOS attacks through the IP Router Alert vector is removed in
removed in the trusted area (or greatly reduced) even if IP Router the trusted area (or greatly reduced) even if IP Router Alert is used
Alert is used inside the trusted area (say for RSVP-TE). Thus an inside the trusted area (say for RSVP-TE). Thus an application
application relying on IP Router Alert MAY be safely deployed within relying on IP Router Alert MAY be safely deployed within the trusted
the trusted area. A Service Provider running RSVP-TE within his area. A Service Provider running RSVP-TE within his network may be
network may be an example of such protected environment. Such an an example of such protected environment. Such an environment is
environment is illustrated in Figure 3. illustrated in Figure 3.
-------- -------------------------- -------- -------- -------------------------- --------
/ A \ / B \ / C \ / A \ / B \ / C \
| | | (*) (*) | | | | | | (*) (*) | | |
| |-------TT | |<=============>| | TT------- | | | |-------TT | |<=============>| | TT------- | |
| | | - - | | | | | | - - | | |
\ / \ / \ / \ / \ / \ /
-------- -------------------------- -------- -------- -------------------------- --------
(*) closer examination of Router Alert option datagrams (*) closer examination of Router Alert option datagrams
skipping to change at page 13, line 31 skipping to change at page 13, line 31
4.2.2. Use of Router Alert In Overlay Model 4.2.2. Use of Router Alert In Overlay Model
In some controlled environment: In some controlled environment:
o the sites of a network A are interconnected through a service o the sites of a network A are interconnected through a service
provider network B provider network B
o the service provider network B protects itself from IP Router o the service provider network B protects itself from IP Router
Alert messages without dropping those when they transit over the Alert messages without dropping those when they transit over the
transit network (for example using mechanisms discussed in transit network (for example using mechanisms discussed in
[I-D.dasmith-mpls-ip-options]) [I-D.ietf-mpls-ip-options])
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 (but and handling of RAO packets (e.g., RSVP) in the network A sites (but
not inside network B) MAY be safely deployed. We refer to such a not inside network B) MAY be safely deployed. We refer to such a
deployment as a use of Router Alert in a Water-Tight Overlay. deployment as a use of Router Alert in a Water-Tight Overlay.
"Overlay" because Router Alert option datagrams are used in network A "Overlay" because Router Alert option datagrams are used in network A
on top of, and completely transparently to, network B. "Water-Tight" on top of, and completely transparently to, network B. "Water-Tight"
because router alert option datagrams from A cannot leak inside because router alert option datagrams from A cannot leak inside
network B. A private enterprise intranet, whose sites are network B. A private enterprise intranet, whose sites are
interconnected through a Service Prover network, and using RSVP to interconnected through a Service Prover network, and using RSVP to
skipping to change at page 15, line 42 skipping to change at page 15, line 42
provider network B provider network B
o the service provider B processes router alert packets on the edge o the service provider B processes router alert packets on the edge
routers and protect these edge routers against RAO based attacks routers and protect these edge routers against RAO based attacks
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 [I-D.dasmith-mpls-ip-options]) in [I-D.ietf-mpls-ip-options])
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) MAY 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
skipping to change at page 17, line 24 skipping to change at page 17, line 24
Note that the Service Provider might additionally use protocol Note that the Service Provider might additionally use protocol
specific mechanisms that reduce the dependency on Router Alert for specific mechanisms that reduce the dependency on Router Alert for
operation of this protocol inside the Service Provider environment; operation of this protocol inside the Service Provider environment;
use of RSVP refresh reduction mechanisms ([RFC2961]) would be an use of RSVP refresh reduction mechanisms ([RFC2961]) would be an
example of such mechanisms in the case where the Service Provider is example of such mechanisms in the case where the Service Provider is
running RSVP-TE within his network since this allows refresh of running RSVP-TE within his network since this allows refresh of
existing Path and Resv states without use of the IP Router Alert existing Path and Resv states without use of the IP Router Alert
option. option.
As yet another example, using mechanisms such as those discussed in As yet another example, using mechanisms such as those discussed in
[I-D.dasmith-mpls-ip-options] a Service Provider can safely protect [I-D.ietf-mpls-ip-options] a Service Provider can safely protect the
the operation of a protocol depending on IP Router Alert within his operation of a protocol depending on IP Router Alert within his
network (e.g., RSVP-TE) while at the same time safely transporting IP network (e.g., RSVP-TE) while at the same time safely transporting IP
Router Alert packets carrying another protocol that may be used end Router Alert packets carrying another protocol that may be used end
to end (e.g., IPv4/IPv6 RSVP). to end (e.g., IPv4/IPv6 RSVP).
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 MAY 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 It is RECOMMENDED that router implementations of IP Router Alert
option include protection mechanisms against Router Alert based DOS option include protection mechanisms against Router Alert based DOS
attacks appropriate for their targeted deployment environments. For attacks appropriate for their targeted deployment environments. For
example, this can include ability on an edge router to "tunnel" IP example, this can include ability on an edge router to "tunnel" IP
Router Alert option of received packets when forwarding those over Router Alert option of received packets when forwarding those over
the core as discussed in [I-D.dasmith-mpls-ip-options]. As another the core as discussed in [I-D.ietf-mpls-ip-options]. As another
example, although not always available from current implementations, example, although not always available from current implementations,
new implementations may include protection mechanisms such as new implementations may include protection mechanisms such as
selective (possibly dynamic) filtering and rate-limiting of IP Router selective (possibly dynamic) filtering and rate-limiting of IP Router
Alert option packets. Alert option packets.
If an IP packet contains the IP Router Alert option, but the payload 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 protocol is not explicitly identified as a Payload of interest by the
router examining the packet, the behavior is not explicitly defined router examining the packet, the behavior is not explicitly defined
by [RFC2113]. However, the behavior is implied and, for example, the by [RFC2113]. However, the behavior is implied and, for example, the
definition of RSVP in [RFC2205] assumes that the packet will be definition of RSVP in [RFC2205] assumes that the packet will be
skipping to change at page 23, line 23 skipping to change at page 23, line 23
February 1997. February 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999. RFC 2711, October 1999.
10.2. Informative References 10.2. Informative References
[I-D.dasmith-mpls-ip-options] [I-D.ietf-mpls-ip-options]
Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, Jaeger, W., Mullooly, J., Scholl, T., and D. Smith,
"Requirements for Label Edge Router Forwarding of IPv4 "Requirements for Label Edge Router Forwarding of IPv4
Option Packets", draft-dasmith-mpls-ip-options-01 (work in Option Packets", draft-ietf-mpls-ip-options-04 (work in
progress), October 2008. progress), May 2010.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-tsvwg-rsvp-l3vpn] [I-D.ietf-tsvwg-rsvp-l3vpn]
Davie, B., Faucheur, F., and A. Narayanan, "Support for Davie, B., Faucheur, F., and A. Narayanan, "Support for
RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-05 RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-07
(work in progress), November 2009. (work in progress), June 2010.
[I-D.krishnan-ipv6-hopbyhop] [I-D.krishnan-ipv6-hopbyhop]
Krishnan, S., "The case against Hop-by-Hop options", Krishnan, S., "The case against Hop-by-Hop options",
draft-krishnan-ipv6-hopbyhop-03 (work in progress), draft-krishnan-ipv6-hopbyhop-04 (work in progress),
July 2009. March 2010.
[I-D.narayanan-rtg-router-alert-extension] [I-D.narayanan-rtg-router-alert-extension]
Narayanan, A., Faucheur, F., Ward, D., and R. Rahman, "IP Narayanan, A., Faucheur, F., Ward, D., and R. Rahman, "IP
Router Alert Option Extension", Router Alert Option Extension",
draft-narayanan-rtg-router-alert-extension-00 (work in draft-narayanan-rtg-router-alert-extension-00 (work in
progress), March 2009. progress), March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 17 change blocks. 
36 lines changed or deleted 31 lines changed or added

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