idnits 2.17.1 draft-ietf-tsvwg-vpn-signaled-preemption-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1620. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 26, 2006) is 6421 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ITU.MLPP.1990' is defined on line 1478, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-tsvwg-rsvp-ipsec-01 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational P. Bose 5 Expires: March 30, 2007 Lockheed Martin 6 September 26, 2006 8 QoS Signaling in a Nested Virtual Private Network 9 draft-ietf-tsvwg-vpn-signaled-preemption-01 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 30, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Some networks require communication between an interior and exterior 43 portion of a VPN, but have sensitivities about what information is 44 communicated across the boundary. This note seeks to outline the 45 issues and the nature of the proposed solutions. 47 Table of Contents 49 1. QoS in a nested VPN . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Nested VPNs . . . . . . . . . . . . . . . . . . . . . . . 5 51 1.2. Signaled QoS technology . . . . . . . . . . . . . . . . . 7 52 1.3. The Resource Reservation Protocol (RSVP) . . . . . . . . . 8 53 1.4. Logical structure of a VPN Router . . . . . . . . . . . . 10 55 2. Reservation and Preemption in a nested VPN . . . . . . . . . . 13 56 2.1. Reservation in a nested VPN . . . . . . . . . . . . . . . 14 57 2.2. Preemption in a nested VPN . . . . . . . . . . . . . . . . 16 58 2.3. Working through an example . . . . . . . . . . . . . . . . 17 59 2.3.1. Initial routine reservations - generating network 60 state . . . . . . . . . . . . . . . . . . . . . . . . 18 61 2.3.2. Initial routine reservations - request reservation . . 19 62 2.3.3. Installation of a reservation using precedence . . . . 20 63 2.3.4. Installation of a reservation using preemption . . . . 21 65 3. Data flows within a VPN Router . . . . . . . . . . . . . . . . 24 66 3.1. VPN Routers that carry data across the cryptographic 67 boundary . . . . . . . . . . . . . . . . . . . . . . . . . 24 68 3.1.1. Plaintext to Ciphertext Data Flows . . . . . . . . . . 24 69 3.1.2. Ciphertext to Plaintext Data Flows . . . . . . . . . . 26 70 3.2. VPN Routers that use the Network Guard for signaling 71 across the cryptographic boundary . . . . . . . . . . . . 27 72 3.2.1. Signaling Flow . . . . . . . . . . . . . . . . . . . . 28 73 3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 35 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 36 85 1. QoS in a nested VPN 87 More and more networks wish to guarantee secure transmission of IP 88 traffic across public LANs or WANs and therefore use Virtual Private 89 Networks. Some networks require communication between an interior 90 and exterior portion of a VPN, but have sensitivities about what 91 information is communicated across the boundary. This note seeks to 92 outline the issues and the nature of the proposed solutions. The 93 outline of the QoS solution for real-time traffic has been described 94 at a high level in [RFC4542]. The key characteristics of this 95 proposal are that 97 o it uses standardized protocols, 99 o It includes reservation setup and teardown for guaranteed and 100 controlled load services using the standardized protocols, 102 o it is independent of link delay, and therefore consistent with 103 high delay*bandwidth networks as well as the more common variety, 105 o it has no single point of failure, such as a central reservation 106 manager, 108 o It provides for the preemption of established data flows, 110 o In that preemption, it not only permits a policy-admitted data 111 flow in, but selects a specific data flow to exclude based upon 112 control input rather than simply accepting a loss of service 113 dictated at the discretion of the network control function, and 115 o interoperates directly with SIP Proxies, H.323 Gatekeepers, or 116 other call management subsystems to present the other services 117 required in a preemptive or preferential telephone network. 119 The thrust of the memo surrounds VPNs that use encryption in some 120 form, such as IPsec. As a result, we will discuss the VPN Router 121 supporting "plaintext" and "ciphertext" interfaces. However, the 122 concept extends readily to any form of aggregation, including the 123 concept proposed in [RFC3175] of the IP traffic entering and leaving 124 a network at identified points, and the use of other kinds of tunnels 125 including GRE, IP/IP, MPLS, and so on. 127 A note on the use of the words "priority" and "precedence" in this 128 document is in order. The term "priority" has been used in this 129 context with a variety of meanings, resulting in a great deal of 130 confusion. The term "priority" is used in this document to identify 131 one of several possible datagram scheduling algorithms. A scheduler 132 is used when deciding which datagram will be sent next on a computer 133 interface; a priority scheduler always chooses a datagram from the 134 highest priority class (queue) that is occupied, shielding one class 135 of traffic from most of the jitter by passing jitter it would 136 otherwise have experienced to another class. [RFC3181] applies the 137 term to a reservation, in a sense that this document will refer to as 138 "precedence". The term "precedence" is used in the sense implied in 139 the phrase "Multi-Level Precedence and Preemption"[ITU.MLPP.1990] ; 140 some classes of sessions take precedence over others, which may 141 result in bandwidth being admitted that might not otherwise have been 142 or may result in the prejudicial termination of a lower precedence 143 session under a stated set of circumstances. For the purposes of the 144 present discussion, "priority" is a set of algorithms applied to 145 datagrams, where "precedence" is a policy attribute of sessions. The 146 techniques of priority comparisons are used in a router or a policy 147 decision point to implement precedence, but they are not the same 148 thing. 150 Along the same lines, it is important for the reader to understand 151 the difference between QoS policies and policies based on the 152 "precedence" or "importance" of data to the person or function using 153 it. Voice, regardless of the precedence level of the call, is 154 impeded by high levels of variation in network-induced delay. As a 155 result, voice is often serviced using a priority queue, transferring 156 jitter from that application's traffic to other applications. This 157 is as true of voice for routine calls as it is for flash traffic. 158 There are classes of application traffic that require bounded delay. 159 That is a different concept than "no jitter"; they can accept jitter 160 within stated bounds. Routing protocols such as OSPF or BGP are 161 critical to the correct functioning of network infrastructure. While 162 they are designed to work well with moderate loss levels, they are 163 not helped by them, and even a short period of high loss can result 164 in dramatic network events. Variation in delay, however, is not at 165 all an issue if it is within reasonable bounds. As a result, it is 166 common for routers to treat routing protocol datagrams in a way that 167 limits the probability of loss, accepting relatively high delay in 168 some cases, even though the traffic is absolutely critical to the 169 network. Telephone call setup exchanges have this characteristic as 170 well: faced with a choice between loss and delay, protocols like SIP 171 and H.323 far prefer the latter, as the call setup time is far less 172 than it would be if datagrams had to be retransmitted, and this is 173 true regardless of whether the call is routine or of high precedence. 174 As such, QoS markings tell us how to provide good service to an 175 application independent of how "important" it may be at the current 176 time, while "importance" can be conveyed separately in many cases. 178 1.1. Nested VPNs 180 One could describe such a network in terms of three network diagrams. 181 Figure 1 shows a simple network stretched across a VPN connection. 182 The VPN Router (where, following [RFC2460] a "router" is "a node that 183 forwards packets not explicitly addressed to itself"), performs the 184 following steps: it 186 o receives an IP datagram from a plain text interface, 188 o determines what remote enclave and therefore other VPN Router to 189 forward it to, 191 o ensures that it has a tunnel mode security association (as 192 generally defined in [RFC2401] section 4) with that router, 194 o encloses the encrypted datagram within another VPN (e.g. IPsec) 195 and IP header, and 197 o forwards the encapsulated datagram toward the remote VPN Router. 199 The receiving VPN Router reverses the steps: it 201 o determines what security association the datagram was received 202 from, 204 o decrypts the interior datagram, 206 o forwards the now-decapsulated datagram on a plain text interface. 208 The use of IPsec in this manner is described as the tunnel mode of 209 [RFC2401] and [RFC4303]. 210 Host Host Host Host Host Host 211 /------------------/ /------------------/ 212 Router -------Router 213 | 214 VPN-Router 215 || 216 || IPsec Tunnel through routed network 217 || 218 VPN-Router 219 | 220 Router -------Router 221 /------------------/ /------------------/ 222 Host Host Host Host Host Host 224 Figure 1: VPN-connected enclave 226 An important point to understand is that the VPN tunnel, like other 227 features of the routed network, are invisible to the host. The host 228 can infer that "something out there" is affecting the Path MTU, 229 introducing delay, or otherwise affecting its data stream, but if 230 properly implemented it should be able to adapt to these. The words 231 "if properly implemented" are the bane of every network manager, 232 however; substandard implementations do demonstrably exist. 234 Outside of the enclave, the hosts are essentially invisible. The 235 communicating enclaves look like a simple data exchange between peer 236 hosts across a routed network, as shown in Figure 2. 238 VPN-Router | Router | VPN-Router 240 Figure 2: VPN-connected enclave from exterior perspective 242 Such networks can be nested and re-used in a complex manner. As 243 shown in Figure 3 a pair of enclaves might communicate across a 244 cipher text network which, for various reasons, is itself re- 245 encrypted and transmitted across a larger cipher text network. The 246 reasons for doing this vary, but they relate to information-hiding in 247 the wider network, different levels of security required for 248 different enclosed enclaves, and so on. 250 Host Host Host Host Host Host 251 /------------------/ /------------------/ 252 Router -------Router 253 | 254 VPN-Router VPN-Router VPN-Router 255 /---------------------/ /----------/ 256 Router -------------Router 257 | 258 VPN-Router VPN-Router 259 /-----------/ /----------/ 260 Router -------Router 261 | 262 | 263 Router -------Router 264 /-----------/ /----------/ 265 VPN-Router VPN-Router 266 | 267 Router ------------Router 268 /---------------------/ /----------/ 269 VPN-Router VPN-Router VPN-Router 270 | 271 Router -------Router 272 /------------------/ /------------------/ 273 Host Host Host Host Host Host 275 Figure 3: Nested VPN 277 The key question this document explores is "how do reservations, and 278 preemption of reservations, work in such an environment?" 280 1.2. Signaled QoS technology 282 The Integrated Services model for networking was originally proposed 283 in [RFC1633]. In short, it divides all applications into two broad 284 classes: those that will adapt themselves to any available bandwidth, 285 and those that will not or cannot. In its own words, 287 One class of applications needs the data in each packet by a 288 certain time and, if the data has not arrived by then, the data 289 is essentially worthless; we call these "real-time" 290 applications. Another class of applications will always wait 291 for data to arrive; we call these "elastic" applications. 293 The Integrated Services model defines data flows supporting 294 applications as either "real-time" or "elastic". It should be noted 295 that "real-time" traffic is also referred to as "inelastic" traffic, 296 and that elastic traffic is occasionally referred to as "non-real- 297 time." 298 In this view, the key issue is the so-called "playback point": a 299 real-time application is considered to have a certain point in time 300 at which data describing the next sound, picture, or whatever to be 301 delivered to a display device or forfeit its utility, while an 302 elastic application has no such boundary. Another way to look at the 303 difference is that real-time applications have an irreducible lower 304 bound on their bandwidth requirements. For example, the typical 305 G.711 payload is delivered in 160 byte samples (plus 40 bytes of IP/ 306 UDP/RTP headers) at 20 millisecond intervals. This will yield 80 307 KBPS of bandwidth, without silence suppression, and not accounting 308 for the layer 2 overhead. To operate in real-time, a G.711 codec 309 requires the network over which its data will be delivered to support 310 communications at 80 KBPS at the IP layer with roughly constant end 311 to end delay and nominal or no loss. If this is not possible (if 312 there is significant loss or wide variations in delay), voice quality 313 will suffer. On the other hand, if many megabits of capacity are 314 available, the G.711 codec will not increase its bandwidth 315 requirements either. Although adaptive codecs exist, (e.g., G.722.2 316 or G.726), the adaptive mechanism can either require greater or 317 lesser bandwidth and can adapt only within a certain range of 318 bandwidth requirements beyond which the quality of the data flow 319 required is not met. Elastic applications, however, will generally 320 adapt themselves to any network: if the bottleneck provides 9600 bits 321 per second, a web transfer or electronic mail exchange will happen at 322 9600 bits per second, and if hundreds of megabits are available, the 323 TCP (or SCTP) transport will increase their transfer rate in an 324 attempt to reduce the time required to accomplish the transfer. 326 For real-time applications, those that require data to be delivered 327 end to end with at least a certain rate and with delays varying 328 between stated bounds, the Integrated Services architecture proposes 329 the use of a signaling protocol that allows the communicating 330 applications and the network to communicate about the application 331 requirements and the network's capability to deliver them. Several 332 such protocols have been developed or are under development, notably 333 including RSVP and NSIS. The present discussion is limited to RSVP, 334 although any protocol that delivers a similar set of capabilities 335 could be considered. 337 1.3. The Resource Reservation Protocol (RSVP) 339 RSVP is initially defined in [RFC2205] with a set of datagram 340 processing rules defined in [RFC2209] and datagram details for 341 Integrated Services [RFC2210]. Conceptually, this protocol specifies 342 a way to identify data flows from a source application to a 343 destination application and request specific resources for them. The 344 source may be a single machine or a set of machines listed explicitly 345 or implied, whereas the destination may be a single machine or a 346 multicast group (and therefore all of the machines in it). Each 347 application is specified by a transport protocol number in the IP 348 protocol field, or may additionally include destination and perhaps 349 source port numbers. The protocol is defined for both IPv4 [RFC0791] 350 and IPv6 [RFC2460]. It was recognized immediately that it was also 351 necessary to provide a means to perform the same function for various 352 kinds of tunnels, which implies a relationship between what is inside 353 and what is outside the tunnel. Definitions were therefore developed 354 for IPsec [RFC2207] and [I-D.ietf-tsvwg-rsvp-ipsec] and for more 355 generic forms of tunnels [RFC2746]. With the later development of 356 the Differentiated Services Architecture [RFC2475], definitions were 357 added to specify the DSCP [RFC2474] to be used by a standard RSVP 358 data flow in [RFC2996] and to use a pair of IP addresses and a DSCP 359 as the identifying information for a data flow [RFC3175]. 361 In addition, the initial definition of the protocol included a 362 placeholder for policy information, and for preemption of 363 reservations. This placeholder was later specified in detail in 364 [RFC2750] with a view to associating a policy [RFC2872] with an 365 identity [RFC3182] and thereby enabling the network to provide a 366 contracted service to an authenticated and authorized user. This was 367 integrated with the Session Initiation Protocol [RFC3261] in 368 [RFC3312]. Preemption of a reservation is specified in the context, 369 in [RFC3181] which in essence specifies that a reservation installed 370 in the network using an Preemption Priority and retained using a 371 separate Defending Priority may be removed by the network via an RESV 372 Error signal that removes the entire reservation. This has issues, 373 however, in that the matter is often not quite so black and white. 374 If the issue is that an existing reservation for 80 KBPS can no 375 longer be sustained but a 60 KBPS reservation could, it is possible 376 that a VoIP sender could change from a G.711 codec to a G.729 codec 377 and achieve that. Or, if there are multiple sessions in a tunnel or 378 other aggregate, one of the calls could be eliminated leaving 379 capacity for the others. [RFC4495] seeks to address this issue. 381 In a similar way, a capability was added to limit the possibility of 382 control signals being spoofed or otherwise attacked [RFC2747] 383 [RFC3097]. 385 [RFC3175] describes several features that are unusual in RSVP, being 386 specifically set up to handle aggregates in a service provider 387 network. It describes three key components: 389 o The RFC 3175 session object, which identifies not the IP addresses 390 of the packets that are identified, but the IP addresses of the 391 ingress and egress devices in the network, and the DSCP that the 392 traffic will use, 394 o The function of a reservation "aggregator", which operates in the 395 ingress router and accepts individual reservations from the 396 "customer" network which it aggregates into the ISP core in a 397 tunnel, an MPLS LSP, or as a traffic stream that it known to leave 398 at the deaggregator, 400 o The function of a reservation "deaggregator", which operates in 401 the egress router and breaks the aggregate reservation and data 402 streams back out into individual data streams that may be passed 403 to other networks. 405 In retrospect, the Session Object specified by RFC 3175 is useful but 406 not intrinsically necessary. If the ISP network uses tunnels, such 407 as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security 408 Associations, the concepts of an aggregator and a deaggregator work 409 in the same manner, although the reservation mechanism would be that 410 of [RFC3473] and [RFC3474] [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or 411 [RFC2746]. 413 1.4. Logical structure of a VPN Router 415 The conceptual structure of a VPN Router is similar to that of any 416 other router. In its simplest form, it is physically a two or more 417 port device, similar to that shown in Figure 4 which has one or more 418 interfaces to the protected enclave(s) and one or more interfaces to 419 the outside world. On the latter, it structures some number of 420 tunnels (in the case of an IPsec tunnel, having security 421 associations) that it can treat as point to point interfaces from a 422 routing perspective. 424 +---------+ +-------+ +----+----+ +---------+ 425 | RSVP | |Routing| |Net Guard| |IPsec Mgr| 426 +----+----+ +---+---+ +----+----+ +----+----+ 427 | | | | 428 +----+-----------+------------+-----------------+----+ 429 | IP | 430 +-----------+--------------------+------------+------+ 431 | | | 432 | +-----+-----+ +----+------+ 433 | | Encrypt/ | | Encrypt/ | 434 | |Decrypt for| |Decrypt for| 435 | | Security | | Security | 436 | |Association| |Association| 437 | +-----+-----+ +----+------+ 438 | | | 439 +-----------+------------+ +-----+------------+------+ 440 | Plain text | | Cipher text | 441 | Interface | | Interface | 442 +------------------------+ +-------------------------+ 444 Figure 4: Logical structure of a VPN Router 446 The encrypt/decrypt unit may be implemented as a function of the 447 plain text router, as a function on its interface card, or as a 448 function of an external device with a private interface to the IP 449 routing functionality of the plain text router. These are 450 conceptually equivalent, although there are practical differences in 451 implementation. The key issue is that when IP routing presents a 452 message to the encrypt/decrypt unit for transmission, it must also be 453 presented with the IP address of the plain text routing peer, whether 454 host or router, to which the security association must be 455 established. This IP Address is used to select (and perhaps create) 456 the security association, and in turn select the appropriate set of 457 security parameters. This could also be implemented by presenting 458 the local Security Parameter Index (SPI) for the data, if it has been 459 created out of band by the Network Management Process. 461 In addition, it is necessary for aggregated signaling to be generated 462 for the cipher text domain. This may be accomplished in several 463 ways: 465 o by having the RSVP process on the plain text router generate the 466 messages and having the encrypt/decrypt unit bypass them into the 467 cipher text network 469 o by having the plain text RSVP Process advise a process in the 470 encrypt/decrypt implementation of what needs to be generated using 471 some local exchange, and having it generate such messages, or 473 o by having a separate parallel network management system 474 intermediate between the plain text and cipher text routers, in 475 which case the encrypt/decrypt unit and the parallel network 476 system must use the same address and the cipher text router must 477 distinguish between traffic for them based on SPI or the presence 478 of encryption. 480 Control plane signaling using this additional path is described in 481 Section 3.2. The information flow between the plain text and cipher 482 text domains includes 484 o IP datagrams via the encrypt/decrypt unit, 486 o RSVP signaling via the bypass path, 488 o Control information coordinating security associations, and 490 o precious little else. 492 2. Reservation and Preemption in a nested VPN 494 / \ 495 ( +--+ +--+ enclave ) ,---------. 496 .----------. \ |H2+---+R2| / ,-' ` 497 +--+ +--+`--.\ +--+ ++-+ / / +--+ +--+ 498 |H1+---+R1| \`. | ,' / |R3+---+H3| 499 +--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+ 500 | / _.`---|VPN2||''-. \ | 501 enclave +----+-i.--'' +----++ `----.\ +----+ enclave 502 --------|VPN1|' | ``|VPN3| , 503 ,+----+ | +----+------' 504 ,' --+-------+----------+------------------+---`. 505 ,' ++-+ `. 506 ,' |R7+--------+ `. 507 / interface +--+ | \ 508 domain 1 +-+--+ \ 509 _.--------|VPN7|--------. 510 ,-----'' +--+-+ `------. . 511 `-. ,-' | `-. .-' 512 `-: inner domain +-++ `.' 513 ( |R9| ) 514 .'. ++-+ ;-. 515 .' `-. | ,-' `-. 516 ' `------. +-+--+ _.-----' ` 517 interface `---------|VPN8|-------'' 518 domain 2 +-+--+ / 519 \ | +--+ / 520 `. +----------+R8| ,' 521 `. ++-+ ,' 522 `. --+------------------+-----------+------+-- ,' 523 ,-----+----+ | +----+------. 524 ,' |VPN6|. | _.|VPN4| ` 525 +----+.`----. +----+ _.--'' ,+----+ 526 | \ `--=.-|VPN5|---:' / | 527 +--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+ 528 |H6+---+R6| | ,' | `.| |R4+---+H4| 529 +--+ +--+ ;/ +--+ ++-+ : +--+ +--+ 530 // |H5+---+R5| \ 531 enclave ,'( +--+ +--+ `. enclave 532 `. ,' \ enclave / '-. , 533 `-------' \ / `-------' 535 Figure 5: Reservations in a nested VPN 537 Let us discuss how a resource reservation protocol, and specifically 538 RSVP, might be used in a nested virtual private network. 540 2.1. Reservation in a nested VPN 542 A reservation in a nest VPN is very much like a reservation in any 543 other network, with one exception: it is composed of multiple 544 reservations that must be coordinated. These include a reservation 545 within the originating and receiving enclaves and a reservation at 546 each layer of the VPN, as shown in Figure 5. 548 Thus, when a host in one enclave opens a reservation to a host in 549 another enclave, a reservation of the appropriate type and size is 550 created end to end. As it traverses the VPN Router leaving its 551 enclave, the reservation information and the data are placed within 552 the appropriate tunnel (e. g., the IPsec Security Association for its 553 precedence level to the appropriate remote VPN Router). At the 554 remote VPN Router, it is extracted from the tunnel and passed on its 555 way to the target system. The data in the enclave will be marked 556 with a DSCP appropriate to its application and (if there is a 557 difference) precedence level, and the signaling datagrams (PATH and 558 RESV) are marked with a DCLASS object indicating that value. RSVP 559 signaling datagrams (PATH and RESV) are marked with a DCLASS object 560 indicating the value used for the corresponding data. The DSCP on 561 the signaling datagrams, however, is a DSCP for signaling, and has 562 the one provision that if routing varies by DSCP then it must be a 563 DSCP that is routed the same way as the relevant data. The [RFC2872] 564 policy object specifies the applicable policy (e. g., "routine 565 service for voice traffic") and asserts a [RFC3182] credential 566 indicating its user (which may be a person or a class of persons). 567 As specified in [RFC3181] it also specifies its Preemption Priority 568 and its Defending Priority; these enable the Preemption Priority of a 569 new session to be compared with the Defending Priority of previously 570 admitted sessions. 572 On the cipher text side of the VPN Router, no guarantees result 573 unless the VPN Router likewise sets up a reservation to the peer VPN 574 Router across the cipher text domain. Thus, the VPN Router sets up 575 an [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or [RFC3175] reservation to 576 its peer. 578 The Session Object defined by [RFC2207] or 579 [I-D.ietf-tsvwg-rsvp-ipsec] contains a field called a "virtual 580 destination port", which allows the multiplexing of many reservations 581 over a common security association, and in the latter case, a common 582 DSCP value. Thus, the voice traffic at every precedence level might 583 use the EF DSCP and service as described in [RFC3246], but the 584 reservations would be for "the aggregate of voice sessions at 585 precedence Pn between these VPN Routers". This would allow the 586 network administration to describe policies with multiple thresholds, 587 such as "a new session at precedence Pn may be accepted if the total 588 reserved bandwidth does not exceed threshold Qn; if it is necessary 589 and sufficient to accept the reservation, existing reservations at 590 lower precedences may be preemptively reduced to make acceptance of 591 the new session possible." 593 In the [RFC3175] case, since the DSCP must be used to identify both 594 the reservation and the corresponding data stream, the aggregate 595 reservations for different precedence levels require different DSCP 596 values. 598 In either case, the fundamental necessity is for one VPN Router to 599 act as what [RFC3175] calls the "aggregator" and another to act as 600 the "deaggregator", and extend a VPN tunnel between them. If the VPN 601 Tunnel is an IPsec Security Association between the VPN Routers and 602 the IP packet is entirely contained within (such as is used to cross 603 a firewall), then the behavior of [RFC2746] is required of the 604 tunnel. That bearer will have the following characteristics: 606 o it will have a DSCP corollary or the same as the DSCP for the data 607 it carries, 609 o the reservations and data will be carried in security associations 610 between the VPN Routers, and 612 o the specification for the reservation for the tunnel itself will 613 not be less than the sum of the requirements of the aggregated 614 reservations. 616 The following requirements relationships apply between the set of 617 enclosed reservations and the tunnel reservation: 619 o The sum of the average rates of the contained reservations, having 620 been adjusted for the additional IP headers, will be less than or 621 equal to the average rate of the tunnel reservation. 623 o The sum of the peak rates of the contained reservations, having 624 been adjusted for the additional IP headers, will be less than or 625 equal to the peak rate of the tunnel reservation. 627 o The sum of the burst sizes of the contained reservations, having 628 been adjusted for the additional IP headers, will be less than or 629 equal to the burst size of the tunnel reservation. 631 o The Preemption Priority of a tunnel reservation is identical to 632 that of the individual reservations it aggregates. 634 o The Defending Priority of a tunnel reservation is identical to 635 that of the individual reservations it aggregates. 637 This would differ only in the case that measurement-based admission 638 is in use in the tunnel but not in the end system. In that case, the 639 tunnel's average bandwidth specification would be greater than or 640 equal to the actual average offered traffic. Such systems are beyond 641 the scope of this specification. 643 As a policy matter, it may be useful to note a quirk in the way 644 Internet QoS works. If the policies for various precedence levels 645 specify different thresholds (e. g., "to accept a new routine call, 646 the total reserved bandwidth after admission may not exceed X; to 647 accept a higher precedence level call, the total reserved bandwidth 648 after admission may not exceed X+Y, and this may be achieved by 649 preempting a lower precedence level call"), the bandwidth Y 650 effectively comes from the bandwidth in use by elastic traffic rather 651 than forcing a preemption event. 653 2.2. Preemption in a nested VPN 655 As discussed in Section 1.3 preemption is specified in [RFC3181] and 656 further addressed in [RFC4495]. The issue is that in many cases the 657 need is to reduce the bandwidth of a reservation due to a change in 658 the network, not simply to remove the reservation. In the case of an 659 end system originated reservation, the end system might be able to 660 accommodate the need through a change of codec; in the case of an 661 aggregate of some kind, it could reduce the bandwidth it is sending 662 by dropping one or more reservations entirely. 664 In a nested VPN or other kind of aggregated reservation, this means 665 that the deaggregator (the VPN Router initiating the RESV signal for 666 the tunnel) must 668 o receive the RESV Error signaling it to reduce its bandwidth, 670 o re-issue its RESV accordingly, 672 o identify one or more of its aggregated reservations, enough to do 673 the job, and 675 o signal them to reduce their bandwidth accordingly. 677 It is possible, of course, that it is signaling them to reduce their 678 bandwidth to zero, which is functionally equivalent to removing the 679 reservation as described in [RFC3181]. 681 In the routers in the core, an additional case arises. One could 682 imagine that some enclave presents the VPN with a single session, and 683 that session has a higher precedence level. If some interior link is 684 congested (e. g., the reserved bandwidth will exceed policy if the 685 call is admitted), a session between a different pair of VPN Routers 686 must be preempted. More generally, in selecting a reservation to 687 preempt, the core router must always select a reservation at the 688 lowest available Defending Priority. This is the reason that various 689 precedence levels must be kept separate in the core. 691 2.3. Working through an example 693 The network in Figure 5 shows three security layers: six plain text 694 enclaves around the periphery, two cipher text domains connecting 695 them at one layer (referred to in the diagram as an "interface 696 domain"), and a third cipher text domain connecting the first two 697 (referred to in the diagram as an "inner domain"). The following 698 distribution of information exists: 700 o Each enclave has access to general routing information concerning 701 other enclaves it is authorized to communicate with: systems in it 702 can translate a DNS name for a remote host or domain and obtain 703 the corresponding address or prefix. 705 o Each enclave router also has specific routing information 706 regarding its own enclave. 708 o A default route is distributed within the enclave, pointing to its 709 VPN Router. 711 o VPN Routers 1-6 are able to translate remote enclave prefixes to 712 the appropriate remote enclave's VPN Router addresses. 714 o Each interface domain has access to general routing information 715 concerning the other interface domains, but not the enclaves. 716 Systems in an interface domain can translate a DNS name for a 717 remote interface domain and obtain the corresponding address or 718 prefix. 720 o Each interface domain router also has specific routing information 721 regarding its own interface domain. 723 o A default route is distributed within the interface domain, 724 pointing to the "inner" VPN Router. 726 o VPN Routers 7 and 8 are able to translate remote interface domain 727 prefixes to remote VPN Router addresses. 729 o Routers in the inner domain have routing information for that 730 domain only. 732 While the example shows three levels, there is nothing magic about 733 the number three. The model can be extended to any number of 734 concentric layers. 736 Note that this example places unidirectional reservations in the 737 forward direction. In voice and video applications, one generally 738 has a reservation in each direction. The reverse direction is not 739 discussed, for the sake of clarity, but operates in the same way in 740 the reverse direction and uses the same security associations. 742 2.3.1. Initial routine reservations - generating network state 744 Now let us install a set of reservations from H1 to H4, H2 to H5, and 745 H3 to H6, and for the sake of argument let us presume that these are 746 at the "routine" precedence. H1, H2, and H3 each initiate an PATH 747 signal describing their traffic. For the sake of argument, let us 748 presume that H1's reservation is for an [RFC2205] session, H2's 749 reservation is for a session encrypted using IPsec, and therefore 750 depends on [RFC2207] and H3 (which is a PSTN Gateway) sends an 751 [RFC3175] reservation comprising a number of distinct sessions. 752 Since these are going to H4, H5, and H6 respectively, the default 753 route leads them to VPN1, VPN2, and VPN3 respectively. 755 The VPN Routers each ensure that they have an appropriate security 756 association or tunnel open to the indicated remote VPN Router (VPN4, 757 VPN5, or VPN6). This will be a security association or tunnel for 758 the indicated application at the indicated precedence level. Having 759 accomplished that, it will place the PATH signal into the security 760 association and forward it. If such does not already exist, 761 following [RFC3175] 's aggregation model, it will now open a 762 reservation (send a PATH signal) for the tunnel/SA within the 763 interface domain; if the reservation does exist, the VPN Router will 764 increase the bandwidth indicated in the ADSPEC appropriately. In 765 this example, these tunnel/SA reservations will follow the default 766 route to VPN7. 768 VPN7 ensures that it has an appropriate security association or 769 tunnel open to VPN8. This will be a security association or tunnel 770 for the indicated application at the indicated precedence level. 771 Having accomplished that, it will place the PATH signal into the 772 security association and forward it. If such does not already exist, 773 following [RFC3175] 's aggregation model, it will now open a 774 reservation (send a PATH signal) for the tunnel/SA within the 775 interface domain; if the reservation does exist, the VPN Router will 776 increase the bandwidth indicated in the ADSPEC appropriately. In 777 this example, this tunnel/SA reservation is forwarded to VPN8. 779 VPN8 acts as an [RFC3175] deaggregator for the inner domain. This 780 means that it receives the PATH signal for the inner domain 781 reservation and stores state, decrypts the data stream from VPN7, 782 operates on the RSVP signals as an RSVP-configured router, and 783 forwards the received IP datagrams (including the updated PATH 784 signals) into its interface domain. The PATH signals originated by 785 VPN1, VPN2, and VPN3 are therefore forwarded towards VPN4, VPN5, and 786 VPN6 according to the routing of the interface domain. 788 VPN4, VPN5, and VPN6 each act as an [RFC3175] deaggregator for the 789 interface domain. This means that it receives the PATH signal for 790 the interface domain reservation and stores state, decrypts the data 791 stream from its peer, operates on the RSVP signals as an RSVP- 792 configured router, and forwards the received IP datagrams (including 793 the updated PATH signals) into its enclave. The PATH signals 794 originated by H1, H2, and H3 are therefore forwarded towards H4, H5, 795 and H6 according to the routing of the enclave. 797 H4, H5, and H6 now receive the original PATH signals and deliver them 798 to their application. 800 2.3.2. Initial routine reservations - request reservation 802 The application in H4, H5, and H6 decides to install the indicated 803 reservations, meaning that they now reply with RESV signals. These 804 signals request the bandwidth reservation. Following the trail left 805 by the PATH signals, the RESV signals traipse back to their 806 respective sources. The state left by the PATH signals leads them to 807 VPN4, VPN5, and VPN6 respectively. If the routers in the enclaves 808 are configured for RSVP, this will be explicitly via R4, R5, or R6; 809 if they are not, routing will lead them through those routers. 811 The various RSVP-configured routers en route in the enclave 812 (including the VPN Router on the "enclave" side) will verify that 813 there is sufficient bandwidth on their links and that any other 814 stated policy is also met. Having accomplished that, each will 815 update its reservation state and forward the RESV signal to the next. 816 The VPN Routers will also each generate an RESV for the reservation 817 within the interface domain, attempting to set or increase the 818 bandwidth of the reservation appropriately. 820 The various RSVP-configured routers en route in the interface domain 821 (including VPN8) will verify that there is sufficient bandwidth on 822 their links and that any other stated policy is also met. Having 823 accomplished that, each will update its reservation state and forward 824 the RESV signal to the next. VPN8 will also generate an RESV for the 825 reservation within the inner domain, attempting to set or increase 826 the bandwidth of the reservation appropriately. This gets the 827 reservation to the inner deaggregator, VPN8. 829 The various RSVP-configured routers en route in the inner domain 830 (including VPN7) will verify that there is sufficient bandwidth on 831 their links and that any other stated policy is also met. Having 832 accomplished that, each will update its reservation state and forward 833 the RESV signal to the next. This gets the signal to VPN7. 835 VPN7 acts as an [RFC3175] aggregator for the inner domain. This 836 means that it receives the RESV signal for the inner domain 837 reservation and stores state, decrypts the data stream from VPN8, 838 operates on the RSVP signals as an RSVP-configured router, and 839 forwards the received IP datagrams (including the updated RESV 840 signals) into its interface domain. The RESV signals originated by 841 VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, and 842 VPN3 through the interface domain. 844 VPN1, VPN2, and VPN3 each act as an [RFC3175] aggregator for the 845 interface domain. This means that it receives the RESV signal for 846 the interface domain reservation and stores state, decrypts the data 847 stream from its peer, operates on the RSVP signals as an RSVP- 848 configured router, and forwards the received IP datagrams (including 849 the updated RESV signals) into its enclave. The RESV signals 850 originated by H4, H5, and H6 are therefore forwarded towards H1, H2, 851 and H3 according to the routing of the enclave. 853 H1, H2, and H3 now receive the original RESV signals and deliver them 854 to their application. 856 2.3.3. Installation of a reservation using precedence 858 Without going through the details called out in Section 2.3.1 and 859 Section 2.3.2 if sufficient bandwidth exists to support them, 860 reservations of other precedence levels or other applications may 861 also be installed across this network. If the "routine" reservations 862 already described are for voice, for example, and sufficient 863 bandwidth is available under the relevant policy, a reservation for 864 voice at the "priority" precedence level might be installed. Due to 865 the mechanics of preemption, however, this would not expand the 866 existing "routine" reservations in the interface and inner domains, 867 as doing this causes loss of information - how much of the 868 reservation is now "routine" and how much is "priority"? Rather, 869 this new reservation will open up a separate set of tunnels or 870 security associations for traffic of its application class at its 871 precedence between that aggregator and deaggregator. 873 As a side note, there is an opportunity here that does not exist in 874 the PSTN. In the PSTN, all circuits are potentially usable by any 875 PSTN application under a certain set of rules (H channels, such as 876 are used by video streams, must be contiguous and ordered). As such, 877 if a channel is not made available to routine traffic but is made 878 available to priority traffic, the operator is potentially losing 879 revenue on the reserved bandwidth and deserves remuneration. 880 However, in the IP Internet, some bandwidth must be kept for basic 881 functions such as routing, and in general policies will not permit 882 100% of the bandwidth on an interface to be allocated to one 883 application at one precedence. As a result, it may be acceptable to 884 permit a certain portion (e. g. 50%) to be used by routine voice and 885 a larger amount (e. g. 60%) to be used by voice at a higher 886 precedence level. Under such a policy, a higher precedence 887 reservation for voice might not result in the preemption of a routine 888 call, but rather impact elastic traffic, and might be accepted at a 889 time that a new reservation of lower precedence might be denied. 891 In microwave networks, such as satellite or mobile ad hoc, one could 892 also imagine network management intervention that could change the 893 characteristics of the radio signal to increase the bandwidth under 894 some appropriate policy. 896 2.3.4. Installation of a reservation using preemption 898 So we now have a number of reservations across the network described 899 in Figure 5 including several reservations at "routine" precedence 900 and one at "priority" precedence. For sake of argument, let us 901 presume that the link from VPN7 to R9 is now fully utilized - all of 902 the bandwidth allocated by policy to voice at the routine or priority 903 level has been reserved. Let us further imagine that a new 904 "priority" reservation is now placed from H3 to H6. 906 The process described in Section 2.3.1 is followed, resulting in PATH 907 state across the network for the new reservation. This is installed 908 even though it is not possible to install a new reservation on 909 VPN7-R9, as it does not install any reservation and the network does 910 not know whether H6 will ultimately require a reservation. 912 The process described in Section 2.3.2 is also followed. The 913 application in H6 decides to install the indicated reservation, 914 meaning that it now replies with an RESV signal. Following the trail 915 left by the PATH signal, the RESV signal traipses back towards H3. 916 VPN6 and (if RSVP was configured) R6 verify that there is sufficient 917 bandwidth on their links and that any other stated policy is also 918 met. Having accomplished that, each will update its reservation 919 state and forward the RESV signal to the next. VPN6 also generates 920 an RESV for the reservation within the interface domain, attempting 921 to set or increase the bandwidth of the reservation appropriately. 923 VPN6, R8, and VPN8's "interface domain" side now verify that there is 924 sufficient bandwidth on their links and that any other stated policy 925 is also met. Having accomplished that, each will update its 926 reservation state and forward the RESV signal to the next. VPN8 will 927 also generate an RESV for the reservation within the inner domain, 928 attempting to set or increase the bandwidth of the reservation 929 appropriately. This gets the reservation to the inner deaggregator, 930 VPN8. 932 VPN8's "inner domain" side and R9 now verify that there is sufficient 933 bandwidth on their links and that any other stated policy is also 934 met. At R9, a problem is detected - there is not sufficient 935 bandwidth under the relevant policy. In the absence of precedence, 936 R9 would now return an RESV Error indicating that the reservation 937 could not be increased or installed. In such a case, if a pre- 938 existing reservation of lower bandwidth already existed, the previous 939 reservation would remain in place but the new bandwidth would not be 940 granted, and the originator (H6) would be informed. Let us clarify 941 what it means to be at a stated precedence: it means that the 942 POLICY_DATA object in the RESV contains a Preemption Priority and a 943 Defending Priority with values specified in some memo. With 944 precedence, [RFC4495]'s algorithm would have the Preemption Priority 945 of the new reservation compared to the Defending Priority of extant 946 reservations in the router, of which there are two: one VPN7->VPN8 at 947 "routine" precedence and one VPN7->VPN8 at "priority" precedence. 948 Since the Defending Priority of routine reservation is less than the 949 Preemption Priority of a "priority" reservation, the "routine" 950 reservation is selected. R9 determines that it will accept the 951 increase in its "priority" reservation VPN7->VPN8 and reduce the 952 corresponding "routine" reservation. Two processes now occur in 953 parallel: 955 o The routine reservation is reduced following the algorithms in 956 [RFC4495] and 958 o The priority reservation continues according to the usual rules. 960 R9 reduces its "routine" reservation by sending an RESV Error 961 updating its internal state to reflect the reduced reservation and 962 sending an RESV Error to VPN8 requesting that it reduce its 963 reservation to a number less than or equal to the relevant threshold 964 less the sum of the competing reservations. VPN8, acting as a de- 965 aggregator, makes two changes. On the "inner domain" side, it marks 966 its reservation down to the indicated rate (the most it is now 967 permitted to reserve), so that if an RESV Refresh event happens it 968 will request the specified rate. On the "interface domain" side it 969 selects one or more of the relevant reservations by an algorithm of 970 its choosing and requests that it likewise reduce its rate. For sake 971 of argument, let us imagine that the selected reservation is the one 972 to VPN5. The RESV Error now makes its way through R8 to VPN5, which 973 similarly reduces its bandwidth request to the stated amount and 974 passes a RESV Error signal on the "enclave" side requesting that the 975 reservation be appropriately reduced. 977 H5 is now faced with a decision. If the request is to reduce its 978 reservation to zero, that is equivalent to tearing down the 979 reservation. In this simple case, it sends an RESV Tear to tear down 980 the reservation entirely and advises its application to adjust its 981 expectations of the session accordingly, which may mean shutting down 982 the session. If the request is to reduce it below a certain value, 983 however, it may be possible for the application to do so and remain 984 viable. For example, if a VoIP application using a G. 711 codec (80 985 KBPS) is asked to reduce its bandwidth below 70 KBPS, it may be 986 possible to renegotiate the codec in use to G. 729 or some other 987 codec. In such a case, the originating application should re-reserve 988 at the stated bandwidth (in this case, 70 KBPS), initiate the 989 application level change, and let the application change the 990 reservation again (perhaps to 60 KBPS) when it has completed that 991 process. 993 For the "priority" reservation, at the same time, R9 believes that it 994 has sufficient bandwidth and that any other stated policy is also 995 met, it forwards the RESV to VPN7. Each will update its reservation 996 state and forward the RESV signal to the next. VPN7 now acts as an 997 [RFC3175] aggregator for the inner domain. This means that it 998 receives the RESV signal for the inner domain reservation and stores 999 state, decrypts the data stream from VPN8, operates on the RSVP 1000 signals as an RSVP-configured router, and forwards the received IP 1001 datagrams (including the updated RESV signals) into its interface 1002 domain. The RESV signals originated by VPN4, VPN5, and VPN6 are 1003 therefore forwarded towards VPN1, VPN2, and VPN3 through the 1004 interface domain. 1006 VPN3 now acts as an [RFC3175] aggregator for the interface domain. 1007 This means that it receives the RESV signal for the interface domain 1008 reservation and stores state, decrypts the data stream from its peer, 1009 operates on the RSVP signals as an RSVP-configured router, and 1010 forwards the received IP datagrams (including the updated RESV 1011 signals) into its enclave. The RESV signal originated by H6 is 1012 therefore forwarded towards H3 according to the routing of the 1013 enclave. 1015 H3 now receives the original RESV signals and deliver it to the 1016 relevant application. 1018 3. Data flows within a VPN Router 1020 This section details the data flows within a VPN Router, in the 1021 context of sessions as described in Section 2. 1023 3.1. VPN Routers that carry data across the cryptographic boundary 1025 3.1.1. Plaintext to Ciphertext Data Flows 1026 +-----------------------+ +----------------------+ 1027 | +--------------------+| |+--------------------+| 1028 | |RSVP || ||Aggregate RSVP || 1029 | | || || || 1030 | |Per session: || ID ||Agg. Session || 1031 | | Destination ||--->|| Agg. Destination || 1032 | | Source || || Agg. Source= self || 1033 | | potential SPI || || Agg. SPI generated|| 1034 | | DSCP ---------> DSCP || 1035 | | vPort or protocol---------> vPort || 1036 | | and port || || || 1037 | | Mean rate ---------> Sum of mean rates || 1038 | | Peak rate ---------> f(Peak rates) || 1039 | | Burst Size ---------> Sum of Burst sizes|| 1040 | | || || || 1041 | +--------------------+| |+--------------------+| 1042 | +--------------------+| |+--------------------+| 1043 | | IP || || IP || 1044 | +--------------------+| |+--------------------+| 1045 | +--------------------+| |+--------------------+| 1046 | | Plain text Interface|| ||Cipher text Interface|| 1047 | +--------------------+| |+--------------------+| 1048 +-----------------------+ +----------------------+ 1050 Figure 6: Data Flows in a VPN Router Outbound 1052 Parameters on a reservation include: 1054 Destination Address: On the plain text side, the VPN Router 1055 participates in the end to end reservations being installed for 1056 plain text sessions. These may include individual flows as 1057 described in [RFC2205] IPsec data flows [RFC2207] aggregate 1058 reservations [RFC3175] or other types. It passes an identifier 1059 for the cipher text side of the deaggregator to its cipher text 1060 unit. 1062 DSCP: The DSCP of the plain text data flow is provided to the cipher 1063 text side. 1065 Virtual Port: The virtual destination port is provided to the cipher 1066 text side. This may be derived from an [RFC2207] session object 1067 or from policy information. 1069 Mean Rate: The sum of the plain text mean rates is provided to the 1070 cipher text unit. 1072 Peak Rate: A function of the plain text peak rates is provided to 1073 the cipher text unit. This function is less than or equal to the 1074 sum of the peak rates. 1076 Burst Size: The sum of the burst sizes is provided to the cipher 1077 text unit. 1079 Messages include: 1081 Path: The Plain text PATH message is sent as encrypted data to the 1082 cipher text unit. In parallel, a trigger needs to be sent to the 1083 cipher text unit that results in it generating the corresponding 1084 aggregated PATH message for the cipher text side. 1086 Path Error: This indicates that a PATH message sent to the remote 1087 enclave was in error. In the error case, the message itself is 1088 sent on as encrypted data, but a signal is sent to the cipher text 1089 side in case the error affects the cipher text reservation (such 1090 as removing or changing state). 1092 Path Tear: The PATH Tear message is sent as encrypted data to the 1093 cipher text unit. In parallel, a signal is sent to the cipher 1094 text side which will trigger a Path Tear on its reservation in the 1095 event that this is the last aggregated session, or change the 1096 SENDER_TSPEC of the aggregated session. 1098 RESV: The Plain text RESV message is sent as encrypted data to the 1099 cipher text unit. In parallel, a trigger needs to be sent to the 1100 cipher text unit that results in it generating the corresponding 1101 aggregated RESV message for the cipher text side. 1103 RESV Error: This indicates that a RESV message received as data and 1104 forwarded into the enclave was in error or needed to be preempted 1105 as described in [RFC3181] or [RFC4495]. In the error case, the 1106 message itself is sent on as encrypted data, but a signal is sent 1107 to the cipher text side in case the error affects the cipher text 1108 reservation (such as removing or changing state). 1110 RESV Tear: The RESV Tear message is sent as encrypted data to the 1111 cipher text unit. In parallel, a signal is sent to the cipher 1112 text side which will trigger a RESV Tear on its reservation in the 1113 event that this is the last aggregated session, or reduce the 1114 bandwidth of an existing reservation. 1116 RESV Confirm: This indicates that a RESV message received as data 1117 and forwarded into the enclave, and is now being confirmed. This 1118 message is sent as encrypted data to the cipher text side, and in 1119 parallel a signal is sent to potentially trigger an RESV Confirm 1120 on the aggregate reservation. 1122 3.1.2. Ciphertext to Plaintext Data Flows 1123 +-----------------------+ +----------------------+ 1124 | +--------------------+| |+--------------------+| 1125 | |RSVP || ||Aggregate RSVP || 1126 | | || || terminated || 1127 | |Per session: |+ || || 1128 | | Destination || || || 1129 | | Source <---------Decrypted RSVP || 1130 | | potential SPI || || message sent to || 1131 | | DSCP || || Plain text unit || 1132 | | vPort or protocol || || *as data* for || 1133 | | and port || || normal processing || 1134 | | Mean rate || || || 1135 | | Peak rate || || || 1136 | | Burst Size || || || 1137 | | || || || 1138 | +--------------------+| |+--------------------+| 1139 | +--------------------+| |+--------------------+| 1140 | | IP || || IP || 1141 | +--------------------+| |+--------------------+| 1142 | +--------------------+| |+--------------------+| 1143 | |Plain text Interface|| ||Cipher text Interface|| 1144 | +--------------------+| |+--------------------+| 1145 +-----------------------+ +----------------------+ 1147 Figure 7: Data Flows in a VPN Router Inbound 1149 The aggregate reservation is terminated by the cipher text side of 1150 the VPN Router. The RSVP messages related to the subsidiary sessions 1151 are carried in the encrypted tunnel as data, and therefore arrive at 1152 the plain text side with other data. As the plain text side 1153 participates in these reservations, some information is returned to 1154 the cipher text size to parameterize the aggregate reservation as 1155 described in Section 3.1.1 in the processing of the outbound 1156 messages. 1158 3.2. VPN Routers that use the Network Guard for signaling across the 1159 cryptographic boundary 1161 As described in Section 1.4 the Network Guard provides an additional 1162 path for the reservation signaling between the plain text and cipher 1163 text domains. 1165 _.------------. 1166 ,--'' Plain text Domain--. 1167 ,-' +--------+ +--------+ `-. 1168 ,' | Host | | Host | `. 1169 ,' +--------+ +--------+ `. 1170 ; : 1171 | +----------------------+ | 1172 : | +--------+ | | 1173 `. | | Router | | ,' 1174 `. | +---+----+ | ,' 1175 `- | +----------+ | ,' 1176 ---| +-+--+ +-+--+--+ |' 1177 |----|E/D |--|Net Grd| | VPN Router 1178 ,-'| +-+--+ +-+--+--+ |\ 1179 , | +----------+ | \ 1180 ,' | +---+----+ | `. 1181 ,' | | Router | | | 1182 / | +--------+ | \ 1183 ; +----------------------+ : 1184 | | 1185 : Cipher text Domain ; 1187 Figure 8: RSVP passage via Network Guard 1189 In this context, the VPN Router is composed of a plaintext router, a 1190 ciphertext router, an encrypt/decrypt implementation (such as a line 1191 card or interface device) and a network management process that 1192 manages the encrypt/decrypt implementation and potentially passes 1193 defined information flows between the plaintext and ciphertext 1194 domains. If the Network Guard is implemented as software process 1195 that exchanges configuration instructions between the routers, this 1196 is simple to understand. If it is built as separate systems 1197 exchanging datagrams, it is somewhat more complex, but conceptually 1198 equivalent. For example, the ciphertext router would consider an IP 1199 datagram received via the Network Guard (control plane) as having 1200 been received from and concerning the interface used in the data 1201 plane to the encrypt/decrypt unit. 1203 3.2.1. Signaling Flow 1205 Encrypt/Decrypt units may not be capable of terminating and 1206 originating flows as described in Section 3.1, and policy may prevent 1207 knowledge of the cipher text network addresses in the plain text 1208 router. In such a case the plain text and cipher text routers may 1209 use the Network Guard as the path for the signaling flows. The 1210 Network Guard performs the following functions to enable the flow of 1211 reservation signaling across the cryptographic domain 1213 o Transform plain text session identifiers into cipher text session 1214 identifiers and vice-versa in IP datagrams and RSVP objects (e.g. 1215 IP addresses) 1217 o Resource management of aggregated reservations (e.g. including 1218 cipher text encapsulation overhead to resources requested) 1220 o Read and write configuration on the Encrypt/Decrypt units as 1221 necessary (e.g. read plain text to cipher text IP address mapping) 1223 In addition the plain text and cipher text routers must support a 1224 routing function or local interface which ensures that aggregated 1225 RSVP messages flow via the Network Guard. The signaling flow across 1226 the entire VPN Router at cryptographic boundary however remains 1227 identical to the description in Section 3.1. 1229 A reader may note that the VPN Router described in Figure 8 can be 1230 collapsed into a single router with two halves or the Network Guard 1231 and the Encrypt/Decrypt units can be part of the plain text router. 1232 The details of alternate logical and physical architectures for the 1233 VPN router are beyond the scope of this document. 1235 3.2.2. Use case with Network Guard 1237 ........................................ 1238 : VPN Router A : 1239 : : 1240 :+-----------++----------++-----------+: 1241 +------+ RSVP :| || NetGrd-A || |: 1242 |Host-A|<---->:|PT-Router-A|+----------+|CT-Router-A|:::::::: 1243 +------+ :| || E/D-A || |: :: 1244 :+-----------++----------++-----------+: :: 1245 : A-RSVP : :: 1246 : <:::::::::::::> : :: 1247 :......................................: :: 1248 A-RSVP :: 1249 ,---. 1250 ,' `. 1251 / \ 1252 ; Interface : 1253 | Domain | 1254 : ; 1255 \ / 1256 `. ,' 1257 '---' 1258 A-RSVP :: 1259 ........................................ :: 1260 : VPN Router B : :: 1261 : : :: 1262 :+-----------++----------++-----------+: :: 1263 +------+ RSVP :| || NetGrd-B || |: :: 1264 |Host-B|<---->:|PT-Router-B|+----------+|CT-Router-B|:::::::: 1265 +------+ :| || E/D-B || |: 1266 :+-----------++----------++-----------+: 1267 : A-RSVP : 1268 : <:::::::::::::> : 1269 :......................................: 1271 Figure 9: Aggregated RSVP via Network Guard 1273 The above figure depicts a simple use case for aggregated signaling 1274 with the Network Guard. In this scenario, Host A initiates RSVP 1275 signaling to Host B for a reservation. The RSVP signaling between 1276 the hosts is encapsulated by the VPN Router Instances into encrypted 1277 tunnels. Aggregated RSVP signaling is triggered by VPN Router 1278 Instances, and flows into the CT-Routers as well as the interface 1279 domains to reserve resources at RSVP capable routers on the path. 1280 The aggregation/deaggregation point for RSVP reservations in this use 1281 case are the PT-Routers. The signaling aggregation of RSVP into 1282 A-RSVP at the PT-Router is similar to the data flow described in 1283 Section 3.1. The Network Guard performs the additional functions 1284 described in Section 3.2.1 to transform plaintext A-RSVP messages 1285 into suitable ciphertext A-RSVP messages. A typical reservation set 1286 up in this case would follow these steps 1288 o Host-A sends RSVP PATH message to Host B 1290 o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to 1291 VPN Router Instance B 1293 o CT Routers and Interface domain carry encrypted RSVP PATH message 1294 (like any other encrypted data message) 1296 o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr 1297 message to PT-Router-A in the encrypted tunnel. 1299 o PT-Router-B forwards decrypted plaintext RSVP PATH message to 1300 Host-B. 1302 o PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH 1303 message towards PT-Router-B via the Network Guard. 1305 o The NetGrd-A transforms the plaintext aggregate RSVP into the 1306 ciphertext aggregate RSVP message as described in Section 3.2.1 1307 and sends it to the CT-Router-A. 1309 o The ciphertext aggregated RSVP message travels through ciphertext 1310 routers in the interface domain. 1312 o CT-Router-B receives the ciphertext aggregate RSVP message and 1313 sends it to the NetGrd-B. 1315 o The NetGrd-B transforms the ciphertext aggregate RSVP into the 1316 plaintext aggregate RSVP message as described in Section 3.2.1 and 1317 sends it to the PT-Router-B. 1319 The subsequent RSVP and Aggregate RSVP signaling follows a similar 1320 flow, as described in detail in [RFC3175] and 1321 [I-D.ietf-tsvwg-rsvp-ipsec]to aggregate each plaintext reservation 1322 into a corresponding ciphertext reservation. This ensures that RSVP 1323 capable ciphertext routers reserve the required resources for a 1324 plaintext end to end reservation. Subsequent mechanisms such as 1325 preemption or the increase and decrease of resources reserved may be 1326 applied to these reservations as described before in this document. 1327 The RSVP data flow as described in Section 3.1 within the VPN router 1328 (from the plaintext router to the ciphertext router via the Guard) 1329 provides necessary and sufficient information to routers in the 1330 ciphertext domain to implement the QoS solution presented in the 1331 document. 1333 In this description, we have described the Network Guard as being 1334 separate from the Encrypt/Decrypt unit. This separation exists 1335 because in certain implementations it is mandated by those who 1336 specify the devices. The separation does not come for free, however; 1337 the separation of the devices for system engineering purposes is 1338 expensive, and it imposes architectural problems. For example, when 1339 the Guard is used to aggregate RSVP messages or PIM routing, the 1340 traffic is destined to the remote VPN Router. This means that the 1341 Guard must somehow receive and respond to, on behalf of the VPN 1342 Router, messages that are not directed to it. There are several 1343 possible solutions: 1345 o The two devices could use a common MAC and IP address, so that 1346 traffic destined to one is also received by the other 1348 o The ciphertext interface of the Guard could be placed into 1349 promiscuous mode, allowing it to receive all messages and discard 1350 all but the few it is interested in. 1352 o The Guard could be engineered to receive all from the ciphertext 1353 router and pass the bulk of it on to the VPN Router through 1354 another interface. In this case, the Guard and the VPN Router 1355 would use the same IP address. 1357 o The VPN Router could be engineered to receive all traffic from the 1358 ciphertext router and pass any unencrypted traffic it receives to 1359 the Guard through another interface. In this case, the Guard and 1360 the VPN Router would use the same IP address. 1362 o All the VPN router functions as shown in Figure 9 could be 1363 incorporated into a single chassis, with appropriate internal 1364 traffic management to send some traffic into the plaintext enclave 1365 and some to the Guard. In this case, the Guard and the VPN Router 1366 would at least functionally be the same system. 1368 Of these, clearly the last is the simplest architecturally and the 1369 one which most minimizes the attendant risk. 1371 4. IANA Considerations 1373 This document makes no request of the IANA. 1375 Note to RFC Editor: in the process assigning numbers and building 1376 IANA registries prior to publication, this section will have served 1377 its purpose. It may therefore be removed upon publication as an RFC. 1379 5. Security Considerations 1381 The typical security concerns of datagram integrity, node and user 1382 authentication are implicitly met by the security association that 1383 exists between the VPN Routers. The secure data stream which flows 1384 between the VPN Routers is also used for the reservation signaling 1385 datagrams flowing between VPN Routers. Information that is contained 1386 in these signaling datagrams receives the same level of encryption 1387 that is received by the data streams. 1389 One of the reasons cited for the nesting of VPN routes in Section 1.1 1390 are the different levels of security across the nested VPN Routers. 1391 If the security level decreases from one VPN Router to the next VPN 1392 Router in the nested path, the reservation signaling datagrams will 1393 by default receive the lower security level treatment. For most 1394 cases, the lower security treatment is acceptable. In certain 1395 networks, however, the reservation signaling across the entire nested 1396 path must receive the highest security level treatment (e. g. 1397 encryption, authentication of signaling nodes). For example the 1398 highest precedence level may only be signaled to VPN Routers which 1399 can provide the highest security levels. If any VPN Router in the 1400 nested path is incapable of providing the highest security level, it 1401 cannot participate in the reservation mechanism. 1403 In the general case, the nested path may contain routers which are 1404 either incapable of participating in VPNs or providing required 1405 security levels. These routers can participate in the reservation 1406 only if the lower security level is acceptable (as configured by 1407 policy) for the signaling of reservation datagrams. 1409 VPN Routers encapsulate encrypted IP packets and prepend an extra 1410 header on each packet. These packets, whether used for signaling or 1411 data, should be identifiable, at a minimum by the IP addresses and 1412 DSCP value. The prepended header, therefore, should contain at a 1413 minimum the DSCP value corresponding to the signaled reservation in 1414 each packet. This may literally be the same DSCP as is used for the 1415 data (forcing control plane traffic to receive the same QoS treatment 1416 as its data), or a different DSCP that is routed identically 1417 (separating control and data plane traffic QoS but not routing). 1419 6. Acknowledgements 1421 Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger 1422 Levesque, and Subha Dhesikan gave early review comments. 1424 Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou 1425 and their associates resulted in Section 3.2. 1427 Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik 1428 Bose) added [I-D.ietf-tsvwg-rsvp-ipsec], which clarified the 1429 interaction of this approach with the DSCP. 1431 7. References 1433 7.1. Normative References 1435 [I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate RSVP 1436 Reservations", 1437 draft-ietf-tsvwg-rsvp-ipsec-01 (work in 1438 progress), June 2006. 1440 [RFC2205] Braden, B., Zhang, L., Berson, S., 1441 Herzog, S., and S. Jamin, "Resource 1442 ReSerVation Protocol (RSVP) -- Version 1 1443 Functional Specification", RFC 2205, 1444 September 1997. 1446 [RFC2207] Berger, L. and T. O'Malley, "RSVP 1447 Extensions for IPSEC Data Flows", 1448 RFC 2207, September 1997. 1450 [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, 1451 J., and L. Zhang, "RSVP Operation Over 1452 IP Tunnels", RFC 2746, January 2000. 1454 [RFC2750] Herzog, S., "RSVP Extensions for Policy 1455 Control", RFC 2750, January 2000. 1457 [RFC2996] Bernet, Y., "Format of the RSVP DCLASS 1458 Object", RFC 2996, November 2000. 1460 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, 1461 F., and B. Davie, "Aggregation of RSVP 1462 for IPv4 and IPv6 Reservations", 1463 RFC 3175, September 2001. 1465 [RFC4495] Polk, J. and S. Dhesikan, "A Resource 1466 Reservation Protocol (RSVP) Extension 1467 for the Reduction of Bandwidth of a 1468 Reservation Flow", RFC 4495, May 2006. 1470 [RFC4542] Baker, F. and J. Polk, "Implementing an 1471 Emergency Telecommunications Service 1472 (ETS) for Real-Time Services in the 1473 Internet Protocol Suite", RFC 4542, 1474 May 2006. 1476 7.2. Informative References 1478 [ITU.MLPP.1990] International Telecommunications Union, "Multilevel 1479 Precedence and Preemption Service", ITU- 1480 T Recommendation I.255.3, 1990. 1482 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1483 September 1981. 1485 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1486 Services in the Internet Architecture: an Overview", 1487 RFC 1633, June 1994. 1489 [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation 1490 Protocol (RSVP) -- Version 1 Message Processing 1491 Rules", RFC 2209, September 1997. 1493 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF 1494 Integrated Services", RFC 2210, September 1997. 1496 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for 1497 the Internet Protocol", RFC 2401, November 1998. 1499 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 1500 Version 6 (IPv6) Specification", RFC 2460, 1501 December 1998. 1503 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1504 "Definition of the Differentiated Services Field (DS 1505 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1506 December 1998. 1508 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, 1509 Z., and W. Weiss, "An Architecture for 1510 Differentiated Services", RFC 2475, December 1998. 1512 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP 1513 Cryptographic Authentication", RFC 2747, 1514 January 2000. 1516 [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub 1517 Application Identity Policy Element for Use with 1518 RSVP", RFC 2872, June 2000. 1520 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1521 Authentication -- Updated Message Type Value", 1522 RFC 3097, April 2001. 1524 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy 1525 Element", RFC 3181, October 2001. 1527 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., 1528 Moore, T., Herzog, S., and R. Hess, "Identity 1529 Representation for RSVP", RFC 3182, October 2001. 1531 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le 1532 Boudec, J., Courtney, W., Davari, S., Firoiu, V., 1533 and D. Stiliadis, "An Expedited Forwarding PHB (Per- 1534 Hop Behavior)", RFC 3246, March 2002. 1536 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., 1537 Johnston, A., Peterson, J., Sparks, R., Handley, M., 1538 and E. Schooler, "SIP: Session Initiation Protocol", 1539 RFC 3261, June 2002. 1541 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 1542 "Integration of Resource Management and Session 1543 Initiation Protocol (SIP)", RFC 3312, October 2002. 1545 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 1546 Switching (GMPLS) Signaling Resource ReserVation 1547 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1548 RFC 3473, January 2003. 1550 [RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA 1551 assignments for Generalized MultiProtocol Label 1552 Switching (GMPLS) Resource Reservation Protocol - 1553 Traffic Engineering (RSVP-TE) Usage and Extensions 1554 for Automatically Switched Optical Network (ASON)", 1555 RFC 3474, March 2003. 1557 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1558 RFC 4303, December 2005. 1560 Authors' Addresses 1562 Fred Baker 1563 Cisco Systems 1564 1121 Via Del Rey 1565 Santa Barbara, California 93117 1566 USA 1568 Phone: +1-408-526-4257 1569 Fax: +1-413-473-2403 1570 EMail: fred@cisco.com 1572 Pratik Bose 1573 Lockheed Martin 1574 700 North Frederick Ave 1575 Gaithersburg, Maryland 20871 1576 USA 1578 Phone: +1-301-240-7041 1579 Fax: +1-301-240-5748 1580 EMail: pratik.bose@lmco.com 1582 Full Copyright Statement 1584 Copyright (C) The Internet Society (2006). 1586 This document is subject to the rights, licenses and restrictions 1587 contained in BCP 78, and except as set forth therein, the authors 1588 retain all their rights. 1590 This document and the information contained herein are provided on an 1591 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1592 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1593 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1594 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1595 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1596 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1598 Intellectual Property 1600 The IETF takes no position regarding the validity or scope of any 1601 Intellectual Property Rights or other rights that might be claimed to 1602 pertain to the implementation or use of the technology described in 1603 this document or the extent to which any license under such rights 1604 might or might not be available; nor does it represent that it has 1605 made any independent effort to identify any such rights. Information 1606 on the procedures with respect to rights in RFC documents can be 1607 found in BCP 78 and BCP 79. 1609 Copies of IPR disclosures made to the IETF Secretariat and any 1610 assurances of licenses to be made available, or the result of an 1611 attempt made to obtain a general license or permission for the use of 1612 such proprietary rights by implementers or users of this 1613 specification can be obtained from the IETF on-line IPR repository at 1614 http://www.ietf.org/ipr. 1616 The IETF invites any interested party to bring to its attention any 1617 copyrights, patents or patent applications, or other proprietary 1618 rights that may cover technology that may be required to implement 1619 this standard. Please address the information to the IETF at 1620 ietf-ipr@ietf.org. 1622 Acknowledgements 1624 Funding for the RFC Editor function is provided by the IETF 1625 Administrative Support Activity (IASA). This document was produced 1626 using xml2rfc v1.31 (of http://xml.resource.org/) from a source in 1627 RFC-2629 XML format.