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