RFC 4923
Quality of Service (QoS) Signaling in a Nested Virtual Private Network
Quality of Service (QoS) Signaling in a Nested Virtual Private Network 🎀
RFC 4923 is a total VPN-and-QoS deep dive, bestie 🌈
- Request for Comments: 4923
- Network Working Group
- Authors: F. Baker (Cisco Systems) and P. Bose (Lockheed Martin) 👑
- Category: Informational 💅
- Date: August 2007 🌸
- Obsoletes / Updates: the header doesn't list any RFCs as obsoleted or updated 🧚
Status of This Memo ✨
This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 💜
Copyright (C) The IETF Trust (2007).
Abstract 🦋
Some networks need to talk between an interior and exterior part of a Virtual Private Network (VPN), or through a chain of those networks (a nested VPN). The catch is that they're super picky about what info crosses the boundary, especially when they're also trying to give QoS to traffic with different precedence. This note lays out the issues and the kinds of solutions being proposed, building on the framework for Integrated Services over Diffserv networks described in RFC 2998. 💖
Table of Contents 🍓
1. Introduction ....................................................3
1.1. Problem Statement ..........................................3
1.2. Background Information and Terminology .....................4
1.3. Nested VPNs ................................................5
1.4. Signaled QoS Technology ....................................7
1.5. The Resource Reservation Protocol (RSVP) ...................9
1.6. Logical Structure of a VPN Router .........................10
2. Reservation and Preemption in a Nested VPN .....................13
2.1. Reservation in a Nested VPN ...............................14
2.2. Preemption in a Nested VPN ................................16
2.3. Working through an Example ................................17
2.3.1. Initial Routine Reservations - Generating
Network State ......................................18
2.3.2. Initial Routine Reservations - Request
Reservation ........................................19
2.3.3. Installation of a Reservation Using Precedence .....20
2.3.4. Installation of a Reservation Using Preemption .....21
3. Data Flows within a VPN Router .................................24
3.1. VPN Routers That Carry Data across the
Cryptographic Boundary ....................................24
3.1.1. Plaintext to Ciphertext Data Flows .................24
3.1.2. Ciphertext to Plaintext Data Flows .................27
3.2. VPN Routers That Use the Network Guard for
Signaling across the Cryptographic Boundary ...............28
3.2.1. Signaling Flow .....................................29
3.2.2. Use Case with Network Guard ........................30
4. Security Considerations ........................................33
5. Acknowledgements ...............................................34
6. References .....................................................34
6.1. Normative References ......................................34
6.2. Informative References ....................................351. Introduction ✨
1.1. Problem Statement 🔥
More and more networks want to guarantee secure transmission of IP traffic across public LANs or WANs, so they use Virtual Private Networks. Some of them need to communicate between an interior and exterior part of a VPN, or through a chain of such networks (a nested VPN). They're also sensitive about what information gets communicated across that boundary, especially when they're giving QoS to communications with different precedence. This note sets out the issues and the nature of the proposed solutions. 💅
The QoS solution for real-time traffic was described at a high level in [RFC4542]. The key characteristics of this proposal are:
- It uses standardized protocols. 🫶
- It includes reservation setup and teardown for guaranteed and controlled load services, using those standardized protocols. ✨
- It is independent of link delay, so it works with high delay*bandwidth networks as well as the more common kind. 🌈
- It has no single point of failure, such as a central reservation manager. 👑
- It provides for the preemption of established data flows. 💀
- During that preemption, it doesn't just let a policy-admitted data flow in. It selects a specific data flow to exclude based on control input, instead of simply accepting a loss of service decided at the discretion of the network control function. 😭
- It interoperates directly with SIP Proxies, H.323 Gatekeepers, or other call management subsystems, so it can offer the other services needed in a preemptive or preferential telephone network. 📞
This memo is mostly about VPNs that use encryption in some form, such as IPsec, and about their nesting across multiple network domains. Section 1.3 narrows this down further, describing the nested VPN as an example of an IPsec or IPsec-like VPN in the context of a 'customer provisioned' VPN. So we'll talk about a VPN router that has "plaintext" and "ciphertext" interfaces. 🧚 The concept is easy to extend to any form of aggregation, including the idea in [RFC3175] of IP traffic entering and leaving a network at identified points, and to other kinds of tunnels, such as Generic Routing Encapsulation (GRE), IP/IP, MPLS, and so on. 🦋
1.2. Background Information and Terminology 📚
Okay, we need to talk about "priority" and "precedence," because this document uses them carefully. "Priority" has been used with a bunch of different meanings in this area, and that caused a ton of confusion. Here, "priority" means one of several possible datagram scheduling algorithms. A scheduler decides which datagram gets sent next on a computer interface. A priority scheduler always picks a datagram from the highest-priority class (queue) that has something waiting, which shields one class of traffic from most of the jitter by passing that jitter on to another class. 🍓
[RFC3181] applies the term to a reservation, in a sense this document calls "precedence." "Precedence" is used the way it's used in the phrase "Multi-Level Precedence and Preemption" [ITU.MLPP.1990]. Some classes of sessions take precedence over others. That can mean bandwidth gets admitted that otherwise wouldn't have been, or that a lower-precedence session gets terminated (prejudicially) under a stated set of circumstances. 👑 So for this discussion: "priority" is a set of algorithms applied to datagrams, and "precedence" is a policy attribute of sessions. Priority comparisons are used in a router or a policy decision point to implement precedence, but they are not the same thing. 💖
The same goes for QoS policies versus policies based on how "precedence" or "importance" matters to the person or function using the data. Voice gets hurt by high levels of network-induced delay variation, no matter what the precedence level of the call is. So voice is often served from a priority queue, which pushes jitter from that app's traffic onto other applications. This is just as true for routine voice calls as it is for flash traffic. 🌸
Some application traffic needs bounded delay. That's a different thing from "no jitter": those apps can handle jitter as long as it stays within stated bounds. Routing protocols like OSPF or BGP are critical to how network infrastructure works. They're designed to cope with moderate loss, but loss doesn't help them, and even a short burst of high loss can cause dramatic network events. Delay variation isn't really a problem as long as it stays within reasonable bounds, so routers often treat routing protocol datagrams in a way that limits the chance of loss, even when that means accepting fairly high delay. The traffic is absolutely critical to the network. 🧠
Telephone call setup has the same trait. When protocols like SIP and H.323 have to choose between loss and delay, they strongly prefer delay. Call setup takes far less time than it would if datagrams had to be retransmitted, and that's true whether the call is routine or high precedence. 📞 So QoS markings tell us how to give an application good service regardless of how "important" it is at the moment, while "importance" can be conveyed separately in many cases. 🫶 iykyk, and now you do, bestie ✨
1.3. Nested VPNs 🧚
okay so you can picture a nested VPN network with three network diagrams 🦋 Figure 1 shows a simple network stretched across a VPN connection. The VPN router (where, following [RFC2460], a "router" is "a node that forwards packets not explicitly addressed to itself") does these steps 💅:
- receives an IP datagram from a plaintext interface,
- determines what remote enclave and therefore other VPN router to forward it to,
- ensures that it has a tunnel mode security association (as generally defined in [RFC4301], Section 4) with that router,
- encloses the encrypted datagram within another VPN (e.g., IPsec) and IP header, and
- forwards the encapsulated datagram toward the remote VPN router.
The receiving VPN router reverses the steps 🔄
- determines what security association the datagram was received from,
- decrypts the interior datagram,
- forwards the now-decapsulated datagram on a plaintext interface.
This way of using IPsec is called the tunnel mode of [RFC4301] and [RFC4303] ✨
Host Host Host Host Host Host
/------------------/ /------------------/
Router -------Router
|
VPN-Router
||
|| IPsec Tunnel through routed network
||
VPN-Router
|
Router -------Router
/------------------/ /------------------/
Host Host Host Host Host Host
Figure 1: VPN-Connected EnclaveAn important point 🫶 the VPN tunnel, just like other features of the routed network, is invisible to the host. The host can infer that "something out there" is affecting the Path MTU, introducing delay, or otherwise affecting its data stream, but if properly implemented, it should be able to adapt to these. The words "if properly implemented" are the bane of every network manager, however 😭 substandard implementations do demonstrably exist.
Outside of the enclave, the hosts are basically invisible 👻 The communicating enclaves look like a simple data exchange between peer hosts across a routed network, as shown in Figure 2.
Hosts Not Visible
/==================/
Router
|
VPN-Router
/---------------------/
Inner Domain
/---------------------/
VPN-Router
|
Router
/==================/
Hosts Not Visible
Figure 2: VPN-Connected Enclave from Exterior PerspectiveNetworks like this can be nested and reused in a super complex way 🌈 As shown in Figure 3, a pair of enclaves might communicate across a ciphertext network that, for various reasons, is itself re-encrypted and sent across a larger ciphertext network. The reasons vary, but they relate to information-hiding in the wider network, different levels of security required for different enclosed enclaves, and so on 🙈
Host Host Host Host Host Host
/------------------/ /------------------/
Router -------Router
|
VPN-Router VPN-Router VPN-Router
/---------------------/ /----------/
Router -------------Router
|
VPN-Router VPN-Router
/-----------/ /----------/
Router -------Router
|
|
Router -------Router
/-----------/ /----------/
VPN-Router VPN-Router
|
Router ------------Router
/---------------------/ /----------/
VPN-Router VPN-Router VPN-Router
|
Router -------Router
/------------------/ /------------------/
Host Host Host Host Host Host
Figure 3: Nested VPNThe big question this document explores is "how do reservations, and preemption of reservations, work in such an environment?" 👑
1.4. Signaled QoS Technology 💜
The Integrated Services model for networking was first proposed in [RFC1633] ✨ In short, it splits all applications into two broad classes: those that will adapt themselves to any available bandwidth, and those that will not or cannot. In the words of [RFC1633]:
One class of applications needs the data in each packet by a certain time and, if the data has not arrived by then, the data is essentially worthless; we call these "real-time" applications. Another class of applications will always wait for data to arrive; we call these "elastic" applications.
The Integrated Services model defines data flows supporting applications as either "real-time" or "elastic". Also, "real-time" traffic is called "inelastic" traffic, and elastic traffic is sometimes called "non-real-time" 🦋
The key issue here is the so-called "playback point" 🎀 A real-time app is treated as having a certain point in time at which data describing the next sound, picture, or whatever to be delivered to a display device, or else it loses its usefulness. An elastic app has no such boundary. Another way to see the difference is that real-time apps have an irreducible lower bound on their bandwidth requirements. For example, the typical G.711 payload is delivered in 160-byte samples (plus 40 bytes of IP/UDP/RTP headers) at 20 millisecond intervals. This gives you 80 kbps of bandwidth, without silence suppression, and not counting the layer 2 overhead 💅 To operate in real-time, a G.711 codec needs the network it delivers over to support communications at 80 kbps at the IP layer, with roughly constant end-to-end delay and nominal or no loss. If that isn't possible (say there's significant loss or wide swings in delay), voice quality will suffer 😭 On the other hand, if many megabits of capacity are available, the G.711 codec won't increase its bandwidth requirements either. Adaptive codecs do exist (e.g., G.722.2 or G.726), but the adaptive mechanism can either need greater or lesser bandwidth, and it can only adapt within a certain range of bandwidth requirements. Past that range, the quality of the data flow required isn't met 🙅
Elastic apps, though, will basically adapt to any network 🌸 If the bottleneck gives 9600 bits per second, a Web transfer or electronic mail exchange will happen at 9600 bits per second. If hundreds of megabits are available, the TCP (or SCTP) transport will ramp up its transfer rate to try to cut down the time the transfer takes ⭐
For real-time apps, the ones that need data delivered end to end with at least a certain rate and with delays varying between stated bounds, the Integrated Services architecture proposes using a signaling protocol. That protocol lets the communicating applications and the network talk about the application requirements and the network's capability to deliver them. Several such protocols have been developed or are under development, notably the Resource Reservation Protocol (RSVP) and Next Steps in Signaling (NSIS). This discussion is limited to RSVP, although any protocol that delivers a similar set of capabilities could be considered 🫶
1.5. The Resource Reservation Protocol (RSVP) 💌
okay so RSVP got its start in [RFC2205], with its datagram processing rules in [RFC2209] and the datagram details for Integrated Services in [RFC2210] 💖. The basic idea is that it lets you identify the data flows going from a source application to a destination application, then ask the network for specific resources for them ✨. The source can be a single machine or a set of machines, either listed explicitly or implied. The destination can be a single machine or a multicast group, which means every machine in that group 🦋. Each application gets identified by a transport protocol number in the IP protocol field, and it can also include destination and maybe source port numbers 🎀. RSVP works for both IPv4 [RFC0791] and IPv6 [RFC2460] 👑.
Right away people realized RSVP also needed to do the same job for all kinds of tunnels, and that means there's a relationship between what's inside the tunnel and what's outside it 🧚. So definitions got made for IPsec [RFC2207] and [RFC4860], plus more generic tunnel forms in [RFC2746] 💅. Later on, the Differentiated Services Architecture [RFC2475] showed up, and that brought in the Differentiated Services Code Point (DSCP) [RFC2474]. [RFC2996] added definitions for using a DSCP with a standard RSVP data flow, and [RFC3175] went one step further and uses a pair of IP addresses plus a DSCP as the identifying info for a data flow 🌈.
Now here's the tea 🍓. The first version of the protocol had a placeholder for policy information and for preemption of reservations. That placeholder got fleshed out in [RFC2750], with the goal of tying a policy [RFC2872] to an identity [RFC3182]. This lets the network give a contracted service to an authenticated and authorized user 🔥. It was then integrated with the Session Initiation Protocol [RFC3261] in [RFC3312] ⭐.
Preemption is handled as specified in [RFC3181], and honestly this part is a little messy 🙈. A reservation installed with a Preemption Priority and kept with a separate Defending Priority can be removed by the network through a RESV Error signal, and that signal wipes out the entire reservation 💀. The thing is, it's often not that black and white. Say an existing reservation for 80 kbps can't be sustained anymore, but a 60 kbps reservation could be. A VoIP sender might be able to switch from a G.711 codec to a G.729 codec and make that work 🦋. Or if there are multiple sessions in a tunnel or other aggregate, you could just drop one call and leave the capacity for the rest 💜. [RFC4495] is the one that tries to fix this problem ✨.
Similarly, a capability was added to make control signals harder to spoof or otherwise attack, which is defined in [RFC2747] and [RFC3097] 🛡️.
[RFC3175] has a few features that are pretty unusual for RSVP, since it's specifically built to handle aggregates in a service provider network 👑. It describes three key components:
- The RFC 3175 session object, which doesn't identify the IP addresses of the individual packets being identified. Instead, it identifies the IP addresses of the ingress and egress devices in the network, plus the DSCP the traffic is going to use 🎀.
- The reservation "aggregator" function, which runs in the ingress router. It accepts individual reservations from the "customer" network and bundles them up for the ISP core, either inside a tunnel, inside an MPLS LSP, or as a traffic stream that's known to leave at the deaggregator 🧚.
- The reservation "deaggregator" function, which runs in the egress router. It breaks the aggregate reservation and the data streams back out into individual data streams that can be passed on to other networks 🌸.
Looking back, the Session Object from RFC 3175 is useful, but it's not intrinsically necessary 🤷♀️. If the ISP network uses tunnels like MPLS LSPs, IP/IP or GRE tunnels, or enclosing IPsec Security Associations, the aggregator and deaggregator concepts work the same way. The reservation mechanism would just be the one from [RFC3473] and [RFC3474], [RFC2207], [RFC4860], or [RFC2746] instead 💅.
1.6. Logical Structure of a VPN Router 🌸
The conceptual structure of a VPN router is pretty similar to any other router 💖. In its simplest form, it's physically a device with two or more ports (kind of like the one in Figure 4). It has one or more interfaces to the protected enclave(s) and one or more interfaces to the outside world. On that outside side, it sets up a bunch of tunnels (for IPsec tunnels, that means having security associations), and it can treat those tunnels as point-to-point interfaces from a routing perspective ✨.
+---------+ +-------+ +----+----+ +---------+
| RSVP | |Routing| |Net Guard| |IPsec Mgr|
+----+----+ +---+---+ +----+----+ +----+----+
| | | |
+----+-----------+------------+-----------------+----+
| IP |
+-----------+--------------------+------------+------+
| | |
| +-----+-----+ +----+------+
| | Encrypt/ | | Encrypt/ |
| |Decrypt for| |Decrypt for|
| | Security | | Security |
| |Association| |Association|
| +-----+-----+ +----+------+
| | |
+-----------+------------+ +-----+------------+------+
| Plaintext | | Ciphertext |
| Interface | | Interface |
+------------------------+ +-------------------------+Figure 4: Logical Structure of a VPN Router
The encrypt/decrypt unit can be implemented as a function of the plaintext router, as a function on its interface card, or as a function of an external device that has a private interface to the IP routing functionality of the plaintext router 🧚. These are conceptually equivalent, although there are practical differences in implementation 🤓. The key issue is this: when IP routing hands a message to the encrypt/decrypt unit for transmission, it must also be given the IP address of the plaintext routing peer, whether that's a host or a router, that the security association has to be established with 🔑. That IP address is used to select (and maybe create) the security association, and that in turn selects the right set of security parameters. This could also be done by presenting the local Security Parameter Index (SPI) for the data, if it was created out of band by the Network Management Process 💜.
On top of that, aggregated signaling has to be generated for the ciphertext domain 🫶. There are a few ways to make that happen:
- by having the RSVP process on the plaintext router generate the messages and having the encrypt/decrypt unit bypass them into the ciphertext network
- by having the plaintext RSVP process tell a process in the encrypt/decrypt implementation what needs to be generated, using some local exchange, and then having that process generate the messages, or
- by having a separate parallel network management system sit between the plaintext and ciphertext routers. In that case, the encrypt/decrypt unit and the parallel network system must use the same address, and the ciphertext router must tell traffic meant for each of them apart based on the SPI or the presence of encryption 🌈
Control plane signaling using this extra path is described in Section 3.2 🎀. The information flowing between the plaintext and ciphertext domains includes:
- IP datagrams going through the encrypt/decrypt unit
- RSVP signaling going through the bypass path
- Control information coordinating security associations
- precious little else 💀
2. Reservation and Preemption in a Nested VPN ✨
/ \
( +--+ +--+ enclave ) ,---------.
.----------. \ |H2+---+R2| / ,-' `
+--+ +--+`--.\ +--+ ++-+ / / +--+ +--+
|H1+---+R1| \`. | ,' / |R3+---+H3|
+--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+
| / _.`---|VPN2||''-. \ |
enclave +----+-i.--'' +----++ `----.\ +----+ enclave
--------|VPN1|' | ``|VPN3| ,
,+----+ | +----+------'
,' --+-------+----------+------------------+---`.
,' ++-+ `.
,' |R7+--------+ `.
/ interface +--+ | \
domain 1 +-+--+ \
_.--------|VPN7|--------.
,-----'' +--+-+ `------. .
`-. ,-' | `-. .-'
`-: inner domain +-++ `.'
( |R9| )
.'. ++-+ ;-.
.' `-. | ,-' `-.
' `------. +-+--+ _.-----' `
interface `---------|VPN8|-------''
domain 2 +-+--+ /
\ | +--+ /
`. +----------+R8| ,'
`. ++-+ ,'
`. --+------------------+-----------+------+-- ,'
,-----+----+ | +----+------.
,' |VPN6|. | _.|VPN4| `
+----+.`----. +----+ _.--'' ,+----+
| \ `--=.-|VPN5|---:' / |
+--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+
|H6+---+R6| | ,' | `.| |R4+---+H4|
+--+ +--+ ;/ +--+ ++-+ : +--+ +--+
// |H5+---+R5| \
enclave ,'( +--+ +--+ `. enclave
`. ,' \ enclave / '-. ,
`-------' \ / `-------'Figure 5: Reservations in a Nested VPN
Let's dig into how a resource reservation protocol, and RSVP specifically, could be used in a nested virtual private network 🦋💖
2.1. Reservation in a Nested VPN ✨
okay bestie, a reservation in a nested VPN is giving the same energy as a reservation in any other network 💅, with one plot twist: it's actually a bunch of reservations that must be coordinated 🫶. That includes one inside the originating enclave, one inside the receiving enclave, and one at each layer of the VPN, as shown in Figure 5 🦋.
So when a host in one enclave opens a reservation to a host in another enclave, a reservation of the right type and size gets created end to end 🌈. As it heads out of its enclave through the VPN router, the reservation info and the data get tucked into the right tunnel (for example, the IPsec Security Association for its precedence level, going to the correct remote VPN router) 🎀. At the remote VPN router it gets pulled back out of the tunnel and sent along to the target system 🧚.
The data inside the enclave gets marked with a DSCP that matches its application and, if it's different, its precedence level 💖. The signaling datagrams (PATH and RESV) get a DCLASS object that shows that value 🔥. Again, PATH and RESV are marked with a DCLASS object indicating the value used for the corresponding data, so that's the same idea said twice, lol 🙈. The DSCP on the signaling datagrams is a DSCP for signaling, though, with one catch: if routing varies by DSCP, then it must be a DSCP that gets routed the same way as the relevant data 🛣️.
The [RFC2872] policy object spells out the applicable policy (like "routine service for voice traffic") and asserts a [RFC3182] credential for its user, which can be a person or a whole class of persons 👑. As specified in [RFC3181], it also carries its Preemption Priority and its Defending Priority 💜. This is what lets the Preemption Priority of a new session get compared with the Defending Priority of sessions that were already admitted ⭐.
On the ciphertext side of the VPN router, you get no guarantees unless that router also sets up a reservation to its peer VPN router across the ciphertext domain 😭. So the VPN router sets up an [RFC2207], [RFC4860], or [RFC3175] reservation to its peer 🫶.
The Session Object from [RFC2207] or [RFC4860] has a field called a "virtual destination port", which lets lots of reservations get multiplexed over one common security association and, in the latter case, one common DSCP value ✨. So voice traffic at every precedence level could use the Expedited Forwarding (EF) DSCP and service as described in [RFC3246], but the reservations would be for "the aggregate of voice sessions at precedence Pn between these VPN routers" 🍓. This lets network admins write policies with multiple thresholds, like "a new session at precedence Pn may be accepted if the total reserved bandwidth does not exceed threshold Qn; if it is necessary and sufficient to accept the reservation, existing reservations at lower precedences may be preemptively reduced to make acceptance of the new session possible" 👀. Iconic behavior, honestly 💅.
In the [RFC3175] case, the DSCP has to identify both the reservation and the matching data stream, so the aggregate reservations for different precedence levels need different DSCP values 🌸.
In either case, the big non-negotiable is that one VPN router acts as what [RFC3175] calls the "aggregator" and another acts as the "deaggregator", and they extend a VPN tunnel between them 🦋. If the VPN Tunnel is an IPsec Security Association between the VPN routers and the IP packet is entirely contained within it (like what you'd use to cross a firewall), then the behavior of [RFC2746] is required of the tunnel 🔒. That bearer has these characteristics:
- it will have a DSCP corollary to the DSCP for the data or the same DSCP as the data it carries,
- the reservations and data will be carried in security associations between the VPN routers, and
- the specification for the reservation for the tunnel itself will not be less than the sum of the requirements of the aggregated reservations.
And these requirements relationships apply between the set of enclosed reservations and the tunnel reservation 💖:
- The sum of the average rates of the contained reservations, having been adjusted for the additional IP headers, will be less than or equal to the average rate of the tunnel reservation.
- The sum of the peak rates of the contained reservations, having been adjusted for the additional IP headers, will be less than or equal to the peak rate of the tunnel reservation.
- The sum of the burst sizes of the contained reservations, having been adjusted for the additional IP headers, will be less than or equal to the burst size of the tunnel reservation.
- The Preemption Priority of a tunnel reservation is identical to that of the individual reservations it aggregates.
- The Defending Priority of a tunnel reservation is identical to that of the individual reservations it aggregates.
The only time this would be different is when measurement-based admission is used in the tunnel but not in the end system 📊. In that case, the tunnel's average bandwidth specification would be greater than or equal to the actual average offered traffic. Those systems are beyond the scope of this spec, so no drama there 🙈.
Okay, policy plot twist 👀: if the policies for different precedence levels use different thresholds (like "to accept a new routine call, the total reserved bandwidth after admission may not exceed X; to accept a call with a higher precedence level, the total reserved bandwidth after admission may not exceed X+Y, and this may be achieved by preempting a call with a lower precedence level"), then the bandwidth Y effectively comes from the bandwidth in use by elastic traffic instead of forcing a preemption event 😭✨. Internet QoS being quirky again, periodt 💅.
2.2. Preemption in a Nested VPN 🔥
As we talked about in Section 1.5, preemption is specified in [RFC3181] and further addressed in [RFC4495] 🦋. The real issue is that in lots of cases you need to reduce the bandwidth of a reservation because the network changed, not just delete the reservation outright 🌸. If the reservation came from an end system, that system might handle it by switching codecs 🎀. If it's some kind of aggregate, it could cut its sending bandwidth by dropping one or more reservations entirely 💅.
In a nested VPN or any other aggregated reservation, that means the deaggregator (the VPN router that starts the RESV signal for the tunnel) must:
- receive the RESV Error signaling it to reduce its bandwidth,
- re-issue its RESV accordingly,
- identify one or more of its aggregated reservations, enough to do the job, and
- signal them to reduce their bandwidth accordingly.
It's possible, of course, that it's signaling them to reduce their bandwidth to zero, which works the same as removing the reservation as described in [RFC3181] 🧚.
Over in the routers in the core, there's an extra case 👀. Imagine some enclave hands the VPN a single session, and that session has a higher precedence level. If some interior link gets congested (say the reserved bandwidth would go over policy if the call got admitted), then a session between a different pair of VPN routers has to be preempted 😱. More generally, when picking a reservation to preempt, the core router must always select a reservation at the lowest available Defending Priority 💜. That's exactly why the different precedence levels have to stay separate in the core 🫶.
2.3. Working through an Example 🧚
Figure 5 shows three security layers 🌈: six plaintext enclaves around the edge, two ciphertext domains connecting them at one layer (called an "interface domain" in the diagram), and a third ciphertext domain connecting those two (called an "inner domain" in the diagram) 💖. Here's who knows what:
- Each enclave has access to general routing information about the other enclaves it's allowed to talk to: systems in it can translate a DNS name for a remote host or domain and get back the matching address or prefix.
- Each enclave router also has specific routing information about its own enclave.
- A default route gets distributed within the enclave, pointing to its VPN router.
- VPN Routers 1-6 can translate remote enclave prefixes into the right remote enclave's VPN router addresses.
- Each interface domain has access to general routing information about the other interface domains, but not the enclaves. Systems in an interface domain can translate a DNS name for a remote interface domain and get back the matching address or prefix.
- Each interface domain router also has specific routing information about its own interface domain.
- A default route gets distributed within the interface domain, pointing to the "inner" VPN router.
- VPN Routers 7 and 8 can translate remote interface domain prefixes into remote VPN router addresses.
- Routers in the inner domain only have routing information for that domain.
The example shows three levels, but there's nothing magic about the number three 🔢. The model can stretch to any number of concentric layers 🌸.
Also, this example only places unidirectional reservations in the forward direction 👈. In voice and video apps you usually have a reservation in each direction 📞. The reverse direction isn't covered here, just to keep things clear, but it works the same way in reverse and uses the same security associations 🫶.
2.3.1. Initial Routine Reservations - Generating Network State
Okay, bestie, now we install a set of reservations: H1 to H4, H2 to H5, and H3 to H6. For the sake of argument, let's say these are all at the "routine" precedence 💅. H1, H2, and H3 each kick things off by sending a PATH signal that describes their traffic. Let's also say H1's reservation is for an [RFC2205] session, while H2's is for a session encrypted with IPsec, so it depends on [RFC2207]. H3 is a Public Switched Telephone Network (PSTN) gateway, so it sends an [RFC3175] reservation made up of a bunch of distinct sessions 📞. Since these all head to H4, H5, and H6 respectively, the default route sends them to VPN1, VPN2, and VPN3, in that order 🦋.
The VPN routers each make sure they have an appropriate security association or tunnel open to the remote VPN router they were told about (VPN4, VPN5, or VPN6). It has to be a security association or tunnel for the indicated application at the indicated precedence level, and it's giving main character energy ✨. Once that's sorted, the router puts the PATH signal into the security association and forwards it. If that tunnel or security association doesn't already exist, the router follows [RFC3175]'s aggregation model and opens a reservation (it sends a PATH signal) for that tunnel/SA within the interface domain. If the reservation already exists, the VPN router increases the bandwidth shown in the ADSPEC as needed 📈. In this example, these tunnel/SA reservations follow the default route to VPN7 🌸.
VPN7 does the same thing: it makes sure it has an appropriate security association or tunnel open to VPN8, for the indicated application at the indicated precedence level 🫶. Then it puts the PATH signal into that security association and forwards it. If it doesn't already exist, VPN7 follows [RFC3175]'s aggregation model and opens a reservation (sends a PATH signal) for the tunnel/SA within the interface domain. If the reservation is already there, VPN7 bumps up the bandwidth in the ADSPEC appropriately. Here, the tunnel/SA reservation gets forwarded to VPN8 💖.
VPN8 acts as an [RFC3175] deaggregator for the inner domain, and honestly it's iconic 👑. It receives the PATH signal for the inner domain reservation and stores state. It decrypts the data stream from VPN7 and operates on the RSVP signals as an RSVP-configured router. Then it forwards the received IP datagrams, updated PATH signals included, into its interface domain. So the PATH signals that started at VPN1, VPN2, and VPN3 keep moving toward VPN4, VPN5, and VPN6, following the routing of the interface domain 🧚.
VPN4, VPN5, and VPN6 each act as an [RFC3175] deaggregator for the interface domain 🌈. Each one receives the PATH signal for the interface domain reservation and stores state. It decrypts the data stream from its peer and operates on the RSVP signals as an RSVP-configured router. Then it forwards the received IP datagrams, updated PATH signals included, into its enclave. The PATH signals that started at H1, H2, and H3 are now heading toward H4, H5, and H6 according to the routing of the enclave 🎀.
H4, H5, and H6 now receive the original PATH signals and hand them off to their applications. Iconic ✨.
2.3.2. Initial Routine Reservations - Request Reservation
Next, the application on H4, H5, and H6 decides to install the reservations it was offered, which means it replies with RESV signals 🍓. These signals request the bandwidth reservation. They follow the trail the PATH signals left behind and traipse back to their sources 🦋. That trail leads them to VPN4, VPN5, and VPN6, respectively. If the routers in the enclaves are configured for RSVP, the RESV signals go explicitly through R4, R5, or R6. If they aren't, routing takes them through those routers anyway 🌸.
The various RSVP-configured routers along the way in the enclave, including the VPN router on the "enclave" side, check that there's enough bandwidth on their links and that any other stated policy is also met 💅. Once that's confirmed, each one updates its reservation state and forwards the RESV signal to the next hop. The VPN routers also each generate a RESV for the reservation within the interface domain, trying to set or increase the bandwidth of that reservation as needed 📈.
The various RSVP-configured routers along the way in the interface domain, including VPN8, check that there's enough bandwidth on their links and that any other stated policy is also met 🫶. After that, each one updates its reservation state and forwards the RESV signal to the next. VPN8 also generates a RESV for the reservation within the inner domain, attempting to set or increase its bandwidth appropriately. That gets the reservation to the inner deaggregator, VPN8 💖.
The various RSVP-configured routers along the way in the inner domain, including VPN7, do the same checks: enough bandwidth on their links, and any other stated policy met 🧚. Once they pass, each one updates its reservation state and forwards the RESV signal onward. That gets the signal to VPN7 🌈.
VPN7 acts as an [RFC3175] aggregator for the inner domain 👑. It receives the RESV signal for the inner domain reservation and stores state. It decrypts the data stream from VPN8 and operates on the RSVP signals as an RSVP-configured router. Then it forwards the received IP datagrams, updated RESV signals included, into its interface domain. So the RESV signals that came from VPN4, VPN5, and VPN6 move back through the interface domain toward VPN1, VPN2, and VPN3 🎀.
VPN1, VPN2, and VPN3 each act as an [RFC3175] aggregator for the interface domain ✨. Each one receives the RESV signal for the interface domain reservation and stores state. It decrypts the data stream from its peer and operates on the RSVP signals as an RSVP-configured router. Then it forwards the received IP datagrams, updated RESV signals included, into its enclave. The RESV signals that came from H4, H5, and H6 are now heading toward H1, H2, and H3 according to the routing of the enclave 🦋.
H1, H2, and H3 now receive the original RESV signals and deliver them to their applications. The reservations are officially set up, bestie 🌸🎉.
2.3.3. Installation of a Reservation Using Precedence
You don't have to go through every step from Sections 2.3.1 and 2.3.2 again 🙈. If there's enough bandwidth to support them, reservations at other precedence levels or for other applications can also be installed across this network 💜. Like, if the "routine" reservations we've been talking about are for voice, a voice reservation at the "priority" precedence level might be installed, as long as there's enough bandwidth under the relevant policy 🔥.
Now here's the tea. Because of how preemption works, this wouldn't expand the existing "routine" reservations in the interface and inner domains. Doing that would cause loss of information, because how much of the reservation is now "routine" and how much is "priority"? 😭 So instead, this new reservation opens up a separate set of tunnels or security associations for traffic of its application class at its precedence level, between that aggregator and deaggregator 🌈.
Side note, but there's an opportunity here that doesn't exist in the PSTN 💅. In the PSTN, all circuits can potentially be used by any PSTN application under a certain set of rules. (H channels, like the ones video streams use, have to be contiguous and ordered.) So if a channel isn't made available to routine traffic but is made available to priority traffic, the operator is potentially losing revenue on the reserved bandwidth and deserves to be paid for it 💸. In the IP Internet, though, some bandwidth has to be kept for basic functions like routing. In general, policies won't allow 100% of an interface's bandwidth to go to one application at one precedence. So it may be acceptable to let a certain portion (e.g., 50%) be used by routine voice, and a larger amount (e.g., 60%) be used by voice at a higher precedence level 🫶. Under a policy like that, a higher precedence reservation for voice might not preempt a routine call. Instead, it impacts elastic traffic, and it might get accepted at a time when a new reservation of lower precedence would be denied 🧚.
In microwave networks, like satellite or mobile ad hoc networks, you could also imagine network management stepping in to change the characteristics of the radio signal, which would increase the bandwidth under some appropriate policy 🛰️✨.
2.3.4. Installation of a Reservation Using Preemption ✨
okay so now there are a bunch of reservations floating around the network (see Figure 5 🦋), including several at "routine" precedence and one at "priority" precedence. For sake of argument, pretend the link from VPN7 to R9 is totally maxed out 😭. All of the bandwidth that policy allows for voice at the routine or priority level is already reserved. Then a brand new "priority" reservation shows up from H3 to H6 💅
The process from Section 2.3.1 kicks in, and PATH state gets set up across the network for the new reservation. It gets installed even though a new reservation can't be installed on VPN7-R9, because PATH doesn't install any reservation, and the network doesn't know yet whether H6 will actually need one 🙃
Section 2.3.2 is also in play. The application in H6 decides to install the reservation, so it sends back an RESV signal. That signal follows the trail the PATH left behind and traipses back toward H3 🌸 VPN6 and (if RSVP was configured) R6 check that there's enough bandwidth on their links and that any other stated policy is met too. Once they pass, each one updates its reservation state and forwards the RESV signal to the next hop. VPN6 also generates an RESV for the reservation within the interface domain, trying to set or increase the bandwidth appropriately 🎀
VPN6, R8, and VPN8's "interface domain" sides all check that there's enough bandwidth on their links and that any other stated policy is met. Once they pass, each one updates its reservation state and forwards the RESV signal to the next hop. VPN8 also generates an RESV for the reservation within the inner domain, trying to set or increase the bandwidth appropriately. This gets the reservation to the inner deaggregator, VPN8 👑
VPN8's "inner domain" side and R9 now check that there's enough bandwidth on their links and that any other stated policy is met. At R9, though, there's a problem: there isn't enough bandwidth under the relevant policy 💀 Without precedence, R9 would return a RESV Error saying the reservation couldn't be increased or installed. If a preexisting reservation of lower bandwidth was already there, it would stay in place, the new bandwidth wouldn't be granted, and the originator (H6) would be informed.
But precedence changes the game, so let's be clear about what it means to be at a stated precedence. It means the POLICY_DATA object in the RESV contains a Preemption Priority and a Defending Priority, with values specified in some memo 🧚 With precedence, the algorithm in [RFC4495] compares the Preemption Priority of the new reservation against the Defending Priority of the extant reservations in the router. There are two of those: one VPN7->VPN8 at "routine" precedence and one VPN7->VPN8 at "priority" precedence. Since the Defending Priority of the routine reservation is less than the Preemption Priority of a "priority" reservation, the "routine" reservation gets selected. R9 decides it will accept the increase in its "priority" reservation VPN7->VPN8 and reduce the corresponding "routine" reservation 🔥 Two processes now happen in parallel:
- The routine reservation is reduced following the algorithms in [RFC4495] and
- The priority reservation continues according to the usual rules.
R9 reduces its "routine" reservation by sending a RESV Error that updates its internal state to reflect the reduced reservation. It also sends a RESV Error to VPN8 asking it to reduce its reservation to a number less than or equal to the relevant threshold, minus the sum of the competing reservations 🫶
VPN8, acting as a deaggregator, makes two changes. On the "inner domain" side, it marks its reservation down to the indicated rate (the most it's now permitted to reserve), so that if an RESV Refresh event happens, it'll request the specified rate. On the "interface domain" side, it selects one or more of the relevant reservations using an algorithm of its choosing and asks that they likewise reduce their rate. For the sake of argument, say the selected reservation is the one to VPN5. The RESV Error now makes its way through R8 to VPN5, which reduces its bandwidth request to the stated amount and passes a RESV Error signal on the "enclave" side asking that the reservation be appropriately reduced 💖
H5 is now faced with a decision 😬 If the request is to reduce the reservation to zero, that's the same as tearing it down. In this simple case, H5 sends a RESV Tear to tear the reservation down entirely, and advises its application to adjust its expectations of the session, which may mean shutting the session down. If the request is to reduce it below a certain value, though, the application might be able to do that and stay viable. For example, if a VoIP application using a G.711 codec (80 kbps) is asked to reduce its bandwidth below 70 kbps, it may be possible to renegotiate the codec in use to G.729 or some other codec. In that case, the originating application should re-reserve at the stated bandwidth (in this case, 70 kbps), start the application-level change, and let the application change the reservation again (perhaps to 60 kbps) once that process is done 🌈
Back at R9, the "priority" reservation is still being processed. R9 believes it has sufficient bandwidth and that any other stated policy is also met, so it forwards the RESV to VPN7. Each one updates its reservation state and forwards the RESV signal to the next hop. VPN7 now acts as an [RFC3175] aggregator for the inner domain 🦋 This means it receives the RESV signal for the inner domain reservation and stores state, decrypts the data stream from VPN8, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its interface domain. The RESV signals originated by VPN4, VPN5, and VPN6 are therefore forwarded toward VPN1, VPN2, and VPN3 through the interface domain.
VPN3 now acts as an [RFC3175] aggregator for the interface domain. This means it receives the RESV signal for the interface domain reservation and stores state, decrypts the data stream from its peer, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its enclave. The RESV signal originated by H6 is therefore forwarded toward H3 according to the routing of the enclave 🏡
Finally, H3 receives the original RESV signals and delivers it to the relevant application 🎉
3. Data Flows within a VPN Router 🌷
This section details the data flows within a VPN router, in the context of the sessions described in Section 2 💜 It specifically identifies the signaling flow at a given VPN boundary, and it also elaborates the signaling mechanism with the help of a Network Guard 🛡️ A use case describing the proposal in the context of an operational scenario is presented here too ✨
3.1. VPN Routers That Carry Data across the Cryptographic Boundary 🔐
3.1.1. Plaintext to Ciphertext Data Flows
okay bestie, let's talk about how plaintext turns into ciphertext 🦋 the VPN router has a plaintext RSVP side and an aggregate RSVP side, and the diagram below is basically the whole vibe 💅
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP ||
| | || || ||
| |Per session: || ID ||Agg. Session ||
| | Destination ||--->|| Agg. Destination ||
| | Source || || Agg. Source= self ||
| | potential SPI || || Agg. SPI generated||
| | DSCP ---------> DSCP ||
| | vPort or protocol---------> vPort ||
| | and port || || ||
| | Mean rate ---------> Sum of mean rates ||
| | Peak rate ---------> f(Peak rates) ||
| | Burst Size ---------> Sum of Burst sizes||
| | || || ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | IP || || IP ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | Plaintext Interface|| ||Ciphertext Interface||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
Figure 6: Data Flows in a VPN Router Outboundso here's what gets handed over from the plaintext side to the ciphertext unit, and it's a whole checklist 📋✨
- Destination Address: on the plaintext side, the VPN router joins the end-to-end reservations that get set up for plaintext sessions 🌸 those can be individual flows from [RFC2205], IPsec data flows from [RFC2207], aggregate reservations from [RFC3175], or other kinds. it then passes an identifier for the ciphertext side of the deaggregator over to its ciphertext unit 🫶
- DSCP: the DSCP of the plaintext data flow gets passed along to the cipher text side 💖
- Virtual Port: the virtual destination port gets passed to the cipher text side 🦋 this can come from an [RFC2207] session object or from policy information 📜
- Mean Rate: the sum of the plaintext mean rates gets handed to the ciphertext unit 🧚
- Peak Rate: a function of the plaintext peak rates gets handed to the ciphertext unit 👑 this function is less than or equal to the sum of the peak rates ✨
- Burst Size: the sum of the burst sizes gets handed to the cipher text unit 🍓
now the messages 📬 it's giving group chat forwarding 😭
- Path: the plaintext PATH message gets sent as encrypted data to the ciphertext unit 🌈 in parallel, a trigger needs to go to the ciphertext unit so it generates the matching aggregated PATH message for the ciphertext side 💅
- Path Error: this shows that a PATH message sent to the remote enclave had an error 🙈 the message itself gets sent on as encrypted data, but a signal also goes to the ciphertext side in case the error affects the ciphertext reservation (like removing or changing state) 💀
- Path Tear: the PATH Tear message gets sent as encrypted data to the ciphertext unit 🦋 in parallel, a signal goes to the cipher text side; it will trigger a Path Tear on its reservation if this is the last aggregated session, or change the SENDER_TSPEC of the aggregated session 🫶
- RESV: the plaintext RESV message gets sent as encrypted data to the ciphertext unit 🌸 in parallel, a trigger needs to go to the ciphertext unit so it generates the matching aggregated RESV message for the ciphertext side ✨
- RESV Error: this shows that a RESV message received as data and forwarded into the enclave had an error or needed to be preempted, as described in [RFC3181] or [RFC4495] 😭 in the error case, the message gets sent on as encrypted data, but a signal also goes to the ciphertext side in case the error affects the ciphertext reservation (like removing or changing state) 🔥
- RESV Tear: the RESV Tear message gets sent as encrypted data to the ciphertext unit 🍓 in parallel, a signal goes to the cipher text side; it will trigger a RESV Tear on its reservation if this is the last aggregated session, or reduce the bandwidth of an existing reservation 🧚
- RESV Confirm: this shows that a RESV message received as data and forwarded into the enclave is now being confirmed 💖 this message gets sent as encrypted data to the ciphertext side, and in parallel, a signal goes out to potentially trigger a RESV Confirm on the aggregate reservation 🎀
3.1.2. Ciphertext to Plaintext Data Flows
okay now the reverse trip 🔄 going from ciphertext back to plaintext looks like this 🦋
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP ||
| | || || terminated ||
| |Per session: |+ || ||
| | Destination || || ||
| | Source <---------Decrypted RSVP ||
| | potential SPI || || message sent to ||
| | DSCP || || Plaintext unit ||
| | vPort or protocol || || *as data* for ||
| | and port || || normal processing ||
| | Mean rate || || ||
| | Peak rate || || ||
| | Burst Size || || ||
| | || || ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | IP || || IP ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| |Plaintext Interface || ||Ciphertext Interface||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
Figure 7: Data Flows in a VPN Router Inboundso the aggregate reservation gets terminated by the ciphertext side of the VPN router 🛑 the RSVP messages for the subsidiary sessions ride along in the encrypted tunnel as data 🔐 so they show up at the plaintext side with the rest of the data 🎀 since the plaintext side is part of these reservations, it sends some info back to the ciphertext side to parameterize the aggregate reservation, as described in Section 3.1.1 when handling outbound messages 💜
3.2. VPN Routers That Use the Network Guard for Signaling across the Cryptographic Boundary
okay so as Section 1.6 explains, the Network Guard gives reservation signaling an extra path between the plaintext and ciphertext domains 🧚
_.------------.
,--'' Plaintext Domain--.
,-' +--------+ +--------+ `-.
,' | Host | | Host | `.
,' +--------+ +--------+ `.
; :
| +----------------------+ |
: | +--------+ | |
`. | | Router | | ,'
`. | +---+----+ | ,'
`- | +----------+ | ,'
---| +-+--+ +-+--+--+ |'
|----|E/D |--|Net Grd| | VPN Router
,-'| +-+--+ +-+--+--+ |\
, | +----------+ | \
,' | +---+----+ | `.
,' | | Router | | |
/ | +--------+ | \
; +----------------------+ :
| |
: Ciphertext Domain ;
Figure 8: RSVP Passage via Network Guardin this setup, the VPN router is made of a plaintext router, a ciphertext router, an encrypt/decrypt implementation (like a line card or interface device), and a network management process 🛠️ that manages the encrypt/decrypt implementation and can pass defined information flows between the plaintext and ciphertext domains 💅 if the Network Guard is a software process that swaps configuration instructions between the routers, it's super simple to understand 🌸 if it's built as a separate system swapping datagrams, it's a bit more complex, but conceptually the same ✨ for example, the ciphertext router would treat an IP datagram received via the Network Guard (control plane) as having come from, and being about, the interface used in the data plane to the encrypt/decrypt unit 🫶
3.2.1. Signaling Flow
encrypt/decrypt units might not be able to terminate and originate flows like Section 3.1 describes, and policy might stop the plaintext router from knowing the ciphertext network addresses 🙈 in that case, the plaintext and ciphertext routers can use the Network Guard as the path for signaling flows 🦋 the Network Guard does the following to keep reservation signaling flowing across the cryptographic domain 👑
- transforms plaintext session identifiers into ciphertext session identifiers and vice-versa in IP datagrams and RSVP objects (e.g. IP addresses) 💖
- performs resource management of aggregated reservations (e.g., including ciphertext encapsulation overhead in the resources requested) 🧚
- reads and writes configuration on the encrypt/decrypt units as necessary (e.g., reads the plaintext to ciphertext IP address mapping) 📜
also, the plaintext and ciphertext routers have to support a routing function or local interface that makes sure aggregated RSVP messages flow via the Network Guard 🔥 but the signaling flow across the whole VPN router at a cryptographic boundary stays identical to what Section 3.1 describes 🎀
a reader might notice that the VPN router in Figure 8 could be squished into a single router with two halves, or the Network Guard and the encrypt/decrypt units could be part of the plaintext router 🌈 the details of other logical and physical architectures for the VPN router are out of scope for this document 💅
3.2.2. Use Case with Network Guard ✨
........................................
: VPN Router A :
: :
:+-----------++----------++-----------+:
+------+ RSVP :| || NetGrd-A || |:
|Host A|<---->:|PT-Router-A|+----------+|CT-Router-A|::::::::
+------+ :| || E/D-A || |: ::
:+-----------++----------++-----------+: ::
: A-RSVP : ::
: <:::::::::::::> : ::
:......................................: ::
A-RSVP ::
,---.
,' `.
/ \
; Interface :
| Domain |
: ;
\ /
`. ,'
'---'
A-RSVP ::
........................................ ::
: VPN Router B : ::
: : ::
:+-----------++----------++-----------+: ::
+------+ RSVP :| || NetGrd-B || |: ::
|Host B|<---->:|PT-Router-B|+----------+|CT-Router-B|::::::::
+------+ :| || E/D-B || |:
:+-----------++----------++-----------+:
: A-RSVP :
: <:::::::::::::> :
:......................................:
Figure 9: Aggregated RSVP via Network GuardOkay so this figure is giving everything 🗺️✨. Here's the vibe: Host A is trying to make an RSVP reservation with Host B, and the two VPN routers (VPN Router A and VPN Router B) are wrapping all that signaling up inside encrypted tunnels 🔐💖. The aggregated RSVP stuff, called A-RSVP, flows into the CT-Routers and out through the interface domain so that the RSVP-capable routers along the path can actually reserve resources for the trip 🦋. The aggregation and deaggregation point here is the PT-Router, and the Network Guard is doing the extra work from Section 3.2.1 to turn plaintext A-RSVP messages into ciphertext A-RSVP messages 💅.
Here's how a typical reservation goes, bestie:
- Host A sends an RSVP PATH message to Host B. 📨
- PT-Router-A wraps that RSVP PATH message in an encrypted tunnel headed to VPN Router B. 🎀
- The CT Routers and the interface domain carry the encrypted RSVP PATH message, just like any other encrypted data message. 🚚
- PT-Router-B decrypts the RSVP Path Message and sends an E2E PathErr message back to PT-Router-A through the encrypted tunnel. 😭
- PT-Router-B forwards the decrypted plaintext RSVP PATH message on to Host B. ✨
- PT-Router-A gets the E2E PathErr and sends an aggregated RSVP PATH message toward PT-Router-B through the Network Guard. 🌸
- NetGrd-A transforms the plaintext aggregate RSVP into a ciphertext aggregate RSVP message, as described in Section 3.2.1, and sends it to CT-Router-A. 🔥
- The ciphertext aggregated RSVP message travels through the ciphertext routers in the interface domain. 🌈
- CT-Router-B receives the ciphertext aggregate RSVP message and sends it to NetGrd-B. 💜
- NetGrd-B transforms the ciphertext aggregate RSVP back into a plaintext aggregate RSVP message, as described in Section 3.2.1, and sends it to PT-Router-B. 👑
The later RSVP and Aggregate RSVP signaling follows a similar flow, as described in detail in [RFC3175] and [RFC4860]to aggregate each plaintext reservation into a corresponding ciphertext reservation 🧚. This makes sure the RSVP-capable ciphertext routers reserve the resources needed for a plaintext end-to-end reservation. Later mechanisms, like preemption or increasing and decreasing the resources reserved, can be applied to these reservations too, just like we talked about earlier in this document 🫶. The RSVP data flow from Section 3.1, inside the VPN router (from the plaintext router to the ciphertext router through the Guard), gives the ciphertext domain routers all the info they need to run the QoS solution in this document. Lowkey genius 🦋💅.
Now, in this description we treated the Network Guard as separate from the encrypt/decrypt unit. That separation exists because, in some implementations, the people who specify the devices require it 🙈. But the separation doesn't come for free ngl: splitting the devices apart for system-engineering purposes is expensive, and it creates architectural problems 💀. For example, when the Guard is used to aggregate RSVP messages or Protocol Independent Multicast (PIM) routing, the traffic is destined for the remote VPN router. So the Guard has to somehow receive and respond, on behalf of the VPN Router, to messages that aren't addressed to it 😭. There are several possible solutions, and they should be picked carefully based on the security and implementation needs of the environment. They are as follows:
Okay the big question is which solution you pick, and it's a security decision as much as a build one 🚨.
- In the simplest case, the Network Guard and the encrypt/decrypt unit can be two independent functions that use a common network and MAC layer. This lets the two functions share a common MAC and IP address, so traffic destined for one function is also received by the other. If the two functions are physically separated on two devices, they can still share a common MAC and IP address. However, the Guard may need extra modifications to filter out and not process IP traffic that isn't destined for itself. 🎀
- The ciphertext interface of the Guard could be placed into promiscuous mode, letting it receive all messages and discard all but the few it cares about. The security considerations for putting a device in promiscuous mode at the VPN boundary need to be taken into account with this method. 👀
- The Guard could be engineered to receive everything from the ciphertext router and pass the bulk of it on to the VPN router through another interface. In this case, the Guard and the VPN router would use the same IP address. This method puts the load of all data and management traffic destined for the VPN router onto the Guard. 🧁
- The VPN router could be engineered to receive all traffic from the ciphertext router and pass any unencrypted traffic it receives to the Guard through another interface. In this case, the Guard and the VPN router would use the same IP address. 🦄
- All the VPN router functions, as shown in Figure 9, could be built into a single chassis, with appropriate internal traffic management to send some traffic into the plaintext enclave and some to the Guard. In this case, the Guard and the VPN router would be -- at least, functionally -- the same system. 👑
Of these, the last one is clearly the simplest architecturally, and it's the one that most minimizes the attendant risk 💖✨.
4. Security Considerations 🔐
The typical security concerns of datagram integrity and node and user authentication are implicitly met by the security association that exists between the VPN routers. The secure data stream flowing between the VPN routers is also used for the reservation signaling datagrams flowing between VPN routers. The information contained in these signaling datagrams gets the same level of encryption as the data streams do 🫶.
One of the reasons cited for nesting VPN routes in Section 1.3 is the different levels of security across the nested VPN routers. If the security level drops from one VPN router to the next VPN router in the nested path, the reservation signaling datagrams will, by default, receive the lower security-level treatment. For most cases, the lower security treatment is acceptable 🙂. In certain networks, though, the reservation signaling across the entire nested path must receive the highest security-level treatment (for example, encryption and authentication of signaling nodes). For instance, the highest precedence level may only be signaled to VPN routers that can provide the highest security levels. If any VPN router in the nested path is incapable of providing the highest security level, it cannot participate in the reservation mechanism 💀🚫.
In the general case, the nested path may contain routers that either can't participate in VPNs or can't provide the required security levels. These routers can take part in the reservation only if the lower security level is acceptable (as configured by policy) for signaling reservation datagrams 🧚.
VPN routers encapsulate encrypted IP packets and prepend an extra header on each packet. These packets, whether used for signaling or data, should be identifiable, at a minimum, by the IP addresses and DSCP value. Therefore, the prepended header should contain, at a minimum, the DSCP value corresponding to the signaled reservation in each packet. This may literally be the same DSCP used for the data (forcing control plane traffic to get the same QoS treatment as its data), or it may be a different DSCP that is routed identically (separating control and data-plane traffic QoS but not routing) 🎀🌈.
Additionally, the security considerations described in [RFC4860] and [RFC3175] also apply in this environment. They include the fact that the integrity of RSVP messages can be ensured via mechanisms described in [RFC2747] and [RFC3097], along with related key management (through manual configuration or a key management protocol) at nodes between any aggregator and deaggregator pair that processes the messages. On top of that, confidentiality can be provided between hops by employing IPsec 🔒💜. Further work in the IETF MSEC Working Group may be applicable in these environments for key management and confidentiality 👑.
5. Acknowledgements 🌸
Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger Levesque, and Subha Dhesikan gave early review comments. Thank you, legends 🫶.
Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou, and their associates resulted in Section 3.2. ✨
Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik Bose) added [RFC4860], which clarified the interaction of this approach with the DSCP. That's the kind of teamwork that's literally iconic 👑💅.
6. References 📚
6.1. Normative References
okay bestie, this is the list of RFCs you have to read before RFC 4923 makes any sense 📚🫶 the "normative" ones are the load-bearing stuff, so no skipping!
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for
IPSEC Data Flows", RFC 2207, September 1997.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC
2750, January 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation
Protocol (RSVP) Extension for the Reduction of
Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency
Telecommunications Service (ETS) for Real-Time
Services in the Internet Protocol Suite", RFC 4542,
May 2006.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
and M. Davenport, "Generic Aggregate Resource
ReSerVation Protocol (RSVP) Reservations", RFC 4860,
May 2007.6.2. Informative References
these ones are the extra-credit reading 🎀 not strictly required, but they give you the whole backstory and I'm obsessed with them ✨
[ITU.MLPP.1990] International Telecommunications Union, "Multilevel
Precedence and Preemption Service", ITU-T
Recommendation I.255.3, 1990.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December
1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January
2000.
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub
Application Identity Policy Element for Use with
RSVP", RFC 2872, June 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 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.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session
Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA
assignments for Generalized MultiProtocol Label
Switching (GMPLS) Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) Usage and Extensions
for Automatically Switched Optical Network (ASON)",
RFC 3474, March 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.Authors' Addresses 🌸
meet the people who wrote this 🫶 Fred Baker and Pratik Bose, with their contact details exactly as they're listed:
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Pratik Bose
Lockheed Martin
700 North Frederick Ave
Gaithersburg, Maryland 20871
USA
Phone: +1-301-240-7041
Fax: +1-301-240-5748
EMail: pratik.bose@lmco.comFull Copyright Statement 💅
so the legal bit, and it's giving very official 💀 The IETF Trust holds the copyright on this document (2007 🗓️). It's governed by the rights, licenses and restrictions in BCP 78, and beyond what's set out there, the authors keep all their rights.
the warranty disclaimer is in all caps (no cap, it's loud), so here it is word for word:
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🦋
the IETF doesn't take a side on whether any IP rights claimed around this tech are valid or how far they reach, and it also doesn't claim it went looking for them 🙈 If you want the rules for rights in RFCs, check BCP 78 and BCP 79.
if you want copies of IPR disclosures sent to the IETF Secretariat, or the licensing assurances people have filed (or the results of anyone trying to get a general license or permission to use the rights), grab them from the IETF's online IPR repository at http://www.ietf.org/ipr.
and if you spot any copyrights, patents, patent applications, or other proprietary rights that might cover tech you need to implement this standard, tell the IETF at ietf-ipr@ietf.org 📨
Acknowledgement 🎀
the RFC Editor function is currently funded by the Internet Society. Thank you, Internet Society 🌈👑
📦 where this page comes from
- ietf: rfc4923 2007-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms