idnits 2.17.00 (12 Aug 2021) /tmp/idnits7193/draft-macrae-policy-cops-vpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 597 has weird spacing: '.... It is deter...' -- 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 1999) is 8496 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) == Outdated reference: draft-ietf-rap-cops has been published as RFC 2748 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: draft-ietf-rap-cops-rsvp has been published as RFC 2749 == Outdated reference: draft-ietf-rap-framework has been published as RFC 2753 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force M. MacRae 2 INTERNET DRAFT S. Ayandeh 3 draft-macrae-policy-cops-vpn-00.txt Nortel Networks 4 Expiration Date: August 1999 February 1999 6 Using COPS for VPN Connectivity 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 except that the right to 12 produce derivative works is not granted. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document proposes a solution for establishing connectivity for 33 a network routed VPN. It makes use of a Policy Server to get 34 information on the establishment of tunnels between the Edge Devices 35 of a Service Provider's network. Use of a Policy Server allows a 36 network operator to enable the tunnel topology which is most suited 37 to the VPN; provides a mechanism to learn about the current state of 38 the VPN connectivity; and enables the addition and removal of 39 tunnels to reflect current network demands. The proposed extensions 40 are independent of the specific tunneling technology deployed in the 41 core of the network, i.e. MPLS, ATM, FR or IP. 43 The document also defines the extensions required to the COPS 44 (Common Open Policy Service) protocol being developed in the IETF 45 for communication between the Edge Devices and the Policy Server to 46 exchange VPN connectivity information. 48 Table of Contents 50 1. Introduction..............................................2 52 2. VPRNs and Tunnels.............................. .............3 53 2.1 VPRN Reference Network................................3 54 2.2 Tunnels in a VPRN.....................................4 55 2.3 Establishing Tunnels..................................4 56 2.4 Removing Tunnels......................................5 57 3. Using COPS for VPN Connectivity...........................5 58 4. Policy Server for VPN Connectivity........................6 59 5. RAP and COPS Background Information.......................7 60 5.1 Overview of RAP Policy Architecture...................7 61 5.2 Overview of COPS for VPN Connectivity.................7 62 6. Scenarios for Managing VPN Connectivity...................8 63 6.1 Opening a COPS Session................................8 64 6.2 Requesting VPN Connectivity Information...............9 65 6.3 Receiving VPN Connectivity Information................9 66 6.4 Reporting on Tunnel Installation.....................10 67 6.5 Summary of Tunnel Establishment......................10 68 6.6 Adding a New Tunnel..................................11 69 6.7 Removing a Tunnel....................................12 70 6.8 Changing Tunnel Parameters...........................13 71 6.9 Failure of a COPS Session............................13 72 6.10 Failure of a Tunnel.................................14 73 7. New COPS Objects for VPN Connectivity....................14 74 7.1 VPN Identifier (VPNID) Object........................15 75 7.2 Stub Link IDentifier (SLID) Object...................15 76 7.3 Policy Rule IDentifier (PRID) Object.................15 77 7.4 BER Encoded Policy Data (BPD) Object.................16 78 7.5 Tunnel Status Object.................................16 79 8. COPS Extensions for VPN Connectivity.....................16 80 8.1 Common Header for VPN................................16 81 8.2 Existing COPS Objects with VPN Information...........17 82 8.2.1 Context Object: Message Type Field.............17 83 8.2.2 Reason Object: Sub-Code Field..................18 84 8.2.3 Decision Object................................18 85 8.2.4 Error Object: Error Subcode Field..............19 86 8.3 Existing COPS Messages with ClientSI Objects.........19 87 8.3.1 ClientSI Object in Open Message................20 88 8.3.2 ClientSI Object in Request Message.............20 89 8.3.3 ClientSI Object in Report State Message........20 90 9. Security Considerations..................................21 91 10. References..............................................21 92 11. Author Information......................................22 93 12. Full Copyright Statement................................22 95 1. Introduction 97 There are a variety of VPN types which can be supported over IP and 98 non-IP facilities and which can operate at different layers of a 99 protocol stack. This work focuses on what is called a Virtual Private 100 Routed Network (VPRN), defined as an emulation of a multi-site wide 101 area routed network using IP facilities. These network based VPNs are 102 operated by Internet Service Providers (ISPs), and are implemented 103 within the provider network rather than on the CPE equipment. 105 VPRNs operate by establishing tunnels between the Edge Devices (EDs) 106 supporting the sites of a VPN. Currently, there is no scalable and 107 interoperable method of dynamically setting up these tunnels. This work 108 proposes a solution for establishing the connectivity between all sites 109 of a routed VPN. It uses policy to determine which EDs require tunnels 110 between them, thus allowing support of various tunnel topologies. An 111 off-network Policy Server (PS) owns information regarding the 112 configuration for the VPRN tunnels, and informs the ED. The proposed ED 113 - PS communication is the COPS (Common Open Policy Service) protocol 114 [1] which is being developed by the IETF RAP (RSVP Admission Protocol) 115 WG. Tunnels are likely to be subjected to QOS considerations, and the 116 use of COPS as the common mechanism for communicating both VPN and QOS 117 related information is advantageous (see COPS extensions for DiffServ 118 [2] and RSVP [3]). 120 This document starts by defining a VPRN and the tunnels used, makes 121 a case for using policy and COPS, gives an overview of the RAP policy 122 architecture, and highlights the COPS operation. It then gives various 123 scenarios for establishing and updating the VPN connectivity before 124 describing in detail the COPS extensions required for VPN connectivity 125 support. 127 2. VPRNs and Tunnels 129 2.1 VPRN Reference Network 131 A VPRN, pictured in Figure 1 below, consists of a mesh of IP tunnels 132 between the Edge Devices in an ISP network. Attached to these EDs are 133 CPE routers connected via one or more links, termed "stub" links. The 134 CPE could be any piece of equipment connecting a VPN site to the ISP 135 network; it is usually a router, but it could be, for example, a LAN 136 Switch sitting in front of a LAN. CPEs can be multihomed to the ISP 137 network; in this case, one stub link may be designated as a "backup" 138 link to be used in case of failure, or both links can be active. A link 139 between 2 CPEs outside of the ISP network is termed a "backdoor" link. 140 Although not shown in the diagram, an ED could support multiple VPNs 141 from the same or different stub link. 143 +---+ +------+ +------+ +---+ 144 |CPE|------| ED |-------------------------| ED |------|CPE| 145 +---+ stub +------+ IP tunnel +------+ stub +---+ 146 link | | | link : 147 | | | : 148 | | ISP NETWORK | : 149 | | | : 150 | |IP tunnel IP tunnel| : 151 | | +--------+ | : 152 | +-----------| ED |-----------+ : 153 | +--------+ : 154 backup| | | backdoor: 155 link | stub link | | stub link link : 156 | | | : 158 | +---+ +---+ : 159 +-------------|CPE| |CPE|....................: 160 +---+ +---+ 162 Figure 1 - Virtual Private Routed Network - Reference Network 164 2.2 Tunnels in a VPRN 166 Tunnels have entry-points, transit points, and exit points. The 167 entry and exit points for VPRN tunnels are the EDs; the transit points 168 (not shown in the figure) are network devices in the provider network. 169 Packets traveling on a tunnel are encapsulated at the entry point ED 170 and forwarded towards the designated exit point ED, where the packet is 171 decapsulated. Transit points are unaware that a tunnel is traversing 172 them: tunnel packets are forwarded just as any other packet. However, 173 one might want to assign a particular QOS (e.g. guarantee some 174 bandwidth or give higher/lower priority) to the packets flowing through 175 a tunnel, in which case, the transit points need to be configured 176 appropriately. Therefore, tunnel establishment needs to be coordinated 177 at entry, transit and exit points. 179 Various encapsulation methods (or tunnel technology) for VPRN 180 tunnels exist: IP-in-IP, IPsec, GRE, L2TP, ATM, FR or MPLS. This 181 document does not advocate the use of any particular tunnel technology, 182 and allows for the support of all. The specific information needed by 183 an ED to perform tunnel installation for various technologies is not 184 the concern of this document. 186 Tunnels can be established in a full-mesh, partial mesh, or 187 arbitrary topology, depending on the VPRN traffic patterns and policy 188 considerations. Tunnels can support uni or bi-directional traffic, 189 requiring sometimes more than one tunnel to achieve full duplex 190 communication between EDs. For example, an ED can send and receive 191 frames on the same Frame Relay DLCI, but it can only receive on one GRE 192 tunnel and send on another. 194 2.3 Establishing Tunnels 196 A tunnel endpoint can be installed when an ED initializes, upon 197 operator intervention, or possibly when a new site joins a VPRN. Tunnel 198 installation has to be performed at both endpoints (and possibly the 199 transit points) and should be coordinated by the PS. 201 The ED requires parameters to control the installation. This 202 information may be technology specific and it may vary between tunnels 203 of the same technology. These include, but are probably not limited to: 205 Rate of retrying tunnel installation: 206 - interval to wait after initial installation failure 207 - interval between each subsequent retry (for linear rate) 208 - factor by which to increment the previous interval to compute the 209 current interval (for exponential rate) 211 - maximum interval 212 Reporting tunnel installation failures to PS: 213 - report initial failure only 214 - report every failure 215 - report each "n" failure 216 - never report failures 218 (More work is required to define / refine these parameters.) 220 Tunnel installation is meant to reserve the resources and setup the 221 appropriate structures in the ED for that tunnel. However, the ED still 222 needs to know when the tunnel can be used, for example, when both ends 223 of an IP-in-IP tunnel are installed. Since the PS has a view of the 224 entire tunnel, it informs the ED when the tunnel can be activated. 226 2.4 Removing Tunnels 228 Tunnels are removed upon failure of a tunnel component, operator 229 intervention, or possibly when a site leaves a VPN. Depending on the 230 tunnel technology used, it may not be possible for an ED to detect a 231 tunnel failure. For example, failure of the exit point ED of an IP-in- 232 IP tunnel cannot be directly detected at the entry point ED due to the 233 connectionless nature of the tunnel, but routing information may convey 234 the loss of a path to the failed ED; on the other hand, failure of an 235 ATM VC is easily detected by the EDs at both endpoints. If a failure 236 can be detected by an ED, it should report it to the PS which may take 237 steps to remove the tunnel at all points. 239 A mechanism to dampen the reporting of flapping tunnels is needed. 240 This requires further study. 242 3. Using COPS for VPN Connectivity 244 Policy is what controls the behaviour of a network under different 245 conditions. Rather than offering a uniform or best-effort service to 246 all users based on static or automated technical considerations, a 247 policy enabled network takes into account the business priorities of 248 the users and their applications, and dynamically determines the 249 treatment to give each packet. 251 For VPRNs, policy is essential in determining the tunnels needed to 252 establish a topology that reflects the expected traffic patterns 253 between sites, respects the criticalness of certain paths or 254 applications, and allows packets to be routed based on non-technical 255 considerations (e.g. all packets from a certain VPN site must go 256 through a firewall). No automatic tool for the discovery of EDs and 257 tunnel establishment could take into consideration these business 258 aspects. Policy dictates which tunnels are required, which EDs and 259 transit points are involved in installing a tunnel, which tunnel 260 technology to use, and any other information which is necessary to 261 establish the tunnel. 263 exchanging QOS information (such as filters) between a PS (or Bandwidth 264 Broker) and an ED, using COPS for VPN connectivity enables a PS to 265 coordinate tunnel installation and the QOS behaviour of those tunnels. 267 COPS allows for dynamic updating of the connectivity between the VPN 268 sites. The PS can oversee the end-to-end management of tunnels 269 (provided the policy architecture supports inter-domain PS-PS 270 communication). Changes to the tunnel topology can be done at different 271 times of day by installing tunnels which are only valid during certain 272 periods of the day, week, month or year. 274 COPS provides a feedback mechanism where the status of the tunnels 275 from all the affected EDs for a given VPN can be correlated at the PS. 276 (Note that the interaction between policy management and network 277 management is out of the scope of this document.) A network operator 278 can therefore add and remove tunnels to better reflect the current 279 network demands. 281 Without COPS, tunnel information would need to be configured for 282 each ED individually and downloaded through a network management or 283 command line interface to each affected ED. This lacks the central 284 control needed to establish a coherent topology and the dynamism 285 required for monitoring and updating the topology. 287 4. Policy Server for VPN Connectivity 289 The Policy Server requirements and its implementation are not dealt 290 with in this document. How the VPN connectivity policy information is 291 obtained, stored, and its exact data representation is not discussed. 292 However, there are certain assumptions being made that are worth 293 mentioning. 295 The Policy Server has access to information required to determine 296 and establish connectivity between the EDs for all the VPNs in its 297 domain. Identifiers are used for each VPN and these may or may not have 298 global significance. The VPN Identifiers are not yet standardized in 299 the IETF, we assume a generic coding capable of accepting many formats 300 (i.e. type - length - value coding). A stub link Identifier is also 301 kept by the PS, the format of which can be varied. 303 For each VPN, the PS has a list of all EDs with links to the VPN 304 sites, and has technology specific information on the tunnels to be 305 setup for each VPN. This may include a membership list of the VPNs 306 attributed to a stub link or configuration information for tunnel such 307 as routing or QOS parameters. 309 We assume in this document that a Policy Information Base (PIB) 310 contains all the policy rules (akin to tunnel information) for VPN 311 connectivity, and that each instance of a policy rule can be identified 312 with a Policy Rule IDentifier (PRID). The policy information in the PIB 313 is defined using the ASN.1 data definition language [5]. The 314 representation of the policy information and the PRID on the wire 315 follows the Basic Encoding Rules (BER) for ASN.1 [6]. The acronym "BPD" 316 refers to the BER-coded Policy Data in the COPS messages / objects. 317 This model is also used for COPS for Diffserv [2]. 319 It is the PS's responsibility to extract the information that is 320 relevant to one ED for a given VPN and send that information when 321 requested by the ED or when a change occurs. The PS receives 322 information on the status of the tunnels (installed or removed) from 323 the ED. What it does with this information and it's relationship with 324 the domain's network or service management system(s) is out of the 325 purview of this document. 327 It is also possible for the PS to coordinate the policies for tunnel 328 establishment with other policy managed activities, such as DiffServ's 329 Bandwidth Broker, IntServ's RSVP resource reservation system, or IPsec 330 security policy. 332 5. RAP and COPS Background Information 334 5.1 Overview of RAP Policy Architecture 336 The RAP WG has proposed [4] two main architectural elements for 337 policy control: (1) the PEP (Policy Enforcement Point) component 338 running on a network node, such as an ED, and (2) the PDP (Policy 339 Decision Point) off-network entity which typically resides at a Policy 340 Server. COPS is used as the protocol between the PDP and the PEP for 341 exchanging policy information. 343 The PEP is the point at which policy decisions are actually enforced 344 or implemented. Policy decisions are made primarily at the PDP which 345 may make use of other mechanisms and protocols to achieve additional 346 functionality. For example, the PDP may use an LDAP-based directory 347 service for storage and retrieval of policy information which has been 348 populated by a management tool. How the PDP obtains the policy 349 information and it's representation (or schema) is out of the scope of 350 this document. 352 In this document, we will continue to refer to the ED and the PS 353 rather than the equivalent PEP and PDP terminology used by RAP. 355 5.2 Overview of COPS for VPN Connectivity 357 Please refer to the base COPS protocol description [1] for a 358 complete understanding of the protocol capabilities. 360 COPS runs on a TCP connection using a well-known port number. The ED 361 opens the TCP session and then initiates a COPS session with a new 362 client type of "vpn". 364 Tunnel installation information is requested by the ED by sending a 365 Request (REQ) message. The PS replies with the information required for 366 tunnels to be installed in one or more Decision (DEC) messages. The 367 protocol requires that the ED send a Report (RPT) message to the PS 368 when the tunnel is installed (or not installed and the reason). Tunnels 369 are activated by the PS by sending unsolicited DEC messages. 371 When a change occurs in the policy data for VPN connectivity, the PS 372 can push the new configuration to the ED in an unsolicited DEC message. 373 The RPT message is also used by the ED to periodically report back to 374 the PS on the current status of the various tunnels. 376 To provide fault tolerance, COPS supports keep-alive, redirects and 377 re-synchronization procedures to allow for the PS to be backed up, or 378 for the load to be shared between more than one PS. 380 6. Scenarios for Managing VPN Connectivity 382 This chapter describes various scenarios for establishing, 383 maintaining, updating, and tearing down the VPN tunnels using COPS 384 protocol exchanges. The scenarios are: 386 - opening a COPS session 387 - requesting VPN connectivity information 388 - receiving VPN connectivity information 389 - reporting on tunnel installation 390 - adding a new tunnel 391 - removing a tunnel 392 - changing tunnel parameters 393 - failure of a COPS session 394 - failure of a tunnel 396 All the messages described below contain a Client Handle which is 397 computed by the ED to identify a transaction. We have defined the unit 398 of transaction as a VPN, and therefore, there is a unique handle 399 computed for each VPN supported on the ED. 401 The Client Specific Information (ClientSI), and the VPN specific 402 objects mentioned in this section are detailed in Chapters 7 and 8. 404 6.1 Opening a COPS Session 406 When the ED is brought into service, it activates all of its links. 407 The device learns about its ED Id (or the PEPID in RAP parlance) and 408 the VPN Ids of the sites supported on each of its own stub links. How 409 this information is obtained (e.g. static provisioning or a dynamic 410 discovery mechanism) is out of the scope of this document. At this 411 point, the ED is ready to get the information to establish the tunnels 412 for all the VPNs that it supports. 414 The ED locates the primary PS (and possibly one or more backup PSs) 415 using provisioned information, or a service location protocol. The ED 416 then establishes a TCP connection (if one is not already established) 417 with the PS on a well-known TCP port number. Once the TCP connection 418 with the PS is established, the ED initiates the COPS session by 419 sending a COPS Client Open (OPN) message to the PS containing the new 420 client type for VPN. Refer to [1] for a complete description of the 421 opening and closing of a COPS session. 423 6.2 Requesting VPN Connectivity Information 425 When an ED's stub link is activated, the ED must send COPS Request 426 (REQ) message(s) to the PS asking for the connectivity information 427 associated with each VPN Id supported on a stub link. If a VPN Id is 428 already supported on another of its own stub link, there is still a 429 need to ask for the tunnel information since the PS may want to change 430 some the tunnel parameters (e.g. bandwidth) when a new stub link is 431 comes into service, and the ED must be told which existing tunnels to 432 use. Therefore the tunnel information is always specific to the stub 433 link. The REQ message contains: 435 with the "vpn" client type 436 unique handle computed by the ED for this VPN 437 to explain the request 438 - request type flag (r-type) = "configuration request" 439 - message type (m-type) indicating new VPN to support 440 with a VPN Id and stub link Id - defined in section 8.3.2 442 6.3 Receiving VPN Connectivity Information 444 As a response to the ED request for the configuration for a VPN, the 445 PS sends one or more Decision (DEC) messages containing information on 446 the tunnels to be installed or used by the ED for one VPN. In some 447 cases, a tunnel may need to be removed in order to install a 448 replacement tunnel (e.g. one with different parameters). The PS can 449 also return a "null decision" to indicate that the ED is not 450 responsible for the establishment of any tunnel for the VPN; in this 451 case, the PS informs the ED of the existing tunnels to use for that 452 VPN. 454 The DEC message can contain information for multiple tunnels, and 455 many DEC messages can be used to contain all the tunnel information 456 required by an ED. It is up to the PS to determine the best way to 457 package the information since the content is self-describing. One DEC 458 message contains: 460 with the "vpn" client type 461 for that VPN - same as in the REQ message 462 one or more decision objects 463 same as REQ message 464 = "install", "remove", or "null decision" 465 as defined in section 8.2.3 467 In the case where the PS finds a COPS protocol error in the REQ 468 message, a single object is returned in one DEC message instead 469 of a (multiple) object(s). The ED should take appropriate 470 action depending on the error as indicated in the COPS protocol 471 specification [1]. The Error_Subcode field for VPNs is defined in 472 section 8.2.4. 474 6.4 Reporting on Tunnel Installation 476 Once tunnel information is received in a DEC message, the ED 477 proceeds to install each tunnel. Tunnel installation is technology 478 specific, as is the determination of its success or failure. 480 Parameters needed by the ED to guide tunnel installation and the 481 reporting back to the PS are included in the tunnel setup information 482 given by the PS (refer to section 2.2). We refer to these as "retry" 483 and "reporting" parameters. 485 When a tunnel is installed, the ED sends to the PS a Report (RPT) 486 message to indicate a successful installation. The status of more than 487 one tunnel for the same VPN can be included in one RPT message, but a 488 tunnel installation status should be sent to the PS without delay. The 489 RPT message for successful tunnel installation contains: 491 with the "vpn" client type 492 computed by the ER for the VPN Id 493 = "installed" 494 PRID of installed tunnels (section 8.3.3) 496 In due time, the PS informs the ED to start using the tunnel just 497 installed by sending an unsolicited DEC message with an "activate" 498 decision flag. 500 with the "vpn" client type 501 for that VPN 502 one or more decision objects 503 indicating "unsolicited" 504 = "activate" 505 PRID of tunnels to activate (section 8.2.3) 507 (Is there a need to send an RPT message to indicate that the tunnel 508 was indeed activated?) 510 If the tunnel installation failed, the ED should periodically 511 attempt the installation again using the retry parameters provided. If 512 a failure needs to be reported (according the reporting parameters), 513 the ED sends the PS an RPT message as follows: 515 with the "vpn" client type 516 computed by the ER for the VPN Id 517 indicating "not installed" 518 is a tunnel report with a status defined in section 8.3.3 520 6.5 Summary of Tunnel Establishment 522 The summary of the entire procedure of requesting and receiving 524 tunnel information, reporting on the installation, and activating the 525 tunnel(s) (sections 6.2, 6.3 and 6.4) is depicted in Figure 2 below; 526 only the successful case is represented. 528 ED PS 529 | REQ (VPN Id, stub link) | (one REQ for each 530 |---------------------------------->| VPN Id on stub link) 531 |---------------------------------->| 532 | | 533 | DEC (install w. tunnel info) | (could be 534 |<----------------------------------| multiple DEC messages) 535 |<----------------------------------| 536 | | 537 | RPT (tunnel i - installed) | (usually one tunnel 538 |---------------------------------->| per RPT message) 539 | ... | 540 | | 541 | RPT (tunnel j - installed) | 542 |---------------------------------->| 543 | | 544 | DEC (activate tunnel i) | (could have more 545 |<----------------------------------| than 1 tunnel per 546 | ... | DEC message) 547 | | 548 | DEC (activate tunnel j) | 549 |<----------------------------------| 550 | | 552 Figure 2 - COPS Message Exchange for Tunnel Establishment 554 6.6 Adding a New Tunnel 556 A tunnel may be added to the established topology under the 557 following circumstances: 559 1. A new stub link is activated. 560 2. A new VPN Id is added to an active stub link (e.g., a new VPN site 561 is added behind an existing stub link). 562 3. It is determined that a new tunnel is required between existing 563 EDs (e.g., for engineering purposes). 564 4. A new tunnel is required by the PS at a specific time (e.g., the 565 policy validity period is reached). 567 In the first 2 cases, the ED is made aware via a configuration update 568 or otherwise that a new VPN Id is to be supported on a stub link. The ED 569 then requests the tunnel information associated with the VPN Id on that 570 stub link (see section 6.2), even if the VPN Id is already supported on 571 another stub link. The PS must have already been populated with the 572 information to give to the ED. 574 In the last 2 cases, the PS is given the information on the new 575 tunnel in some manner (irrelevant to this document). The PS identifies 576 the affected EDs and pushes the tunnel information to those EDs in 577 unsolicited DEC messages (see section 6.3). 579 with the "vpn" client type and "unsolicited" flag 580 computed by the ER for the VPN Id 581 one or more decision objects 582 583 - request type flag (r-type) = "unsolicited" 584 = "install" 585 is tunnel information (see section 8.2.3) 587 The DEC message elicits RPT messages (as in section 6.4) for 588 reporting on the tunnel installation(s). When appropriate, the PS will 589 also send DEC messages to activate the tunnel(s). 591 6.7 Removing a Tunnel 593 Tunnel removal may be required under the following circumstances: 595 1. A stub link is deactivated or fails. 596 2. A VPN Id is removed from an active stub link. 597 3. It is determined that a tunnel is no longer required between 598 existing EDs (e.g., for engineering purposes). 599 4. The PS determines that a tunnel is no longer required (e.g., a 600 policy validity period expires). 602 In the first 2 cases, the ED detects that a change in the VPNs 603 supported on a stub link. It cannot release the resources of the 604 tunnel(s) associated with the VPN Id for that stub link because the 605 tunnel(s) may still be needed by another stub link. The PS must be 606 informed because another ED may need to remove the other end of the 607 tunnel. The ED sends a request for new configuration information 608 because of the unsupported VPN Ids on the stub link, and waits for the 609 PS decision to determine its course of action. The REQ message is as 610 follows: 612 with the "vpn" client type 613 unique handle computed by the ED for this VPN 614 to explain the request 615 - request type flag (r-type) = "configuration request" 616 - message type (m-type) indicating VPN no longer supported 617 with a VPN Id and stub link - defined in section 8.3.2 619 The PS responds with a DEC message indicating either to "deactivate" 620 the tunnel(s), "remove" the tunnels(s), or "install" new tunnel(s). 622 In the third and fourth cases, the PS sends an unsolicited DEC 623 message with a "deactivate" or "remove" decision, indicating that the 624 tunnel is no longer to be used or required by the ED. This is sent to 625 the EDs at the tunnel entry and exit points. 627 with the "vpn" client type and "unsolicited" flag 629 for the VPN Id 630 one or more decision objects 631 632 - request type flag (r-type) = "unsolicited" 633 = "deactivate" or "remove" 634 PRIDs of affected tunnels (see 8.2.3) 636 The ED then stops using a tunnel (deactivate) or releases the resources 637 (remove) of all the affected tunnels. The ED sends RPT messages for 638 each tunnel indicating that it was "deactivated" or "removed". 640 It is possible to fail to deactivate or remove a tunnel, for example, 641 if there is not enough buffers for inter-process communication. This 642 however is an extreme situation, and we will assume that tunnel removal 643 and deactivation is always successful. 645 6.8 Changing Tunnel Parameters 647 Sometimes, it may be necessary to change the parameters of a tunnel. 648 The PS is given the new parameters and uses a two step process of 649 tunnel removal and addition. This can be done in one of 2 ways, at the 650 PS's discretion: 652 Case 1: The PS first sends an unsolicited DEC message to remove the 653 tunnel. Upon reception of the successful RPT message from the ED, the 654 PS sends the DEC message to install and activate the tunnel with the 655 new parameters. Operation in this way may leave a window when there is 656 no tunnel operating between 2 EDs for a given VPN. 658 Case 2: The PS first sends a DEC message to install the new tunnel. 659 Upon reception of the successful RPT message from the ED, the PS sends 660 the DEC message to deactivate the old tunnel and activate the new 661 tunnel (sent in same message to be executed as one atomic operation by 662 the ED). This way causes additional resources to be used in the network 663 during the changeover time, but ensures continuous transmission between 664 EDs. 666 The capability to change tunnel parameters while keeping the tunnel 667 active is not considered at this point. Connection oriented tunnel 668 technology does not support such a change. 670 6.9 Failure of a COPS Session 672 Should the communication between the PS and the ED fail, the COPS 673 document [1] explains how the ED tries to re-establish the 674 communication with the primary PS, and this failing, with a backup PS. 675 The ED operates with the cached VPN connectivity information only for a 676 specified period of time, after which it will remove the established 677 tunnels. The time to wait before removing (or deactivating?) the 678 tunnels could be communicated to the ED in various ways: 680 - As part of the configuration information received from the network 682 management system of the ED. 684 - As part of the Client Accept (CAT) message from the PS; this would 685 require the definition of a new object to be included in the CAT 686 message; the "policy data lifetime after communication failure" 687 would be applicable to all COPS client types for all the policy 688 data received from the PS; this means a change to the base COPS 689 protocol. 691 - As part of the information for each tunnel; this value would 692 override the configured value or the value received in the CAT 693 message. 695 The exact way to communicate this information to the ED requires 696 further study. 698 6.10 Failure of a Tunnel 700 When a tunnel fails, it is desirable to inform the PS to insure that 701 the tunnel at both endpoints is removed or deactivated, and, if at all 702 possible, that new tunnels be added to compensate for the loss of a 703 tunnel. 705 Detecting a tunnel failure is technology dependent, and it is not 706 always possible for the ED to do so. Nonetheless, any detectable 707 failure should be reported to the PS. It is left to the ED 708 implementation to detect the failures if it can. 710 When tunnel failure is detected, the ED sends to the PS a RPT message 711 containing: 713 with the "vpn" client type 714 computed by the ER for the VPN Id 715 indicating "removed" 716 is a tunnel report with a status of 717 "removed - failed tunnel" and a technology specific 718 reason (see section 8.3.3) 720 7. New COPS Objects for VPN Connectivity 722 The following objects are added to COPS objects to support VPN 723 Connectivity: 725 - VPN Identifier 726 - Stub Link Identifier 727 - Policy Rule Identifier (PRID) 728 - BER (Basic Encoding Rule) encoded Policy Data (BPD) 729 - Tunnel status 731 Please note that all objects described below are a multiple of 4 732 octets to align them on a 32-bit word boundary. Shorter objects are 733 padded with zeros. 735 7.1 VPN Identifier (VPNID) Object 737 This is a PS-unique identifier for the VPN. Its exact format has not 738 been standardized yet, although some proposals have been put forth. We 739 will assume at this time that more than one format can be supported. 741 0 1 2 3 742 +--------------+---------------+---------------+---------------+ 743 | VPNID_Len | VPNID_Type | 744 +--------------+---------------+---------------+---------------+ 745 = VPNID = 746 +--------------+---------------+---------------+---------------+ 748 - VPNID_Len = length in octets of the entire object 749 - VPNID_Type = identifies the format of the VPN Id that follows 750 (values tbd) 751 - VPNID = variable length VPN identifier 753 7.2 Stub Link IDentifier (SLID) Object 755 This is an identifier for the stub link of the ER. Since a format has 756 not been standardized, we will assume at this time that more than one 757 format can be supported. 759 0 1 2 3 760 +--------------+---------------+---------------+---------------+ 761 | SLID_Len | SLID_Type | 762 +--------------+---------------+---------------+---------------+ 763 = SLID = 764 +--------------+---------------+---------------+---------------+ 766 - SLID_Len = length in octets of the entire object 767 - SLID_Type = identifies the format of the SLID that follows 768 (values tbd) 769 - SLID = variable length Stub Link identifier 771 7.3 Policy Rule IDentifier (PRID) Object 773 This object carries the identifier for the instance of a policy 774 rule. The exact format of the PRID is to be determined. 776 0 1 2 3 777 +--------------+---------------+---------------+---------------+ 778 | PRID_Len | Type = PRID | 779 +--------------+---------------+---------------+---------------+ 780 = PRID = 781 +--------------+---------------+---------------+---------------+ 783 - PRID_Len = length in octets of the entire object 784 - Type = identifies that a PRID follows 785 - PRID = variable length Policy Rule identifier 787 7.4 BER Encoded Policy Data (BPD) Object 789 This object carries the value of the instance of a policy rule which 790 is encoded using BER (Basic Encoding Rules) for ASN.1 [6]. The content 791 of the BPD is still to be determined (i.e. the policy schema). 793 0 1 2 3 794 +--------------+---------------+---------------+---------------+ 795 | PRID_Len | Type = BPR | 796 +--------------+---------------+---------------+---------------+ 797 = BPR = 798 +--------------+---------------+---------------+---------------+ 800 7.5 Tunnel Status Object 802 The tunnel status object is used by the ED to report on the 803 installation and removal of the tunnel. 805 0 1 2 3 806 +--------------+---------------+---------------+---------------+ 807 | T_Status_Len | Type = T_Status | 808 +--------------+---------------+---------------+---------------+ 809 | Tunnel_Status | Tunnel_Error_Code | 810 +--------------+---------------+---------------+---------------+ 812 Tunnel_Status 813 - 0 = installed 814 - 1 = not installed - doing periodic retries 815 - 2 = not installed - all periodic retries failed 816 - 3 = removed - PS request 817 - 4 = removed - failed tunnel 818 Tunnel_Error_Code = technology specific reason why the tunnel is not 819 installed or being removed (values tbd) 821 8. COPS Extensions for VPN Connectivity 823 A COPS message contains a common header followed by a number of typed 824 objects. The base COPS protocol provides for the definition of client 825 specific information (ClientSI) in its messages and in the objects 826 included within these messages. The extensions required to COPS 827 messages and objects to support the VPN client type are described in 828 detail in this chapter. 830 Note that there are no new messages required for VPN support in COPS. 831 Refer to the base COPS specification [1] for the complete message and 832 object descriptions. In case of any discrepancy between this document 833 and [1], the latter should be considered the authoritative text. 835 8.1 Common Header for VPN 837 The common header is used to identify the message type and client 839 type. A new COPS client type is defined to support VPNs. 841 0 1 2 3 842 +--------------+---------------+---------------+---------------+ 843 |Version|Flags | Op Code | Client Type = 0xnn | 844 +--------------+---------------+---------------+---------------+ 845 | Message Length | 846 +--------------+---------------+---------------+---------------+ 848 - Client Type = nn for VPN client type (need IANA reservation) 850 8.2 Existing COPS Objects with VPN Information 852 COPS objects appear after the common header and are formatted as 853 follows: 855 0 1 2 3 856 +--------------+---------------+---------------+---------------+ 857 | Length | C-num | C-type | 858 +--------------+---------------+---------------+---------------+ 859 | | 860 = = 861 | | 862 +--------------+---------------+---------------+---------------+ 864 - Length = length in octets of object header and content 865 - C-num = object class number (identifies the object) 866 - C-type = type of information specific to the C-num 867 - = variable length object content; specific to the C-num 868 and C-type 870 Some COPS objects are defined with fields which can contain 871 information tailored for client specific purposes. These objects are: 873 - Context object: the M-type field can contain VPN message types 874 - Reason Code object: the error sub-codes can be VPN specific 875 - Decision object: the ClientSI field can be defined for VPNs 876 - Error object: can contain error sub-codes for VPN purposes 878 Furthermore, the Decision object contains a command-code field which 879 requires new commands to support VPN connectivity. 881 8.2.1 Context Object: Message Type Field 883 The Context object (c-num=2, c-type=1) is present in the Request 884 (REQ) and Decision (DEC) messages. It contains a Request Type (R-type) 885 field to indicate the type of request sent to the PS, and a Message 886 Type (M-type) field to indicate a request specific to the COPS client 887 type. 889 M-type values for the VPN client type are defined for a 890 "configuration request" R-type. These are: 892 0x01 = new VPN supported on stub link 893 0x02 = VPN no longer supported on stub link 895 The current values in the COPS base protocol for the R-type field 896 found in the Context object refers to the R-type of the REQ message 897 that provoked the DEC message. For an unsolicited DEC message, where 898 there is no prior request, a new value of "unsolicited" would make more 899 sense than using "configuration request". 901 8.2.2 Reason Object: Sub-Code Field 903 The Reason object (c-num=5, c-type=1) is present in the Delete 904 Request State (DRQ) message to indicate the reason why a previous 905 request is being deleted. It contains a Reason-subcode field which can 906 be used to indicate VPN specific information to clarify the generic 907 Reason-code. 909 There are no Reason-subcode values defined for the VPN client type 910 at this time; the field should be set to zero. 912 8.2.3 Decision Object 914 The Decision (DEC) message contains one or more Decision objects (c- 915 num=6). Each of these objects has a c-type defined for carrying various 916 types of decision data. There is a mandatory Decision Flags object (c- 917 type=1) which includes a command-code field to indicate the action to 918 perform on the decision data: 920 - "null decision": to indicate to use existing tunnel(s) 921 - "install": to indicate tunnels to install (i.e. get resources) 922 - "remove": to releases the tunnel resources 924 For VPN connectivity purposes, there is a need to add 3 more 925 commands: 927 - "activate": to instruct the ED to start using the tunnel(s) 928 - "deactivate: to instruct the ED to stop using the tunnel(s) 929 - "deactivate & activate" to instruct the ED to swap from using one 930 tunnel (deactivate) to using another one (activate) 932 Another Decision object (c-type=5) carries Named decision data. The 933 Named data is specific to the decision flag which indicates the type of 934 configuration data given in the decision. 936 The following information is carried in the Decision object for 937 Named data when the decision flag is "install": 939 0 1 2 3 940 +--------------+---------------+---------------+---------------+ 941 | Length | C-num=6 | C-type=5 | 942 +--------------+---------------+---------------+---------------+ 944 = = 945 +--------------+---------------+---------------+---------------+ 947 ::= | 948 ::= 949 defined in section 7.3 950 defined in section 7.4 952 The following information is carried in the Decision object for 953 Named data for the decision flag values of "null decision", "remove", 954 "activate" and "deactivate": 956 0 1 2 3 957 +--------------+---------------+---------------+---------------+ 958 | Length | C-num=6 | C-type=5 | 959 +--------------+---------------+---------------+---------------+ 960 = = 961 +--------------+---------------+---------------+---------------+ 963 ::= | 964 ::= 966 The following information is carried in the Decision object for 967 Named data for the "deactivate & activate" decision flag: 969 0 1 2 3 970 +--------------+---------------+---------------+---------------+ 971 | Length | C-num=6 | C-type=5 | 972 +--------------+---------------+---------------+---------------+ 973 = = 974 +--------------+---------------+---------------+---------------+ 976 ::= 978 8.2.4 Error Object: Error Subcode Field 980 The Error object (c-num=8, c-type=1) is found in the DEC message 981 when the PS cannot respond to the ED's REQ message because of a 982 protocol error. The Error-subcode field in this object is used to 983 further define the Error field included in the object. 985 The are no Error-subcode values defined for the VPN client type at 986 this time. The field should contain zeros. 988 8.3 Existing COPS Messages with ClientSI Objects 990 There are Client Specific Information (ClientSI) objects defined in 991 various COPS messages which can be used to carry VPN data. These are 992 found in the: 994 - Client Open (OPN) message 995 - Request (REQ) message 997 - Report State (RPT) message 999 The ClientSI object for VPN uses the following field settings: 1001 - C-num = 9; ClientSI object 1002 - C-type = 1; Signaled ClientSI (VPN objects) 1003 = 2; Named ClientSI (named configuration information) 1005 8.3.1 ClientSI Object in Open Message 1007 The VPN ClientSI object in the Open (OPN) message is not used at this 1008 time. 1010 8.3.2 ClientSI Object in Request Message 1012 The VPN ClientSI object in the Request (REQ) message contains the 1013 VPN Id and the stub link Id for which configuration is requested; its 1014 format is as follows: 1016 0 1 2 3 1017 +--------------+---------------+---------------+---------------+ 1018 | Length | C-num = 9 | C-type = 1 | 1019 +--------------+---------------+---------------+---------------+ 1020 = = 1021 +--------------+---------------+---------------+---------------+ 1022 = = 1023 +--------------+---------------+---------------+---------------+ 1025 defined in section 7.1 1026 defined in section 7.2 1028 8.3.3 ClientSI Object in Report State Message 1030 The VPN ClientSI object in the Report (RPT) message for reporting 1031 tunnel installation or removal status carries named data which is 1032 dependent on the report type. 1034 To indicate a successful tunnel installation, the report type of 1035 "installed" is used with the following ClientSI: 1037 0 1 2 3 1038 +--------------+---------------+---------------+---------------+ 1039 | Length | C-num = 9 | C-type = 2 | 1040 +--------------+---------------+---------------+---------------+ 1041 = = 1042 +--------------+---------------+---------------+---------------+ 1044 ::= | 1045 1046 ::= 1047 defined in section 7.3 1049 A report type of "removed" indicates that a tunnel's resources have 1050 been released, while "not installed" or "not removed" report types 1051 indicate that the action requested by the PS to install or remove a 1052 tunnel was not successful. The ClientSI is then: 1054 0 1 2 3 1055 +--------------+---------------+---------------+---------------+ 1056 | Length | C-num = 9 | C-type = 2 | 1057 +--------------+---------------+---------------+---------------+ 1058 = = 1059 +--------------+---------------+---------------+---------------+ 1061 ::= | 1062 1063 ::= 1064 defined in section 7.3 1065 defined in section 7.5 1067 The content of the ClientSI object when the report type is 1068 "accounting" is still to be determined. 1070 Further study is required to determine if new report types of 1071 "activated" and "deactivated" are required to support VPNs. 1073 9. Security Considerations 1075 Extending COPS to provide VPN Connectivity is subject to the same 1076 security considerations as the base protocol. COPS [1] advocates using 1077 IPsec for PS-ED communication. 1079 10. References 1081 [1] Boyle, J. et al, "The COPS (Common Open Policy Service) Protocol", 1082 draft-ietf-rap-cops-05.txt, January 18, 1999, work in progress. 1084 [2] Reichmeyer, F. et al, "COPS Usage for Differentiated Services", 1085 draft-ietf-rap-cops-ds-01.txt, December, 1998, work in progress. 1087 [3] Boyle, J. et al, "COPS Usage for RSVP", draft-ietf-rap-cops-rsvp- 1088 03.txt, February 18, 1999, work in progress. 1090 [4] Yavatkar R. et al. "A Framework for Policy-based Admission 1091 Control", draft-ietf-rap-framework-01.txt, November, 1998, work in 1092 progress. 1094 [5] Information Processing Systems - Open Systems Interconnection - 1095 "Specification of Abstract Syntax Notation One (ASN.1)", International 1096 Organization for Standardization. International Standard 8824, 1097 December, 1987. 1099 [6] Information Processing Systems - Open Systems Interconnection - 1100 "Specification of the Basic Encoding Rules for Abstract Syntax Notation 1101 One (ASN.1)", International Organization for Standardization. 1102 International Standard 8825, December, 1987. 1104 11. Author Information 1106 Michelle MacRae 1107 Nortel Networks 1108 PO Box 3511 Station C 1109 Ottawa, Ontario K1Y 4H7 1110 Canada 1111 phone: (613) 763-5607 1112 email: crm57a@nortelnetworks.com 1114 Siamack Ayandeh 1115 Nortel Networks 1116 PO Box 3511 Station C 1117 Ottawa, Ontario K1Y 4H7 1118 Canada 1119 phone: (613) 763-3645 1120 email: ayandeh@nortelnetworks.com 1122 12. Full Copyright Statement 1124 "Copyright (C) The Internet Society (1999). All Rights Reserved. 1126 This document and translations of it may be copied and furnished to 1127 others, and derivative works that comment on or otherwise explain it or 1128 assist in its implementation may be prepared, copied, published and 1129 distributed, in whole or in part, without restriction of any kind, 1130 provided that the above copyright notice and this paragraph are 1131 included on all such copies and derivative works. However, this 1132 document itself may not be modified in any way, such as by removing the 1133 copyright notice or references to the Internet Society or other 1134 Internet organizations, except as needed for the purpose of developing 1135 Internet standards in which case the procedures for copyrights defined 1136 in the Internet Standards process must be followed, or as required to 1137 translate it into languages other than English. 1139 The limited permissions granted above are perpetual and will not be 1140 revoked by the Internet Society or its successors or assigns. 1142 This document and the information contained herein is provided on an 1143 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1144 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1145 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1146 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1147 FITNESS FOR A PARTICULAR PURPOSE.