RFC 6411
Applicability of Keying Methods for RSVP Security
Applicability of Keying Methods for RSVP Security 🎀
okay so the title block is giving "RFC 6411, Informational, October 2011" 💅 It's by M. Behringer, F. Le Faucheur, and B. Weis from Cisco Systems, published by the IETF as an Informational doc (ISSN: 2070-1721). It doesn't list anything it obsoletes or updates, so it's just doing its own thing 🦋
Abstract ✨
okay so RSVP (Resource ReSerVation Protocol) lets neighbors do hop-by-hop integrity protection on each other. To make that work, messages have to be cryptographically protected with a shared secret between the participating nodes 🔐 This doc compares group keying for RSVP with per-neighbor or per-interface keying, talks about how those keys get provisioned, and covers where each approach fits and where it falls short 🧩 It also looks at whether encrypting RSVP messages is a good move 🫶
Status of This Memo ✨
This doc is not an Internet Standards Track spec. It's published just for info 📚
This doc is a product of the Internet Engineering Task Force (IETF) 🌸 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for the deets 💖
Want the current status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc6411 🍓
Copyright Notice ✨
Copyright (c) 2011 IETF Trust and the persons identified 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 stand on the date this doc was published. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc 📜 Code Components pulled from this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🔥
Table of Contents 🧚
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 4
3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5
3.1. Per-Interface and Per-Neighbor Keys . . . . . . . . . . . 5
3.2. Group Keys . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 8
4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 8
4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Per-Neighbor and Per-Interface Key Negotiation . . . . 8
4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8
5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9
5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9
5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9
6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10
6.1. General Considerations Using IPsec . . . . . . . . . . . . 10
6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11
6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11
6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12
6.5. Applicability of Tunnel Mode with Address Preservation . . 12
7. End-Host Considerations . . . . . . . . . . . . . . . . . . . 13
8. Applicability to Other Architectures and Protocols . . . . . . 14
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Informative References . . . . . . . . . . . . . . . . . . . . 161. Introduction and Problem Statement 🦋
okay so RSVP [RFC2205] allows hop-by-hop authentication of RSVP neighbors, as specified in [RFC2747] 💅 In this mode, an integrity object gets attached to each RSVP message to carry a keyed message digest 🔑 That digest lets the receiver verify who sent the message and check that the message wasn't tampered with. Since a sequence number is included in what the digest covers, it also gives you replay protection 🛡️
[RFC2747] doesn't dictate how the key for the integrity operation is derived 🤷♀️ Right now, most RSVP implementations use a statically configured key, set per interface or per neighbor. The problem is that manually configuring a key for every router pair across a whole network is operationally hard, especially when keys need to change on a regular basis 😭 So a lot of RSVP users just use the same key across their entire RSVP network and change it rarely, if ever, because of the operational burden 💀 Still, keys sometimes have to change because of network operational requirements (for example, when operational staff changes) 🙈
This doc walks through a bunch of keying methods and how well they fit different RSVP deployment environments, for both message integrity and encryption ✨ It's meant as a comparison guide so you can see where each RSVP keying method works best and what limits each one 🌈 It also looks at how RSVP hop-by-hop authentication is affected when non-RSVP nodes, or subverted nodes, show up in the reservation path 👑
"RSVP Security Properties" ([RFC4230]) gives an overview of RSVP security, including RSVP Cryptographic Authentication [RFC2747], but it doesn't discuss key management. It says that "RFC 2205 assumes that security associations are already available". This doc focuses specifically on key management with different key types, including group keys, so it complements [RFC4230] 🧚
1.1. Terminology 📚
A security domain, in this doc, is two or more nodes that share a common RSVP security policy 🫶
When this doc mentions a key, it means a symmetric key. A symmetric key best meets the operational requirements of RSVP deployments, and it's the only type of key that's currently explicitly supported for protecting RSVP messages 🔐
2. The RSVP Hop-by-Hop Trust Model 💖
Lots of protocol security mechanisms in networks require and use per-peer authentication. Each hop authenticates messages from its neighbor with a shared key or a certificate 🎀 RSVP uses this same model. Trust here is transitive. Each RSVP node explicitly trusts only its RSVP next-hop peers, through the message digest in the INTEGRITY object. The next-hop RSVP speaker then trusts its own peers, and so on 🧶 For more background, check out "RSVP Security Properties" [RFC4230] 📖
The keys used to protect RSVP messages can be group keys, for example, distributed via the Group Domain of Interpretation (GDOI) [RFC6407], as discussed in [GDOI-MAC]. When a group key is used, the authentication granularity becomes group membership of devices, not (individual) peer authentication between devices 👯♀️
The trust an RSVP node has in another RSVP node within a common security domain has an explicit part and an implicit part 🌸 Explicitly, the node trusts the other node to keep RSVP messages intact (or confidential, depending on whether authentication, encryption, or both are used). That only means the message hasn't been altered or seen by a non-trusted node 👀 Implicitly, each node trusts the other node to maintain the level of protection specified within that security domain. In any group-keying scheme like GDOI, a node trusts all the other members of the group, because authentication is now based on group membership, as noted above 🫶
RSVP can work even when there's a non-RSVP router on the path from sender to receiver ✨ The non-RSVP hop ignores the RSVP message and just passes it along, and then the next RSVP node can process it. For RSVP authentication or encryption to work in this case, the key used to compute the RSVP message digest has to be shared by the two RSVP neighbors, even if they aren't IP neighbors 🧩 With non-RSVP hops in the mix, an RSVP node always knows the next IP hop before forwarding an RSVP message, but it doesn't always know the RSVP next hop 🤔 Part of the Path message's whole job is to discover the RSVP next hop (and to re-discover it dynamically when it changes, for example, because of a routing change) 🗺️ So non-RSVP hops affect how RSVP authentication or encryption operates, and they can influence which keying approach you pick 💅
Figure 1 shows this. R2 here doesn't participate in RSVP; the other nodes do. In this case, R2 passes any RSVP messages along unchanged and ignores them 🍓
----R3---
/ \
sender----R1---R2(*) R4----receiver
\ /
----R5---
(*) Non-RSVP hop
Figure 1: A Non-RSVP Node in the PathThis creates a challenge for RSVP authentication and encryption 😭 With a non-RSVP hop in the path, an RSVP router doesn't know the RSVP next hop for some RSVP messages, like a PATH message, at the time it forwards them. In Figure 1, for example, R1 knows the next IP hop for a Path message addressed to the receiver is R2, but it doesn't necessarily know whether the RSVP next hop is R3 or R5. So per-interface and per-neighbor keys can't easily be used when there are non-RSVP routers on the path between senders and receivers 🙈
Section 4.3 of [RFC2747] says that "... the receiver MAY initiate an integrity handshake with the sender". If that handshake happens, it can be used to figure out the identity of the next RSVP hop. In that case, non-RSVP hops can also be traversed using per-interface or per-neighbor keys 🔑
Group keying naturally works even with non-RSVP routers 🌈 Looking back at Figure 1, with group keying, R1 would use the group key to protect a Path message addressed to the receiver and forward it to R2. Since R2 is a non-RSVP node, it ignores the Path message and forwards it to R3 or R5, depending on the current shortest path as determined by routing. Either way, the RSVP router that receives the Path message can authenticate it successfully using the group key ✨
3. Applicability of Key Types for RSVP 🧚♀️
3.1. Per-Interface and Per-Neighbor Keys ✨
okay so most current RSVP auth setups support per-interface keys 💅 When the interface is point-to-point, meaning an RSVP router has only one RSVP neighbor on each interface, this works just like per-neighbor keys, since every neighbor gets its own key 🫶 In that point-to-point case, the security domain is simply between the router and its neighbor.
BUT, when the interface is multipoint, every RSVP speaker on that subnet has to be in the same security domain and share the same key in this model. Lowkey, that makes it a bad fit for places where nodes from different security domains sit on the same subnet, like Internet exchange points 🙈 In those cases, per-neighbor keys are required, and the security domain is between the router and its neighbor 👑
With per-neighbor keys, each RSVP key is bound to an interface plus a neighbor on that interface 🦋 That means one interface and one subnet can have different security domains living side by side. Iconic.
Per-interface and per-neighbor keys can both be used inside a single security domain ✨
These key types can also be used between security domains, since they're tied to a specific interface or neighbor 💜
Both monotonically increasing sequence numbers (like the INTEGRITY object's simple sequence numbers [RFC2747], or the Encapsulating Security Payload (ESP) and Authentication Header (AH) anti-replay sequence numbers [RFC4301]) and time-based anti-replay methods (like the INTEGRITY sequence numbers based on a clock [RFC2747]) can be used with per-neighbor and per-interface keys 🌸
Like we talked about in the last section, per-neighbor and per-interface keys can not be used when there are non-RSVP hops in the path 💀
3.2. Group Keys 🧚
With group keys, all the members of a group of RSVP nodes share the same key 🍓 So a node uses the same key no matter which RSVP hop is going to process the message next (as long as that hop is in the group sharing that key). It also means a node uses the same key on the receiving side as on the sending side when it's exchanging RSVP messages within the group. Main character energy for keys that just vibe together 🌈
Group keys fit intra-domain RSVP auth really naturally, since all RSVP nodes are in the same security domain and implicitly trust each other 🫶 The nodes also extend trust to a group key server (GKS), which manages group membership and hands out the group keys. Here's how that looks, Figure 2:
......GKS1.............
: : : : :
: : : : :
source--R1--R2--R3-----destination
| |
|<-----domain 1----------------->|
Figure 2: A Group Key Server within a Single Security DomainA single group key can't normally cover multiple security domains, because by definition the domains don't trust each other 😭 They wouldn't be willing to trust the same group key server. For one group key to work across several security domains, you'd need a single group key server that both sides trust. That's theoretically possible, but in practice it's unlikely that one entity is trusted by both domains. Figure 3 shows this setup:
...............GKS1....................
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
Figure 3: A Single Group Key Server across Security DomainsA more practical way to run RSVP across security domains is to use a separate group key server for each security domain, and then use per-interface or per-neighbor keys between the two domains. Those two domains together make a third security domain 🎀 Figure 4 shows this setup:
....GKS1...... ....GKS2.........
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
|<-->|
domain 3
Figure 4: A Group Key Server per Security DomainAs we covered in Section 2, group keying can be used in the presence of non-RSVP hops ✨
Because a group key may be used to verify messages from different peers, monotonically increasing sequence number methods are not appropriate 🙅♀️ Time-based anti-replay methods (like the INTEGRITY sequence numbers based on a clock [RFC2747]) can be used with group keys 💖
4. Key Provisioning Methods for RSVP 🎀
4.1. Static Key Provisioning 🌸
Static keys are preconfigured, either by hand or through a network management system. Honestly, this is the simplest way to do RSVP authentication 💅 Static keying can be used with per-interface keys, per-neighbor keys, or group keys.
Provisioning static keys means either an operator manually touching every node, or a network management system doing that same job for them 😩 Time synchronization of static key provisioning and changes is critical, so you don't end up with inconsistent keys inside a security domain ⏰
So static key provisioning isn't really an ideal model for a big network 🙈
That said, the number of interconnection points where RSVP is allowed to transit between two domains is often pretty small and well controlled 🦋 Also, the different domains may not be in a position to use an infrastructure trusted by both sides to update keys on both sides. So statically provisioned keys may be applicable to inter-domain RSVP authentication 🫶
Since you can't change a key at the exact same moment on every communicating RSVP node, there needs to be a grace period where an RSVP node accepts both the old and the new key 🧚 Otherwise, RSVP operation would get interrupted 😭 (Dynamic keying approaches can have a grace period with two valid keys too, but the grace period in manual keying tends to be a lot longer than with dynamic key rollover schemes 💜)
4.2. Dynamic Keying ✨
4.2.1. Per-Neighbor and Per-Interface Key Negotiation 🔥
To avoid the hassle of manual key provisioning and updates in static key deployments, key negotiation between RSVP neighbors could be used to derive either per-interface or per-neighbor keys 🤝
4.2.2. Dynamic Group Key Distribution 🌈
With this approach, group keys get dynamically distributed among a set of RSVP routers. For example, [GDOI-MAC] describes a mechanism for distributing group keys to a group of RSVP speakers using GDOI [RFC6407] 🍓 Here, each RSVP node requests a group key from a key server as part of an encrypted and integrity-protected key agreement protocol. Once the key server has authenticated and authorized the RSVP nodes, it hands a group key to each group member. The authentication in this model can be based on public key mechanisms, which means you avoid needing static key provisioning altogether 👑
5. Specific Cases Supporting Use of Group Keying 💖
5.1. RSVP Notify Messages 📣
[RFC3473] introduces the Notify message and lets these messages be sent in a non-hop-by-hop fashion. As the Security Considerations section of [RFC3473] discusses, this can interfere with RSVP's hop-by-hop integrity and authentication model 😬 [RFC3473] describes how standard IPsec-based integrity and authentication can be used to protect Notify messages 🔐
Group keying may allow regular RSVP authentication [RFC2747] to protect non-hop-by-hop Notify messages ✨ For example, RSVP Notify messages that are commonly used for traffic engineering in MPLS networks are non-hop-by-hop messages. These can be sent from an ingress node straight to an egress node. In that case, group keying avoids setting up node-to-node keying when node-to-node keying isn't otherwise being used 🧚
5.2. RSVP-TE and GMPLS 🦋
Using RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast Reroute [RFC4090] deserves some extra thought 🤓
With the facility backup method of Fast Reroute, a backup tunnel runs from the Point of Local Repair (PLR) to the Merge Point (MP). It protects Label Switched Paths (protected LSPs) against the failure of a facility, like a router, that sits between the PLR and the MP 🛟 When that facility fails, the PLR redirects a protected LSP into the backup tunnel. As a result, the PLR and MP need to exchange RSVP control messages with each other, for example to maintain the protected LSP 💅 Some of those messages go over the backup tunnel (like a Path message from PLR to MP), while others are sent directly to the RSVP node (like a Resv message from MP to PLR). During the rerouted period, the PLR and MP effectively become RSVP neighbors, even though they may not be directly connected and so don't act as RSVP neighbors when nothing has failed 🌸 The Security Considerations section of [RFC4090] raises this point, saying: "Note that the facility backup method requires that a PLR and its selected merge point trust RSVP messages received from each other". Environments like this may benefit from group keying 🫶 A group key can be used among a set of routers enabled for Fast Reroute, so the PLR and MP can authenticate each other's messages without needing keys configured in advance for every possible PLR and MP pair, or an activated key update mechanism 🔥
Where RSVP-TE or RSVP-TE Fast Reroute runs across AS boundaries (see [RFC4216]), the considerations in Sections 3.1 and 3.2 above apply. So per-interface or per-neighbor keys can be used between two RSVP neighbors in different ASes, no matter what keying method the RSVP router uses to talk to RSVP routers in its own AS 👑
[RFC4875] specifies protocol extensions for Point-to-Multipoint (P2MP) RSVP-TE. RSVP message integrity mechanisms for hop-by-hop RSVP signaling apply to hop-by-hop P2MP RSVP-TE signaling (see the Security Considerations in [RFC4875]) 🌈
[RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop signaling. Since it reuses LSP Hierarchy procedures for some of its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling 🧚 Both LSP Hierarchy and P2MP RSVP-TE rely on the security mechanisms defined in [RFC3473] and [RFC4206] for non-hop-by-hop RSVP-TE signaling. Group keying can simplify protecting non-hop-by-hop signaling for LSP Hierarchy and P2MP RSVP-TE 💖
6. Applicability of IPsec for RSVP ✨
6.1. General Considerations Using IPsec ✨
okay so everything we talked about with keying in this doc? It's ALSO totally applicable when you're using IPsec [RFC4301] to protect RSVP 🔐. Section 1.2 of [RFC2747] says IPsec is not an optimal choice to protect RSVP 🙈. The big reason is that an IPsec security association (SA) and an RSVP SA are not based on the same parameters. ngl though, IPsec can still be used to protect RSVP 💅. The Security Policy Database (SPD) traffic selectors for related RSVP flows will not be constant. Sometimes the source and destination addresses are end hosts, and sometimes they're RSVP routers. So traffic selectors in the SPD are expected to specify ANY for the source address and destination addresses, and to specify IP protocol 46 (RSVP) 🎀.
"The Multicast Group Security Architecture" [RFC3740] defines in detail a "Group Security Association" (GSA) 🫶. That definition works here too and allows the use of IPsec for RSVP. The existing GDOI specification [RFC6407] manages group security associations, which IPsec can use. An example GDOI policy would be to encrypt or authenticate all packets of the RSVP protocol itself (IP protocol 46). So a router implementing GDOI and the AH and/or ESP protocols is able to implement this policy, which is iconic 👑.
Because the traffic selectors for an SA cannot be predicted, SA lookup is expected to use only the Security Parameters Index (SPI) (or SPI plus protocol) 🧚.
6.2. Comparing AH and the INTEGRITY Object 🦋
The INTEGRITY object defined by [RFC2747] provides integrity protection for RSVP also in a group-keying context, as we discussed above. AH [RFC4302] is an alternative method to provide integrity protection for RSVP packets 💜.
The RSVP INTEGRITY object protects the entire RSVP message, but it does not protect the IP header of the packet nor the IP options (in IPv4) or extension headers (in IPv6) 🙈.
AH tunnel mode (transport mode is not applicable; see Section 6.4) protects the entire original IP packet. That includes the IP header of the original IP packet ("inner header"), IP options or extension headers, plus the entire RSVP packet 🔥. It also protects the immutable fields of the outer header. Main character energy 👑.
So the difference between the two schemes in terms of covered fields is whether the IPv4 header and IP options, or the IPv6 header and extension headers, of the original IP packet are protected (as is the case with AH) or not (as is the case with the INTEGRITY object). AH also covers the immutable fields of the outer header 🌸.
As described in the next section, IPsec tunnel mode cannot be applied for RSVP traffic in the presence of non-RSVP nodes. Therefore, the security associations in both cases, AH and INTEGRITY object, are between the same RSVP neighbors. From a keying point of view, both approaches are comparable 🫶.
6.3. Applicability of Tunnel Mode 🌈
IPsec tunnel mode encapsulates the original packet, prepending a new IP header plus an ESP or AH sub-header. The entire original packet plus the ESP/AH sub-header is secured. However, with ESP, the new outer IP header is not cryptographically secured in this process 💀.
Protecting RSVP packets with IPsec tunnel mode works with any of the keying methods described above (per-interface, per-neighbor, or group keying), as long as there are no non-RSVP nodes on the path (however, see the group-keying considerations below) ✨. For RSVP messages to be visible and considered at each hop, such a tunnel would not cross routers. Instead, each RSVP node would establish a tunnel with each of its peers, effectively leading to link protection 🍓.
In the presence of a non-RSVP hop, tunnel mode cannot be applied, because a router upstream from a non-RSVP hop does not know the next RSVP hop, and thus cannot apply the correct tunnel header. The same situation applies to a host attached to the network by a non-RSVP-enabled first hop. This is independent of the key type used 😭.
Using group keying with ESP tunnel mode, where a security gateway places a peer security gateway address as the destination of the ESP packet, has consequences. In particular, if a man-in-the-middle attacker redirects the ESP-protected reservation to a different security gateway, the receiving security gateway cannot detect that the destination address was changed. However, it has received and will act upon an RSVP reservation that will be routed along an unintended path. RSVP routers encountering the RSVP packet path will not be aware that this is an unintended path, so they will act upon it. The resulting RSVP state along both the intended path and the unintended path will be incorrect. Therefore, using group keying with ESP tunnel mode is not recommended, unless address preservation is used (see Section 6.5) 🚨.
Heads up bestie: a man-in-the-middle can redirect an ESP-protected reservation without the receiving gateway noticing, so the RSVP state on both paths ends up wrong. Address preservation (Section 6.5) is the way out of this one 🙏.
6.4. Non-Applicability of Transport Mode 🙅♀️
IPsec transport mode, as defined in [RFC4303], is not suitable for securing RSVP Path messages, since those messages preserve the original source and destination 🧚. [RFC4301] states explicitly that "the use of transport mode by an intermediate system (e.g., a security gateway) is permitted only when applied to packets whose source address (for outbound packets) or destination address (for inbound packets) is an address belonging to the intermediate system itself". This would not be the case for RSVP Path messages, so transport mode is a no-go 💅.
6.5. Applicability of Tunnel Mode with Address Preservation 🦋
When the identity of the next-hop RSVP peer is not known, it is not possible to use a tunnel-endpoint destination address in the tunnel mode outer IP header. Section 3.1 of "Multicast Extensions to the Security Architecture for the Internet Protocol" [RFC5374] defines a new tunnel mode: tunnel mode with address preservation 🌸. This mode copies the destination and, optionally, the source address from the inner header to the outer header. Therefore, the encapsulated packet will have the same destination address as the original packet, and it will normally be subject to the same routing decisions. While [RFC5374] focuses on multicast environments, tunnel mode with address preservation can also be used to protect unicast traffic in conjunction with group keying. In this tunnel mode, the RSVP speakers act as security gateways, because they maintain the original end-system addresses of the RSVP packets in the tunnel mode outer IP header. This addressing scheme is used by RSVP to ensure that the packets continue along the routed path toward the destination end host 🛣️.
Tunnel mode with address preservation, in conjunction with group keying, allows the use of AH or ESP for protection of RSVP even in cases where non-RSVP nodes have to be traversed. This is because it allows routing of the IPsec-protected packet through the non-RSVP nodes in the same way as if it were not IPsec protected 🫶.
When used with group keying, tunnel mode with address preservation can be used to mitigate redirection attacks, where a man-in-the-middle modifies the destination of the outer IP header of the tunnel mode packet. The inbound processing rules for tunnel mode with address preservation (Section 5.2 of [RFC5374]) require that the receiver verify that the addresses in the outer IP header and the inner IP header are consistent. Therefore, the attack can be detected, and RSVP reservations will not proceed along an unintended path. Iconic defense 👑✨.
7. End-Host Considerations 💖
Unless RSVP Proxy entities [RFC5945] are used, RSVP signaling is controlled by end systems and not routers 🖥️. As discussed in [RFC4230], RSVP allows both user-based security and host-based security. User-based authentication aims at "providing policy based admission control mechanism based on user identities or application" [RFC3182]. To identify the user or the application, a policy element called AUTH_DATA, which is contained in the POLICY_DATA object, is created by the RSVP daemon at the user's host and transmitted inside the RSVP message. This way, a user may authenticate to the Policy Decision Point (or directly to the first-hop router) 🔑.
Host-based security relies on the same mechanisms as between routers (i.e., the INTEGRITY object) as specified in [RFC2747]. For host-based security, per-interface or per-neighbor keys may be used. However, key management with statically provisioned keys can be difficult in a large-scale deployment, as described in Section 4 😩.
In principle, an end host can also be part of a group key scheme, such as GDOI. If the end systems are part of the same security domain as the RSVP hops in the network, group keying can be extended to include the end systems 🌈. If the end systems and the network are in different zones of trust, group keying cannot be used 🚫.
8. Applicability to Other Architectures and Protocols 🧚♀️
While so far this document only discusses RSVP security assuming the traditional RSVP model as defined by [RFC2205] and [RFC2747], the analysis also applies to other RSVP deployment models, as well as to similar protocols. These include the following 💅:
- "Aggregation of RSVP for IPv4 and IPv6 Reservations" [RFC3175]: This scheme defines aggregation of individual RSVP reservations, and discusses use of RSVP authentication for the signaling messages. Group keying is applicable to this scheme, particularly when automatic Deaggregator discovery is used, since in that case, the Aggregator does not know ahead of time which Deaggregator will intercept the initial end-to-end RSVP Path message 🦋.
- "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations" [RFC4860]: This document also discusses aggregation of individual RSVP reservations. Here again, group keying applies and is mentioned in the Security Considerations section 🌸.
- "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels" [RFC4804]: This scheme also defines a form of aggregation of RSVP reservations, but this time over MPLS-TE tunnels. Similarly, group keying may be used in such an environment 💜.
- "Pre-Congestion Notification (PCN) Architecture" [RFC5559]: This defines an architecture for flow admission and termination based on aggregated pre-congestion information. One deployment model for this architecture is based on Intserv over Diffserv, where the Diffserv region is PCN-enabled. Also, RSVP signaling is used end-to-end, but the PCN-domain is a single RSVP hop, i.e., only the PCN-boundary-nodes process RSVP messages. In this scenario, RSVP authentication may be required among PCN-boundary-nodes, and the considerations about keying approaches discussed earlier in this document apply. In particular, group keying may facilitate operations, since the ingress PCN-boundary-node does not necessarily know ahead of time which PCN-egress-node will intercept and process the initial end-to-end Path message. From the viewpoint of securing end-to-end RSVP in this scenario (from the end host to the PCN-ingress-node, to the PCN-egress-node, to the other end host), there are a lot of similarities in scenarios involving RSVP Aggregation over aggregate RSVP reservations [RFC3175] [RFC4860], RSVP Aggregation over MPLS-TE tunnels [RFC4804], and RSVP (Aggregation) over PCN ingress-egress aggregates 🌟.
9. Summary ✨
Okay bestie, here's the big recap 💅 This table sums up every RSVP keying approach and where each one actually works. Keying can be used for RSVP authentication (like the RSVP INTEGRITY object or AH) and/or RSVP encryption (like ESP in tunnel mode) 🔐
+----------------------------+-----------------+--------------------+
| | per-neighbor / | group keys |
| | per-interface | |
| | keys | |
+----------------------------+-----------------+--------------------+
| Works intra-domain | Yes | Yes |
| Works inter-domain | Yes | No |
| Works over non-RSVP hops | No | Yes (1) |
| Dynamic keying | Yes (IKE) | Yes (e.g., GDOI) |
+----------------------------+-----------------+--------------------+
Table 1: Overview of Keying Approaches and Their ApplicabilityNow the footnote 🙈 RSVP integrity with group keys works over non-RSVP nodes. RSVP encryption with ESP and RSVP authentication with AH work over non-RSVP nodes in tunnel mode with address preservation. But RSVP encryption with ESP and RSVP authentication with AH do not work over non-RSVP nodes in tunnel mode.
We also have a few observations to vibe with:
- All key types can be used statically, or with dynamic key negotiation. This affects how manageable the solution is, but not its applicability itself 🧚
- For encryption of RSVP messages, IPsec ESP in tunnel mode can be used 🔒
- There are some special cases in RSVP that would totally benefit from a group-keying approach 👑: non-RSVP hosts, the Notify message (see Section 5.1), the various RSVP deployment models (see Section 8), and MPLS Traffic Engineering and GMPLS (see Section 5.2).
10. Security Considerations 🚨
Okay, serious moment incoming 😭 This entire document is about RSVP security. This section zooms in on the specific security problems caused by subverted RSVP nodes, and these are a big deal.
10.1. Subverted Nodes
An undetected subverted node is one an intruder has taken control of, and it's still implicitly trusted. That's the scary part 💀 It's still a real threat to RSVP's security. RSVP authentication is hop by hop, not end to end, so one subverted node in the path breaks the whole chain of trust. And honestly, this is mostly true no matter what kind of keying you're using 🥀
With per-interface or per-neighbor keying, a subverted node can start sending fake messages to its neighbors 🙃 It can do this in a bunch of ways, like changing the receiver address in a Path message or generating fake Path messages out of nowhere. That lets it create path states on every RSVP router along any arbitrary path through the RSVP domain. Which, yikes, could lead to a denial of service by using up router resources (like memory) 🫠 The subverted node can also generate fake Resv messages going upstream that match valid Path states. By doing that, it can reserve excessive amounts of bandwidth, which could be another denial-of-service attack 💔
Group keying adds one more nasty trick: a subverted node can send fake RSVP messages to any node in the RSVP domain, not just its adjacent RSVP nodes 👀 BUT, and this is a big but 🫶, you can get a lot of this same abuse with per-neighbor or per-interface keys too, as we just covered. So the impact of a subverted node on the path is comparable across all the keying schemes discussed here: per-interface, per-neighbor, and group keys alike 💅
11. Acknowledgements 🎀
The authors want to thank everybody who gave feedback on this document 💖 Shoutout especially to Bob Briscoe, Hannes Tschofenig, Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg. Iconic behavior from all of them 👑
12. Informative References 📚
Here's the reading list, bestie 🤓
- [GDOI-MAC] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress, September 2011.
- [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
- [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
- [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
- [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 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.
- [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
- [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
- [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
- [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
- [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
- [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", RFC 4804, February 2007.
- [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.
- [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
- [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
- [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
- [RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, "Resource Reservation Protocol (RSVP) Proxy Approaches", RFC 5945, October 2010.
- [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.
Authors' Addresses 💌
Michael H. Behringer
Cisco Systems
Village d'Entreprises Green Side
400, Avenue Roumanille, Batiment T 3
Biot - Sophia Antipolis 06410
France
EMail: mbehring@cisco.com
URI: http://www.cisco.com
Francois Le Faucheur
Cisco Systems
Village d'Entreprises Green Side
400, Avenue Roumanille, Batiment T 3
Biot - Sophia Antipolis 06410
France
EMail: flefauch@cisco.com
URI: http://www.cisco.com
Brian Weis
Cisco Systems
170 W. Tasman Drive
San Jose, California 95134-1706
USA
EMail: bew@cisco.com
URI: http://www.cisco.com📦 where this page comes from
- ietf: rfc6411 2011-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms