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