RFC 6398
IP Router Alert Considerations and Usage
RFC 6398: IP Router Alert Considerations and Usage 💖
okay bestie, so this is RFC 6398 🎀 and it's a Best Current Practice, which makes it BCP 168 👑. It came out in October 2011 from F. Le Faucheur, Ed. at Cisco 💅. It's an IETF document with ISSN 2070-1721 🦋, and it updates RFC 2113 and RFC 2711, so it's basically adding notes to those two 📝.
Abstract ✨
okay so the IP Router Alert Option is an IP option that tells transit routers to take a closer look at what's inside a packet 👀. Protocols like RSVP, PGM, IGMP, MLD, MRD, and GIST all use it 🔥. This doc covers the security side of the current Router Alert option and how to use it, and it updates RFC 2113 and RFC 2711 🧚.
the big takeaway is that it's not a vibe for end-to-end stuff on the open Internet 🙅♀️. There are controlled environments where the protocols that rely on it can run safely 💜. It also has recommendations on protection approaches for service providers, plus brief guidelines for implementing Router Alert on routers 🛡️.
Status of This Memo 📜
this memo documents an Internet Best Current Practice 🌸.
this doc is a product of the IETF. it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶. More info on BCPs is in Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6398 🔗.
Copyright Notice ©
Copyright (c) 2011 IETF Trust and the people listed as the document authors. All rights reserved 🔒.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read them carefully, because they spell out your rights and restrictions for this doc 📖. Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 💜.
Table of Contents 🧾
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Conventions Used in This Document ..........................4
3. Security Concerns of Router Alert ...............................5
4. Guidelines for Use of Router Alert ..............................7
4.1. Use of Router Alert End to End in the Internet
(Router Alert in Peer Model) ...............................7
4.2. Use of Router Alert in Controlled Environments .............9
4.2.1. Use of Router Alert within an Administrative
Domain ..............................................9
4.2.2. Use of Router Alert in Overlay Model ...............11
4.3. Router Alert Protection Approaches for Service Providers ..13
5. Guidelines for Router Alert Implementation .....................15
6. Security Considerations ........................................16
7. Contributors ...................................................16
8. Acknowledgments ................................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................171. Introduction 🦋
okay so [RFC2113] and [RFC2711] define the IPv4 and IPv6 Router Alert Options (RAOs), respectively 🧚. We're just gonna call them all "the IP Router Alert" for short. The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet 👀.
some of the protocols that use the IP Router Alert are:
- Resource reSerVation Protocol (RSVP) ([RFC2205], [RFC3175], [RFC3209])
- Pragmatic General Multicast (PGM) ([RFC3208])
- Internet Group Management Protocol (IGMP) ([RFC3376])
- Multicast Listener Discovery (MLD) ([RFC2710], [RFC3810])
- Multicast Router Discovery (MRD) ([RFC4286])
- Next Steps in Signaling (NSIS) General Internet Signaling Transport (GIST) ([RFC5971])
Section 3 is all about the security concerns with using the Router Alert Option 🔐.
Section 4 is the guidelines section 💅. Section 4.1 recommends that Router Alert not be used for end-to-end applications over the Internet, while Section 4.2 shows the controlled environments where apps and protocols that rely on IP Router Alert can be deployed effectively and safely ✨. Section 4.3 gives recommendations on protection approaches that service providers can use to shield their network from Router-Alert-based attacks 🛡️.
finally, Section 5 has generic recommendations for router implementation of Router Alert, aimed at boosting protection against attacks 🧱.
this doc discusses considerations and practices based on the current specifications of IP Router Alert ([RFC2113], [RFC2711]). Possible future enhancements to those specs (aimed at cutting the security risks of IP Router Alert) are outside the scope of this doc 🚫. One such proposal is discussed in [RAO-EXT], but at the time of writing, the IETF hasn't adopted any extensions for this purpose 🙃.
the IPv6 base spec [RFC2460] defines the hop-by-hop options extension header 📦. The hop-by-hop options header carries optional information that must be examined by every node along a packet's delivery path. The IPv6 Router Alert Option is one particular hop-by-hop option. The security concerns discussed here for the IPv6 Router Alert apply more generally to the concept of the IPv6 hop-by-hop options extension header too 🌀. Addressing that broader concept thoroughly would need extra material covering things like how the effectiveness of an attack could depend on how many options are included and on the range the option-type value belongs to, so that's kept outside the scope of this doc 🙈. A detailed discussion of the security risks and proposed remedies for the IPv6 hop-by-hop option is in [IPv6-HOPBYHOP] 📚.
the IPv4 base spec [RFC0791] defines a general notion of IPv4 options that can go in the IPv4 header, without distinguishing between hop-by-hop and end-to-end options 🧩. The IPv4 Router Alert Option is one particular IPv4 option. Security concerns similar to the ones discussed here for the IPv4 Router Alert apply more generally to the concept of the IPv4 option. But fully covering the broader IPv4 option concept would need extra material for things like the lack of option ordering, so it's kept outside the scope of this doc 🙅♀️. Also, other IPv4 options are often blocked in firewalls and aren't very widely used, so the practical risks they present are largely nonexistent 😌.
2. Terminology 📚
for readability, this doc uses the following loosely defined terms 🧠:
- Fast path: Hardware or Application-Specific Integrated Circuit (ASIC) processing path for packets. This is the nominal processing path within a router for IP datagrams.
- Slow path: Software processing path for packets. This is a sub-nominal processing path for packets that require special processing or differ from assumptions made in fast-path heuristics.
- Next level protocol: The protocol transported in the IP datagram. In IPv4 [RFC0791], the next level protocol is identified by the IANA protocol number conveyed in the 8-bit "Protocol" field in the IPv4 header. In IPv6 [RFC2460], the next level protocol is identified by the IANA protocol number conveyed in the 8-bit "Next Header" field in the IPv6 header.
2.1. Conventions Used in This Document 🌈
okay, the big ones: 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] 💜.
3. Security Concerns of Router Alert ✨
okay bestie, this is the spicy part 🔥 The IP Router Alert Option is defined in [RFC2113] and [RFC2711] as a way to tell transit routers "hey, look closer at this packet" 👀. [RFC4081] and [RFC2711] both flag the security risk: if somebody floods a router with bogus (or just unwanted) IP datagrams carrying the Router Alert, it can mess with the router in not-cute ways 💀. If the router punts those packets to the slow path, the attack can eat a big chunk of the slow path and even make the slow path drop packets. That hurts every other app and protocol running there too, which is a denial of service (DoS) ([RFC4732]). 😭
Now, [RFC2113] specifies no mechanism for telling different users of IP Router Alert apart, and [RFC2711] specifies a very limited one 🙃 So a lot of fast switching implementations punt most or all packets marked with IP Router Alert to the slow path, unless the router is configured to systematically ignore or drop all Router Alert packets. Some deployed IP routers can and do process packets containing the Router Alert Option in the fast path, though 🦋
Some IP Router Alert implementations can use the next level protocol as a discriminator for the punting decision, so different protocols using IP Router Alert get treated differently. But that still only allows very coarse triage 💅 There are two reasons. First, the next level protocol is the same when IP Router Alert is used for different applications of the same protocol (for example, RSVP vs. RSVP - Traffic Engineering (RSVP-TE)), or when it's used for different contexts of the same application (for example, different levels of RSVP aggregation [RFC3175]). So it's not always possible to get the triage you need in the fast path across IP Router Alert packets from different applications or different contexts of an application 🥲 Second, some protocols that need punting might be carried over a transport protocol (such as TCP or UDP). That could be because (1) they need the services of that transport protocol, (2) the protocol doesn't justify using up a scarce next level protocol value, or (3) not relying on a very widely deployed transport protocol is likely to cause deployment issues, since common middlebox behaviors like firewalls or NATs discard packets of "unknown" protocols 🧱 So looking at the next level protocol alone in the fast path isn't enough to triage IP Router Alert packets from different protocols that share the same transport protocol. Therefore, it's generally not possible to make sure that only the IP Router Alert packets for next level protocols of interest get punted to the slow path while everything else is efficiently forwarded (that is, in the fast path) 💔
Some IP Router Alert implementations can take the Value field inside the Router Alert Option into account. But only one value (zero) was defined in [RFC2113], and there was no IANA registry for IPv4 Router Alert values until recently ([RFC5350]) 🙄 So most IPv4 Router Alert implementations couldn't do useful classification based on the Value field in the fast path. [RFC2113] says unknown values should be ignored (meaning the packets should be forwarded as normal IP traffic), but it's been reported that some existing implementations just ignore the Value field completely, so they process any packet with an IPv4 Router Alert no matter what its option value is 😳 There's now an IANA registry for further allocation of IPv4 Router Alert values ([RFC5350]), but it would only allow coarse-grain classification, and only if implementations support it. For IPv6, [RFC2711] states that "the Value field can be used by an implementation to speed processing of the datagram within the transit router" and defines an IANA registry for these values. Again, though, that only allows coarse-grain classification 🫠 Plus, some existing IPv6 Router Alert implementations are reported to depart from that behavior.
[RFC2711] mentions that limiting the use of the IP Router Alert Option, by rate or some other means, is a way to protect against a potential attack 🛡️ However, if rate limiting is the protection mechanism and its granularity isn't fine enough to tell IP Router Alert packets of interest apart from unwanted ones, an IP Router Alert attack could still badly degrade the protocols of interest that depend on IP Router Alert 😭
In a nutshell, the IP Router Alert Option doesn't give you a convenient universal way to accurately and reliably tell apart the IP Router Alert packets you want from the unwanted ones 🙈 That creates a security concern whenever the option is used. Short of appropriate router-implementation-specific mechanisms, the router slow path is at risk of being flooded by unwanted traffic.
Note that service providers commonly let external parties talk to a control plane application on their routers, such as with BGP peering 🌐 Depending on the actual environment and BGP security practices, the resulting DoS attack vector with BGP peering is similar to, or somewhat less serious than, the one with the Router Alert Option, for a few reasons:
- With BGP, edge routers only exchange control plane information with pre-identified peers, so they can easily filter out any control plane traffic coming from other peers or non-authenticated peers. The Router Alert Option, on the other hand, can be received in a datagram with any source address and any destination address. Still, the effectiveness of that BGP filtering depends on proper security practices 🔐 Poor BGP security practices (such as infrequent or nonexistent update of BGP peers' authentication keys) create vulnerabilities through which the BGP authentication mechanisms can be compromised.
- With BGP peering, the control plane hole is only open on the edge routers, and core routers are completely isolated from any direct control plane exchange with entities outside the administrative domain. So with BGP, a DoS attack would only affect the edge routers, while with the Router Alert Option, the attack could propagate to core routers 🌊 However, in some BGP environments the distinction between edge and core routers isn't strict, and many, most, or all routers act as both. In those environments, a large part of the network is exposed to direct control plane exchanges with entities outside the administrative domain (just as it would be with Router Alert).
- With BGP, the BGP policy control would typically prevent re-injection of undesirable information out of the attacked device. With the Router Alert Option, the non-filtered attacking messages would typically be forwarded downstream 📤 We do note that there have been real-life occurrences where incorrect information was propagated through the BGP system, causing widespread problems.
4. Guidelines for Use of Router Alert 💅
4.1. Use of Router Alert End to End in the Internet (Router Alert in Peer Model)
Because of the security concerns with Router Alert we just talked about in Section 3, network operators SHOULD actively protect themselves against externally generated IP Router Alert packets 🛡️ There are no convenient universal mechanisms to triage between desired and undesired Router Alert packets, so network operators often protect themselves by isolating themselves from externally generated IP Router Alert packets right now. This might be done by tunneling IP Router Alert packets [RFC6178] so the IP Router Alert Option is hidden through that network. Or it might be done with mechanisms that drop IP Router Alert packets occasionally (for example, with rate limiting) or systematically 🙅♀️
So, applications and protocols SHOULD NOT be deployed with a dependency on processing of the Router Alert Option (as it's currently specified) across independent administrative domains in the Internet 🚫 Figure 1 illustrates this hypothetical use of Router Alert end to end in the Internet. We call this the "Peer Model" Router Alert Option use, because core routers in different administrative domains would all take part in processing Router Alert Option datagrams for the same signaling flow 🦋
-------- -------- -------- --------
/ A \ / B \ / C \ / D \
| (*) | | (*) | | (*) | | (*) |
| | |<============>| |<=============>| |<=============>| | |
| - | | - | | - | | - |
\ / \ / \ / \ /
-------- -------- -------- --------
(*) closer examination of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
Figure 1: Use of Router Alert End to End in the Open Internet
(Router Alert in Peer Model)While this recommendation is framed specifically in the context of Router Alert, the fundamental security risk that network operators want to prevent is letting devices and protocols outside their administrative domain (and therefore not controlled by them) tap into the control plane of their core routers 🧁 Similar security concerns would probably come up whether that control plane access is provided through the Router Alert Option or by some other mechanism (for example, deep packet inspection). In other words, the fundamental security concern is tied to the idea of end-to-end signaling in a Peer Model across domains in the Internet 🌍 So operators would typically not want their core routers taking part in end-to-end signaling with external, uncontrolled devices over the open Internet. That means they'd prevent deploying end-to-end signaling in a Peer Model through their network, whether or not that signaling uses Router Alert 💜
4.2. Use of Router Alert in Controlled Environments
4.2.1. Use of Router Alert within an Administrative Domain ✨
okay so, in some controlled environments (like inside one administrative domain 🏰), the network admin can figure out that IP Router Alert packets will only ever come from trusted, well-behaved devices. Or they can show that certain protection mechanisms (like RAO filtering and rate limiting 🛡️) are strong enough against the plausible RAO-based DoS attacks. Either way, an application that relies on exchanging and handling RAO packets (RSVP, for example 📞) can be safely deployed inside that controlled network. A private enterprise network that's firewalled from the Internet and uses RSVP reservations for voice and video flows is a super example of this 💖. Here's what that looks like 👇
------------------------- -------- --------
/ A \ / B \ / C \
| (*) (*) | -- | | | |
| | |<============>| | |--|FW|--| |--------| |
| - - | -- | | | |
\ / \ / \ /
------------------------- -------- --------
(*) closer examination of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
FW: Firewall
Figure 2: Use of Router Alert within an Administrative Domain -
Private Enterprise Network Firewalled from the Internet
and Using RSVP ReservationsNow here's a twist 🦋. In some controlled environments, several administrative domains have a special relationship where they cooperate super tightly and basically act like a single trust domain 🤝. In that case, one domain is willing to trust another with respect to the traffic that gets injected across the boundary. So a downstream domain is willing to trust that traffic arriving at the boundary has already been properly validated and filtered by the upstream domain 🫶. Once it's been established that this trust can be applied to Router Alert Option packets, an application that relies on exchanging and handling RAO packets (RSVP again, iconic 💅) can be safely deployed inside that controlled environment. For example, the people in a company who run the multimedia endpoints and the people who run the network could team up so RSVP reservations work for video flows going from endpoint to endpoint across the network 🎀.
Next up, some environments where the network admin can reliably make sure that Router Alert packets from any untrusted device (like external routers 🚧) are kept from entering a trusted area (like the internal routers). One way to do this is to make sure the routers straddling the trust boundary (the edge routers, usually) always encapsulate those packets as they cross the trusted area. And the encapsulating header does NOT set IP Router Alert, or anything equivalent to it. This is discussed in [RFC6178] 📖. In environments like this, the risks of DoS attacks through the IP Router Alert vector are removed (or greatly reduced) inside the trusted area, even if IP Router Alert is still used there (say, for RSVP-TE 🧚). So an application that relies on IP Router Alert can be safely deployed within the trusted area 🌸. A service provider running RSVP-TE inside its own network is a great example of this protected environment. Here's how it looks 👇
-------- -------------------------- --------
/ A \ / B \ / C \
| | | (*) (*) | | |
| |-------TT | |<=============>| | TT------- | |
| | | - - | | |
\ / \ / \ /
-------- -------------------------- --------
(*) closer examination of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
TT: Tunneling of Router Alert Option datagrams
Figure 3: Use of Router Alert within an Administrative Domain -
Service Provider Running RSVP-TE within Its Network4.2.2. Use of Router Alert in Overlay Model 🌈
Okay, in some controlled environments:
- The sites of a network A are interconnected through a service provider network B.
- The service provider network B protects itself from IP Router Alert messages without dropping those messages when they transit over the network (for example, using mechanisms discussed in [RFC6178]).
In a setup like this, an application that relies on exchanging and handling RAO packets (RSVP 💜) can be safely deployed in the network A sites, but not inside network B. We call this a use of Router Alert in a Water-Tight Overlay. "Overlay" because the Router Alert Option datagrams are used in network A on top of network B, completely transparently to it 🫧. And "Water-Tight" because RAO datagrams from network A can't leak inside network B 💧. A private enterprise intranet built as a Virtual Private Network (VPN) over a service provider network, using RSVP to make reservations for voice and video within the enterprise sites, is a good example of this controlled environment 🎧. Here it is in Figure 4 👇
-------- --------
/ A \ / A \
| (*) | | (*) |
| | |<=====================================>| | |
| - | | - |
\ / \ /
-------- --------
\ /
\ ------------------------- /
\ / B \ /
\| |/
TT TT
| |
\ /
-------------------------
(*) closer examination of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
TT: Tunneling of Router Alert Option datagrams
Figure 4: Use of Router Alert in Water-Tight OverlayIn the controlled environment described above, an application that relies on exchanging and handling RAO packets (RSVP-TE 🧠) can also be safely deployed inside the service provider network B (but not in network A), and this can happen at the same time 🙌. This setup, with independent, isolated deployments of Router Alert in an overlay at two levels, is shown in Figure 5 👇
-------- --------
/ A \ / A \
| (*) | | (*) |
| | |<=====================================>| | |
| - | | - |
\ / \ /
-------- --------
\ /
\ ------------------------- /
\ / B \ /
\| (*) (*) |/
TT | |<============>| | TT
| - - |
\ /
-------------------------
(*) closer examination of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
TT: Tunneling of Router Alert Option datagrams
Figure 5: Use of Router Alert in Water-Tight Overlay at Two LevelsOkay, one more layered setup 🍓. In some controlled environments:
- The sites of a network A are interconnected through a service provider network B.
- The service provider B processes Router Alert packets on the edge routers and protects these edge routers against RAO-based attacks using mechanisms such as (possibly per port) RAO rate limiting and filtering.
- The service provider network B protects its core routers from Router Alert messages without dropping those messages when they transit over the network (for example, using mechanisms discussed in [RFC6178]).
In a controlled environment like this, an application that relies on exchanging and handling RAO packets (RSVP 💖) can be safely deployed in the network A sites and on network B's edges, but not in the core of network B. We call this a use of Router Alert in a Leak-Controlled Overlay. It's an "Overlay" because the Router Alert Option datagrams are used in network A on top of network B's core, completely transparently to it 🦋. And it's "Leak-Controlled" because RAO datagrams from network A leak inside network B's edges, but not inside network B's core 🚰. A private enterprise intranet whose sites are interconnected through a service provider network, using RSVP for voice and video within the network A sites, and also on network B's edge to extend the reservation onto the attachment links between networks A and B (as specified in [RFC6016]), is a good example of this controlled environment 💅. Here it is in Figure 6 👇
-------- --------
/ A \ / A \
| | | |
| | ------------------------ | |
| (*) | /(*) (*) \ | (*) |
| | |<======>| |<============>| |<=========>| | |
| - | | - - | | - |
\ / | \ - - / | \ /
-------- | TT-| | | |-TT | --------
| - - |
\ /
------------------------
(*) closer examination of Router Alert Option datagrams
<==> flow of Router Alert Option datagrams
TT: Tunneling of Router Alert Option datagrams
Figure 6: Use of Router Alert in Leak-Controlled Overlay4.3. Router Alert Protection Approaches for Service Providers ✨
okay so Section 3 is literally the scary part 😭 it explains how the IP Router Alert opens up a DoS vector in the router control plane. So a service provider MUST implement strong protection of its network against attacks based on IP Router Alert. no cap, this is non-negotiable 🛡️
As we covered in Section 4.2.2, some apps can totally benefit from IP Router Alert packets in an Overlay Model, where Router Alert packets get exchanged transparently on top of a service provider 🦋 So a service provider protecting its network from Router Alert attacks SHOULD use mechanisms that avoid (or at least minimize) dropping end-to-end IP Router Alert packets, except the ones that are part of an attack. we want the good ones to get through, bestie 💖
For example, if the service provider doesn't run any protocol that depends on IP Router Alert inside its network, it might just turn off punting/processing of IP Router Alert packets on its routers. Lowkey the simplest fix ever 🧚 This makes sure end-to-end IP Router Alert packets transit transparently and safely through the network ✨
Another example: using protection mechanisms like selective filtering and rate limiting (which Section 5 suggests IP Router Alert implementations support), a service provider can protect a protocol that depends on IP Router Alert inside its network (like RSVP-TE) while still carrying IP Router Alert packets for another protocol that might be used end to end 🎀 Also, the service provider might use protocol-specific mechanisms that reduce how much that protocol depends on Router Alert inside its environment. RSVP refresh reduction mechanisms ([RFC2961]) are an example of this when the service provider runs RSVP-TE in its network, because they let existing Path and Resv states get refreshed without using the IP Router Alert Option 🌸
And one more: using mechanisms like the ones in [RFC6178], a service provider can safely protect a protocol that depends on IP Router Alert inside its network (like RSVP-TE) while safely transporting IP Router Alert packets for another protocol that might be used end to end (like IPv4/IPv6 RSVP) 👑 Tunneling Router Alert Option datagrams over an MPLS backbone, as described in [RFC6178], is well understood. Tunneling them over a non-MPLS IP backbone, though, comes with a bunch of issues (especially figuring out where to forward the encapsulated datagram), and it's not common practice at the time of writing this document 🙈
As a last resort, if the service provider has no way to safely transport end-to-end IP Router Alert Option packets over its network, it can drop those packets. > it must be noted that this has the undesirable consequence of blocking the use of the Router Alert Option in the Overlay Model on top of that network. That means users of that network can't deploy a bunch of valid applications/protocols in their environment 💀
5. Guidelines for Router Alert Implementation 🎀
A router implementation of the IP Router Alert Option SHOULD include protection mechanisms against Router-Alert-based DoS attacks, as appropriate for the deployment environments they're targeting 🛡️ For example, an edge router being able to "tunnel" received IP Router Alert Option packets when forwarding them over the core (as in [RFC6178]) would count. And although it's not always available from current implementations, new implementations MAY include protection mechanisms like selective (possibly dynamic) filtering and rate limiting of IP Router Alert Option packets ✨
Router implementations of the IP Router Alert Option SHOULD also offer a configuration option to simply ignore the presence of "IP Router Alert" in IPv4 and IPv6 packets 🧚 As discussed in Section 4.3, this lets IP Router Alert packets transit a network segment without creating an adverse operational security risk for that segment, as long as the operator of that segment never uses the IP Router Alert messages for any purpose 🦋
Now here's the tea 🍵 If an IP packet contains the IP Router Alert Option, but the router examining it doesn't explicitly identify the next level protocol as a protocol of interest, the behavior isn't explicitly defined by [RFC2113]. But it's kinda implied. For example, the definition of RSVP in [RFC2205] assumes the packet gets forwarded using normal forwarding based on the destination IP address 💅 So a router implementation SHOULD forward within the "fast path" (subject to all normal policies and forwarding rules) a packet carrying the IP Router Alert Option whose next level protocol isn't a protocol of interest to that router 🚀 The "not punting" behavior protects the router from DoS attacks using IP Router Alert packets of a protocol it doesn't know. The "forwarding" behavior helps with transparent end-to-end transport of IP Router Alert packets, like when end-to-end applications want to use them 💖
Similarly, an implementation MAY support selective forwarding within 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 Value field of the Router Alert Option 🌈 This allows router protection against DoS attacks using IP Router Alert packets with a value that isn't relevant to that router, like nesting levels of aggregated RSVP reservations ([RFC5350]) 🫶
6. Security Considerations 🔥
This document expands the security considerations of [RFC2113] and [RFC2711], which define the IPv4 and IPv6 RAOs, respectively. It does that by discussing the security risks associated with the current IP Router Alert Option and the practices around it 😭 See [RFC4081] for additional security considerations. Please read those too, bestie. This stuff is serious 💀
7. Contributors 💜
The contributors to this document (in addition to the editor) are:
Reshad Rahman
Cisco Systems
rrahman@cisco.com
David Ward
Juniper Networks
dward@juniper.net
Ashok Narayanan
Cisco Systems
ashokn@cisco.com
Adrian Farrel
OldDog Consulting
adrian@olddog.co.uk
Tony Li
Cisco Systems
tony.li@tony.li8. Acknowledgments 🫶
The editor and contributors would like to thank Dave Oran, Magnus Westerlund, John Scudder, Ron Bonica, Ross Callon, Alfred Hines, Carlos Pignataro, Roland Bless, Jari Arkko, and Ran Atkinson for their comments 🌸 This document also benefited from discussions with Jukka Manner and Suresh Krishnan 🎀 The discussion about use of the Value field in the IPv4 Router Alert is borrowed from a similar discussion in [RFC5971] ✨
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the
IPv4 and IPv6 Router Alert Options", RFC 5350,
September 2008.9.2. Informative References
[IPv6-HOPBYHOP]
Krishnan, S., "The case against Hop-by-Hop options", Work
in Progress, October 2010.
[RAO-EXT] Narayanan, A., Le Faucheur, F., Ward, D., and R. Rahman,
"IP Router Alert Option Extension", Work in Progress,
March 2009.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[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.
[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., Ed., and L. Costa, Ed., "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.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732,
December 2006.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", RFC 5971, October 2010.
[RFC6016] Davie, B., Le Faucheur, F., and A. Narayanan, "Support for
the Resource Reservation Protocol (RSVP) in Layer 3 VPNs",
RFC 6016, October 2010.
[RFC6178] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl, "Label
Edge Router Forwarding of IPv4 Option Packets", RFC 6178,
March 2011.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📦 where this page comes from
- ietf: rfc6398 2011-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms