draft-ietf-intarea-router-alert-considerations-08.txt   draft-ietf-intarea-router-alert-considerations-09.txt 
Network Working Group F. Le Faucheur, Ed. Network Working Group F. Le Faucheur, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: BCP August 2, 2011 Intended status: BCP August 2, 2011
Expires: February 3, 2012 Expires: February 3, 2012
IP Router Alert Considerations and Usage IP Router Alert Considerations and Usage
draft-ietf-intarea-router-alert-considerations-08 draft-ietf-intarea-router-alert-considerations-09
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 15, line 42 skipping to change at page 15, line 42
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, a Service Provider MUST implement strong control plane. Thus, a Service Provider MUST implement strong
protection of his network against attacks based on IP Router Alert. protection of his network against attacks based on 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, a Service Provider MUST protect his network from Provider). Thus, a Service Provider protecting his network from
attacks based on IP Router Alert. In doing so, the Service Provider attacks based on IP Router Alert SHOULD use mechanisms that avoid (or
SHOULD use mechanisms that avoid (or at least minimize) dropping of at least minimize) dropping of end to end IP Router Alert packets
end to end IP Router Alert packets (other than those involved in an (other than those involved in an attack).
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
 End of changes. 2 change blocks. 
6 lines changed or deleted 5 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/