draft-ietf-intarea-router-alert-considerations-04.txt   draft-ietf-intarea-router-alert-considerations-05.txt 
Network Working Group F. Le Faucheur, Ed. Network Working Group F. Le Faucheur, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: BCP June 7, 2011 Intended status: BCP June 27, 2011
Expires: December 9, 2011 Expires: December 29, 2011
IP Router Alert Considerations and Usage IP Router Alert Considerations and Usage
draft-ietf-intarea-router-alert-considerations-04 draft-ietf-intarea-router-alert-considerations-05
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.
PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use Resource reSerVation Protocol (RSVP), Pragmatic General Multicast
of the IP Router Alert option. This document discusses security (PGM), Internet Group Management Protocol (IGMP), Multicast Listener
aspects and usage guidelines around the use of the current IP Router Discovery (MLD), Multicast Router Discovery (MRD) and General
Alert option. Specifically, it provides recommendation against using Internet Signalling Transport (GIST) are some of the protocols that
the Router Alert in the end-to-end open Internet as well as identify make use of the IP Router Alert option. This document discusses
controlled environments where protocols depending on Router Alert can security aspects and usage guidelines around the use of the current
be used safely. It also provides recommendation about protection IP Router Alert option. Specifically, it provides recommendation
approaches for Service Providers. Finally it provides brief against using the Router Alert in the end-to-end open Internet as
guidelines for Router Alert implementation on routers. well as identify controlled environments where protocols depending on
Router Alert can be used safely. It also provides recommendation
about protection approaches for Service Providers. Finally it
provides brief guidelines for Router Alert implementation on routers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). 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 December 9, 2011. This Internet-Draft will expire on December 29, 2011.
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 4, line 13 skipping to change at page 4, line 13
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
[RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router
Alert Option (RAO). In this document, we collectively refer to those Alert Option (RAO). In this document, we collectively refer to those
as the IP Router Alert. The IP Router Alert Option is an IP option as the IP Router Alert. The IP Router Alert Option is an IP option
that alerts transit routers to more closely examine the contents of that alerts transit routers to more closely examine the contents of
an IP packet. an IP packet.
RSVP ([RFC2205], [RFC3175], [RFC3209]), PGM ([RFC3208]), IGMP Resource reSerVation Protocol (RSVP) ([RFC2205], [RFC3175],
([RFC3376]), MLD ([RFC2710], [RFC3810]), MRD ([RFC4286]) and NSIS [RFC3209]), Pragmatic General Multicast (PGM) ([RFC3208]), Internet
General Internet Signalling Transport (GIST) ([RFC5971]) are some of Group Management Protocol (IGMP) ([RFC3376]), Multicast Listener
the protocols that make use of the IP Router Alert. Discovery (MLD) ([RFC2710], [RFC3810]), Multicast Router Discovery
(MRD) ([RFC4286]) and NSIS General Internet Signalling Transport
(GIST) ([RFC5971]) are some of the protocols that make use of the IP
Router Alert.
Section 3 describes the security concerns associated with the use of Section 3 describes the security concerns associated with the use of
the Router Alert option. the Router Alert option.
Section 4 provides guidelines for the use of Router Alert. More Section 4 provides guidelines for the use of Router Alert. More
specifically, Section 4.1 recommends that Router Alert not be used specifically, Section 4.1 recommends that Router Alert not be used
for end to end applications over the Internet, while Section 4.2 for end to end applications over the Internet, while Section 4.2
presents controlled environments where applications/protocols relying presents controlled environments where applications/protocols relying
on IP Router Alert can be deployed effectively and safely. on IP Router Alert can be deployed effectively and safely.
Section 4.3 provides recommendations on protection approaches to be Section 4.3 provides recommendations on protection approaches to be
used by Service Providers in order to protect their network from used by Service Providers in order to protect their network from
Router Alert based attacks. Router Alert based attacks.
Finally, Section 5 provides generic recommendations for router Finally, Section 5 provides generic recommendations for router
implementation of Router Alert aiming at increasing protection implementation of Router Alert aiming at increasing protection
against attacks. against attacks.
The present document discusses considerations and practises based on The present document discusses considerations and practices based on
the current specification of IP Router Alert ([RFC2113], [RFC2711]). the current specification of IP Router Alert ([RFC2113], [RFC2711]).
Possible future enhancements to the specification of IP Router Alert Possible future enhancements to the specification of IP Router Alert
(in view of reducing the security risks associated with the use of IP (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 Router Alert) are outside the scope of this document. One such
such enhancements can be found in proposal is discussed in [I-D.narayanan-rtg-router-alert-extension]
[I-D.narayanan-rtg-router-alert-extension]. but at the time of this writing, the IETF has not adopted any
extensions for this purpose.
The IPv6 base specification [RFC2460] defines the hop-by-hop option The IPv6 base specification [RFC2460] defines the hop-by-hop option
extension header. The hop-by-hop option header is used to carry extension header. The hop-by-hop option header is used to carry
optional information that must be examined by every node along a optional information that must be examined by every node along a
packet's delivery path. The IPv6 Router Alert Option is one packet's delivery path. The IPv6 Router Alert Option is one
particular hop by hop option. Similar security concerns to those particular hop by hop option. Similar security concerns to those
discussed in the present document for the IPv6 Router Alert apply discussed in the present document for the IPv6 Router Alert apply
more generically to the concept of IPv6 hop-by-hop option extension more generically to the concept of IPv6 hop-by-hop option extension
header. However, addressing the broader concept of IPv6 hop-by-hop header. However, addressing the broader concept of IPv6 hop-by-hop
option thoroughly would require additional material so as to cover option thoroughly would require additional material so as to cover
skipping to change at page 5, line 15 skipping to change at page 5, line 19
kept outside the scope of the present document. A detailed kept outside the scope of the present document. A detailed
discussion about security risks and proposed remedies associated with discussion about security risks and proposed remedies associated with
IPv6 hop-by-hop option can be found in [I-D.krishnan-ipv6-hopbyhop]. IPv6 hop-by-hop option can be found in [I-D.krishnan-ipv6-hopbyhop].
The IPv4 base specification [RFC0791] defines a general notion of The IPv4 base specification [RFC0791] defines a general notion of
IPv4 options that can be included in the IPv4 header (without IPv4 options that can be included in the IPv4 header (without
distinguishing between hop-by-hop versus end-to-end option). The distinguishing between hop-by-hop versus end-to-end option). The
IPv4 Router Alert Option is one particular IPv4 option. Similar IPv4 Router Alert Option is one particular IPv4 option. Similar
security concerns to those discussed in the present document for the security concerns to those discussed in the present document for the
IPv4 Router Alert apply more generically to the concept of IPv4 IPv4 Router Alert apply more generically to the concept of IPv4
option. However, addressing the broader concept of IPv4 option option. However, addressing the security concerns of the broader
thoroughly would require additional material so as to cover concept of IPv4 option thoroughly is kept outside the scope of the
additional considerations associated with it (such as lack of option present document because it would require additional material so as
ordering, etc.), so this is kept outside the scope of the present to cover additional considerations associated with it (such as lack
document. of option ordering, etc.), and because other IPv4 options are often
blocked in firewalls and not very widely used, so the practical risks
they present are largely non-existent.
3. Security Concerns of Router Alert 3. Security Concerns of Router Alert
The IP Router Alert option is defined ([RFC2113], [RFC2711]) as a The IP Router Alert option is defined ([RFC2113], [RFC2711]) as a
mechanism that alerts transit routers to more closely examine the mechanism that alerts transit routers to more closely examine the
contents of an IP packet. [RFC4081] and [RFC2711] mention the contents of an IP packet. [RFC4081] and [RFC2711] mention the
security risks associated with the use of the IP Router Alert: security risks associated with the use of the IP Router Alert:
flooding a router with bogus (or simply undesired) IP datagrams which flooding a router with bogus (or simply undesired) IP datagrams which
contain the IP Router Alert could impact operation of the router in contain the IP Router Alert could impact operation of the router in
undesirable ways. For example, assuming the router punts the undesirable ways. For example, assuming the router punts the
skipping to change at page 6, line 45 skipping to change at page 6, line 45
levels of RSVP aggregation [RFC3175]). Thus, it is not possible to levels of RSVP aggregation [RFC3175]). Thus, it is not possible to
achieve the necessary triage in the fast path across IP Router Alert achieve the necessary triage in the fast path across IP Router Alert
packets from different applications or from different contexts of an packets from different applications or from different contexts of an
application. Secondly, some protocols requiring punting may be application. Secondly, some protocols requiring punting may be
carried over a transport protocol (e.g., TCP or UDP) possibly because carried over a transport protocol (e.g., TCP or UDP) possibly because
they require the services of that transport protocol, possibly they require the services of that transport protocol, possibly
because the protocol does not justify allocation of a scarce next because the protocol does not justify allocation of a scarce next
level protocol value or possibly because not relying on a very widely level protocol value or possibly because not relying on a very widely
deployed transport protocol is likely to result in deployment issues deployed transport protocol is likely to result in deployment issues
due to common middlebox behaviors (e.g. Firewalls or NATs discarding due to common middlebox behaviors (e.g. Firewalls or NATs discarding
packets of "unkown" protocols). Thus, considering the next level packets of "unknown" protocols). Thus, considering the next level
protocol does not allow triage in the fast path of IP Router Alert protocol does not allow triage in the fast path of IP Router Alert
packets from different protocols sharing the same transport protocol. packets from different protocols sharing the same transport protocol.
Therefore, it is generally not possible to ensure that only the IP Therefore, it is generally not possible to ensure that only the IP
Router Alert packets for next level protocols of interest are punted Router Alert packets for next level protocols of interest are punted
to the slow path while other IP Router Alert packets are efficiently to the slow path while other IP Router Alert packets are efficiently
forwarded (i.e., in fast path). forwarded (i.e., in fast path).
Some IP Router Alert implementations may be able to take into account Some IP Router Alert implementations may be able to take into account
the value field inside the router alert option. However, only one the value field inside the router alert option. However, only one
value (zero) was defined in [RFC2113] and no IANA registry for IPv4 value (zero) was defined in [RFC2113] and no IANA registry for IPv4
skipping to change at page 7, line 43 skipping to change at page 7, line 43
the use of IP Router Alert. the use of IP Router Alert.
In a nutshell, the IP router alert option does not provide a In a nutshell, the IP router alert option does not provide a
convenient universal mechanism to accurately and reliably distinguish convenient universal mechanism to accurately and reliably distinguish
between IP Router Alert packets of interest and unwanted IP Router between IP Router Alert packets of interest and unwanted IP Router
Alert packets. This, in turn, creates a security concern when IP Alert packets. This, in turn, creates a security concern when IP
Router Alert option is used, because, short of appropriate router Router Alert option is used, because, short of appropriate router
implementation specific mechanisms, the router slow path is at risk implementation specific mechanisms, the router slow path is at risk
of being flooded by unwanted traffic. of being flooded by unwanted traffic.
It can be observed that opening up a hole in the control plane of Note that service providers commonly allow external parties to
Service Provider routers is commonly done for other applications, communicate with a control plane application in their routers, such
such as BGP peering. Depending on the actual environment and BGP as with BGP peering. Depending on the actual environment and BGP
security practises, the resulting DOS attack vector is similar, or security practices, the resulting DOS attack vector is similar, or
somewhat less serious, with BGP peering than with Router Alert option somewhat less serious, with BGP peering than with Router Alert option
for a number of reasons that include: for a number of reasons that include:
o With BGP, edge routers only exchange control plane information o With BGP, edge routers only exchange control plane information
with pre-identified peers and can easily filter out any control with pre-identified peers and can easily filter out any control
plane traffic coming from other peers or non-authenticated peers, plane traffic coming from other peers or non-authenticated peers,
while the Router-Alert option can be received in a datagram with while the Router-Alert option can be received in a datagram with
any source address and any destination source. However, we note any source address and any destination source. However, we note
that effectiveness of such BGP filtering is dependent on proper that effectiveness of such BGP filtering is dependent on proper
security practises; poor BGP security practices (such as security practices; poor BGP security practices (such as
infrequent or inexistent update of BGP peers authentication keys) infrequent or inexistent update of BGP peers authentication keys)
create vulnerabilities through which the BGP authentication create vulnerabilities through which the BGP authentication
mechanisms can be compromised. mechanisms can be compromised.
o with BGP Peering, the control plane hole is only open on the edge o with BGP Peering, the control plane hole is only open on the edge
routers, and core routers are completely isolated from any direct routers, and core routers are completely isolated from any direct
control plane exchange with entities outside the administrative control plane exchange with entities outside the administrative
domain. Thus, with BGP, a DOS attack would only affect the edge domain. Thus, with BGP, a DOS attack would only affect the edge
routers, while with Router Alert option, the attack could routers, while with Router Alert option, the attack could
propagate to core routers. However, in some BGP environments, the propagate to core routers. However, in some BGP environments, the
distinction between edge and core routers is not strict, and many/ distinction between edge and core routers is not strict, and many/
most/all routers act as both edge and core routers; in such BGP most/all routers act as both edge and core routers; in such BGP
environments, a large part of the network is exposed to direct environments, a large part of the network is exposed to direct
control plane exchanges with entities outside the administrative control plane exchanges with entities outside the administrative
domain (as it would be with Router Alert). domain (as it would be with Router Alert).
o with BGP, the BGP policy control would typically prevent re- o with BGP, the BGP policy control would typically prevent re-
injection of undesirable information out of the attacked device, injection of undesirable information out of the attacked device,
while with the Router-Alert option, the non-filtered attacking while with the Router-Alert option, the non-filtered attacking
messages would typically be forwarded downstream. However, we messages would typically be forwarded downstream. However, we
note that there has been real life occurences of situations where note that there has been real life occurrences of situations where
incorrect information was propagated through the BGP system, incorrect information was propagated through the BGP system,
causing quite widespread problems. causing quite widespread problems.
4. Guidelines for use of Router Alert 4. Guidelines for use of Router Alert
4.1. Use of Router Alert End-to-End In the Internet (Router Alert in 4.1. Use of Router Alert End-to-End In the Internet (Router Alert in
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 be achieved
achieved by tunneling IP Router Alert packets [RFC6178] so that the by tunneling IP Router Alert packets [RFC6178] so that the IP Router
IP Router Alert option is hidden through that network, or it may be Alert option is hidden through that network, or it may be achieved
achieved via mechanisms resulting in occasional (e.g., rate limiting) via mechanisms resulting in occasional (e.g., rate limiting) or
or systematic drop of IP Router Alert packets. systematic drop of 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
core routers in different administrative domains would partake in core routers in different administrative domains would partake in
processing of Router Alert option datagrams associated with the same processing of Router Alert option datagrams associated with the same
signalling flow. signalling flow.
skipping to change at page 16, line 29 skipping to change at page 16, line 29
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
[RFC6178] a Service Provider can safely protect the operation of a [RFC6178] a Service Provider can safely protect the operation of a
protocol depending on IP Router Alert within his network (e.g., protocol depending on IP Router Alert within his network (e.g.,
RSVP-TE) while at the same time safely transporting IP Router Alert 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., packets carrying another protocol that may be used end to end (e.g.,
IPv4/IPv6 RSVP). We observe that while tunneling of Router Alert IPv4/IPv6 RSVP). We observe that while tunneling of Router Alert
option datagrams over an MPLS backbone as discussed in [RFC6178] is option datagrams over an MPLS backbone as discussed in [RFC6178] is
well understood, tunnelling Router Alert option datagrams over an well understood, tunneling Router Alert option datagrams over an non-
non-MPLS IP backbone presents a number of issues (and in particular MPLS IP backbone presents a number of issues (and in particular for
for determining where to forward the encapsulated datagram) and is determining where to forward the encapsulated datagram) and is not
not common practise at the time of writing this document. common practice at the time of writing this 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 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
skipping to change at page 17, line 39 skipping to change at page 17, line 39
Router Alert packets of a protocol unknown to the router. The Router Alert packets of a protocol unknown to the router. The
"forwarding" behavior contributes to transparent end to end transport "forwarding" behavior contributes to transparent end to end transport
of IP Router Alert packets (e.g., to facilitate their use by end to of IP Router Alert packets (e.g., to facilitate their use by end to
end application). end application).
Similarly, an implementation MAY support selective forwarding within Similarly, an implementation MAY support selective forwarding within
"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.
7. IANA Considerations 7. IANA Considerations
None. None.
 End of changes. 15 change blocks. 
44 lines changed or deleted 53 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/