idnits 2.17.1 draft-ietf-l3vpn-ce-based-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 442: '...gnaling message, it MUST check whether...' RFC 2119 keyword, line 454: '...idered CE device MUST reject the incom...' RFC 2119 keyword, line 486: '... document SHOULD use 'permanent' IPs...' RFC 2119 keyword, line 505: '... document MAY use traffic-driven IPs...' RFC 2119 keyword, line 508: '...by this document SHOULD NOT use traffi...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 2003) is 7711 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) == Missing Reference: 'RFC2685' is mentioned on line 354, but not defined == Unused Reference: 'LEE-DHCP' is defined on line 951, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'CE-SOL' -- Possible downref: Normative reference to a draft: ref. 'DUFFY' -- No information found for draft-ietf-ppvpn-framework-0x - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FRAMEWORK' -- Possible downref: Normative reference to a draft: ref. 'GRE-CE' ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) -- No information found for draft-ietf-ipsec-dpd-0x - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPSEC-DPD' -- Possible downref: Normative reference to a draft: ref. 'KNIGHT' -- Possible downref: Non-RFC (?) normative reference: ref. 'LEE-DHCP' ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) -- No information found for draft-touch-ipsec-vpn-0x - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TOUCH' Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jeremy De Clercq 3 INTERNET DRAFT Olivier Paridaens 4 Alcatel 6 Andrew Krywaniuk 7 Cliff Wang 9 March 2003 10 Expires September, 2003 12 An Architecture for 13 Provider Provisioned CE-based Virtual Private Networks 14 using IPsec 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months. Internet-Drafts may be updated, replaced, or obsoleted by 29 other documents at any time. It is not appropriate to use Internet- 30 Drafts as reference material or to cite them other than as a 31 ``working draft'' or ``work in progress.'' 33 To view the entire list of current Internet-Drafts, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 36 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific 37 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 39 Distribution of this memo is unlimited. 41 Abstract 43 This document describes the procedures for a Service Provider to 44 offer Virtual Private Network Services to its customers by 45 provisioning the CE devices on behalf of the customer. The IPsec 46 technology is used to protect the customer traffic. 48 0. SubIP-Area Section 49 SUMMARY 51 The PPVPN framework document [FRAMEWORK] identifies three basic 52 provider provisioned VPN types : Provider Provisioned Network Based 53 (or PE-based) Layer 3 VPNs, Provider Provisioned Layer 2 VPNs and 54 Provider Provisioned CE-based VPNs. 56 This document describes a method enabling a Service Provider to offer 57 VPN services to its customers by provisioning the CE devices on 58 behalf of the customer (Provider Provisioned CE-based VPNs). 60 For a CE-based VPN to be set up under the SP's control, the VPN 61 customer informs the Service Provider of which sites (identified by a 62 set of CE devices) should become part of the considered VPN and what 63 the requested topology of the VPN should look like. The SP then 64 configures and maintains a VPN database and manages the Customer's 65 VPN. 67 The model proposed in this document uses the IPsec protocol suite for 68 the purpose of securing the customer VPN traffic. 70 When the model proposed is used, the addition of one VPN site only 71 requires a minimum amount of configuration. This is obtained via a 72 provisioning scheme using a network management protocol. 74 RELATED DOCUMENTS 76 See References section (especially [CE-SOL], [TOUCH]). 78 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 80 PPVPN box. 82 WHY IS IT TARGETED AT THIS WG 84 This document describes a mechanism for Provider Provisioned CE-based 85 VPNs, which is clearly identified as an item within the scope of the 86 PPVPN WG, as stated from the following WG charter extract: "This 87 working group is responsible for defining and specifying a limited 88 number of sets of solutions for supporting provider-provisioned 89 virtual private networks (PPVPNs). The work effort will include the 90 development of a framework document, a service requirements document 91 and several individual technical approach documents that group 92 technologies together to specify specific VPN service offerings. The 93 framework will define the common components and pieces that are 94 needed to build and deploy a PPVPN. Deployment scenarios will include 95 provider-managed VPN components located on customer premises.". 97 JUSTIFICATION 99 This document is justified by the fact that it defines a solution for 100 PP CE-based VPNs, which are identified as a specific type of PPVPNs 101 both in the WG charter and the general framework I-D. As described in 102 the general framework I-D, PP CE-based VPNs have specific 103 characteristics compared to Network-Based VPNs especially with 104 regards to management and security. 106 Changes since last version 108 Proposed changes to version -02.txt of this document, based on 109 comments received on the ppvpn exploder, have mostly been dealt with 110 in [CE-SOL]. 112 This version -03.txt differs not significantly from the previous 113 version (-02.txt); this allows this (architecture) document to be 114 used for reference's purpose. 116 1. Introduction 118 The PPVPN framework document [FRAMEWORK] identifies three basic 119 provider provisioned VPN types : Provider Provisioned Network Based 120 (also termed PE-based) Layer 3 VPNs, Provider Provisioned Layer 2 121 VPNs and Provider Provisioned CE-based VPNs. 123 This document describes a method enabling a Service Provider to offer 124 VPN services to its customers by provisioning the CE devices on 125 behalf of the customer (Provider Provisioned CE-based VPNs). 127 For a CE-based VPN to be set up under the SP's control, the VPN 128 customer informs the Service Provider of which sites (identified by a 129 set of CE devices) should become part of the considered VPN and what 130 the requested topology of the VPN should look like. The SP then 131 configures and updates its VPN database, and then provisions and 132 manages the Customer's VPN. 134 The model proposed in this document uses the IPsec protocol suite for 135 the purpose of securely tunneling the customer VPN traffic. 137 This specification proposes some mechanisms that can be used to 138 enhance the scalability of the VPN provisioning (e.g. the addition of 139 a VPN site to an existing VPN). 141 2. Reference Model 143 The reference model upon which the mechanisms and procedures 144 described in this document are based, is taken from the CE-based VPN 145 reference model described in [FRAMEWORK]. The most important aspects 146 of that framework model and the restrictions that are relevant to 147 this document are described in this section. 149 +---------+ +------------------------------------+ +---------+ 150 | | | | | | 151 | | | +------+ +------+ : +------+ 152 +------+ : | | | | | | : | CE | 153 | CE | : | | | P | | PE | : |device| 154 |device| : +------+ VPN tunnel |router| |router| : | of | 155 | of |=:====================================================:=|VPN A| 156 |VPN A| : | | +------+ +------+ : +------+ 157 +------+ : | PE | | | : | 158 +------+ : |router| | | : | 159 | CE | : | | VPN tunnel +------+ : +------+ 160 |device|=:====================================================:=| CE | 161 | of | : +------+ | PE | : |device| 162 |VPN B| : | | |router| : | of | 163 +------+ : | | +------------+ +------------+ | | : |VPN B| 164 | : | | | Customer | | Network | +------+ : +------+ 165 |Customer | | | management | | management | | | : | 166 |interface| | | function | | function | | |Customer | 167 | | | +------------+ +------------+ | |interface| 168 | | | | | | 169 +---------+ +------------------------------------+ +---------+ 170 | Access | |<---------- SP network(s) --------->| | Access | 171 | network | | | | network | 173 Figure 1: Reference model for provider provisioned CE-based VPNs 175 2.1 Entities in the reference model 177 o Customer Edge (CE) device 179 In the context of this solution, a CE device is a router located 180 at the edge of a customer site, that has IP connectivity with a 181 SP's PE device. A CE device maintains one or more VPN tunnel 182 endpoints. The VPN-specific functions in the CE device are managed 183 by the SP's management system. It is very common for the SP to 184 manage the complete CE device, while it is also possible for the 185 customer to self-manage part of the CE's functions. In such a 186 situation, the separation of responsabilities is to be clearly 187 defined in the SLA. 189 Note that other functions that are normally applied by the PE 190 router may need to be performed by the CE device in this context 191 (e.g. NAT functionality, QoS classification, etc.). 193 The CE device may also provide general (non VPN-oriented) Internet 194 connectivity for the customer network. Such connectivity may be 195 achieved via the SP's PE router that provides the VPN connectivity 196 or some other router (of the same or another SP). In such a 197 situation, the CE device must be able to distinguish between 198 traffic to be sent through a VPN and traffic to be sent outside 199 any VPN. 201 o Provider Edge (PE) router 203 In the context of Provider Provisioned CE-based VPNs, a PE router 204 is a router, located at the edge of the Service Provider's 205 network, that does not have any VPN-specific functionality. A PE 206 router is attached via an access connection to one or more CE 207 devices, and offers possibly limited or restricted IP connectivity 208 over the access connections to these CE devices. 210 o SP network 212 A SP network is a network administrated by a single service 213 provider. In the context of provider provisioned CE-based VPNs, 214 the SP network consists of the Service Provider's IP (backbone) 215 network and the Service Provider's management functions that 216 manage both its own IP (backbone) network and the VPN customer's 217 VPN functions on the CE devices. 219 o Access connection 221 An access connection represents an isolated layer 2 connectivity 222 between a CE device and a PE router. This includes dedicated 223 physical circuits, logical circuits (such as Frame Relay and ATM), 224 IP tunnels (e.g., using IPsec, L2TP) and shared-medium access 225 (such as Ethernet-based access). In the context of provider 226 provisioned CE-based VPNs, the CE device and the PE router have 227 layer 3 connectivity over the Access Connection. 229 o VPN tunnel 231 A VPN tunnel is a logical link between two entities which is 232 created by encapsulating packets within an encapsulating header 233 for purpose of transmission between those two entities for support 234 of VPNs. In the context of provider provisioned CE-based VPNs, a 235 VPN tunnel is an IP tunnel (e.g., using IPsec, L2TP, GRE, IP-in- 236 IP) between two CE devices over the SP's network. In the context 237 of this document, a VPN tunnel is achieved using IPsec in tunnel 238 mode or via an IP-in-IP tunnel protected by IPsec in transport 239 mode between two CE devices. [GRE-CE] describes how to use GRE 240 encapsulation for CE to CE tunneling in a CE-based IPsec VPN 241 scenario. 243 2.2 Assumed Reachability 245 It is assumed in this specification that the CE devices have at least 246 one IP address that is known to the SP network and that is routable 247 within the SP's network. It is also assumed that every CE device 248 knows how to reach the other CE devices attached to the common SP. 249 This might be via a direct routing entry in the CE's routing table or 250 alternatively via a default route towards the PE device it is 251 attached to. These CE IP addresses will be known in the SP network, 252 if not globally, then at least in the PE devices engaged in the VPN 253 services. 255 This means that either a routing protocol will be running between the 256 CE and the PE device, exchanging routes belonging to the service 257 provider's routing realm; or alternatively, the CE will have a 258 configured default route or static route towards the PE, and the PE 259 will have assigned an IP address to the CE device before or upon 260 set-up of the IP service offered to the CE device. 262 As some of the CE's interfaces are in the SP's routing space and some 263 of the CE's interfaces are in the customer's routing space, CE 264 devices will need to be able to operate in two distinct (separate and 265 possibly overlapping) routing spaces. 267 More details regarding the assumed CE's reachability are provided in 268 [CE-SOL]. 270 2.3 Assumed Service Provider's infrastructure 272 It is assumed that the Service Provider has a secure provisioning 273 channel to every attached CE device. This secure provisioning channel 274 will be used to exchange VPN-specific configuration information 275 between the SP's VPN database and the CE devices. 277 The particular implementation of this provisioning channel is outside 278 of the scope of this document. Some examples are: (i) manual 279 configuration by a trusted party, directly on the considered network 280 element; (ii) via a management protocol running over an IPsec-secured 281 connection between the SP's management center and the considered 282 network element; (iii) via a management protocol that has its own 283 implicit security mechanisms. For scalability reasons, manual 284 configuration is not recommended. 286 3. Configuring the CE-based VPN 287 Note that [CE-SOL] proposes a detailed instantiation of the 288 procedures described in this section. 290 As a Service Provider that is offering VPN services over its backbone 291 network will be responsible for the configuration and the management 292 of a potential large amount of VPNs, it is required that the 293 provisioning actions for the initial establishment and the 294 maintenance of a PP CE-based VPN would be minimal. 296 The minimal configuration required is to first configure the Service 297 Provider's VPN database with the CE device to be part of a well- 298 defined VPN. Further device provisioning can be achieved through the 299 management channel. 301 For the purpose of CE device configuration, the Service Provider will 302 maintain a VPN database per VPN customer. The exchange of information 303 between the SP's VPN database and the targeted CE-devices is achieved 304 using an information exchange/configuration protocol such as LDAP, 305 SNMP, COPS, XML/HTTP etc. We will call this protocol 'the management 306 protocol' throughout the rest of this document. 308 It is assumed for the scope of this document that the management 309 channel used for the configuration information exchange by the chosen 310 protocol is sufficiently secured (e.g. by using a specific IPsec 311 protection for that purpose, or by using a SSL or SSH protected 312 channel, etc.). 314 3.1 (Minimal) configuration needed at the CE device 316 - 'Management channel' information : the information needed to access 317 (or to exchange information with) the SP's VPN database ('database 318 reachability information', authentication information for the VPN 319 database, encryption information for the configuration management 320 channel, necessary credentials, etc.). Note that this is assumed to 321 be present, and that setting up a secure management channel is 322 outside of the scope of this document. 324 - Peer CE devices : the IP addresses (in the SP's realm) of the peer 325 CE devices that belong to the same VPN and to which a direct peering 326 relationship is required. This information can be one IP address 327 (e.g. in the case that the considered CE device is a 'spoke' in a 328 'hub&spoke' topology); this information can be the complete set of 329 the IP addresses of all the other CE devices belonging to the same 330 VPN (in the case of a 'fully meshed' topology); or this information 331 can be a subset of the IP addresses of the CE devices belonging to 332 the same VPN (for more complex topologies). 334 - Security Information : the information needed to set up and 335 maintain IPsec Security Associations with the Peer CE devices: 337 - a set of transforms to use with IPsec (this information relates 338 to the protection of the actual user data packets) for every 339 Security Association. 341 - tunnel property information for every SA that the considered CE 342 participates in : traffic-driven tunnel or 'permanent' tunnel; 343 tunnel mode or IPsec transport mode on an IP-in-IP tunnel; dynamic 344 routing through the tunnel or not. 346 - an IKE credential: (i) a pre-shared key or (ii) a private 347 key/certificate pair and a certificate for a Certificate Authority 348 (these are to be used to establish the IPsec security associations 349 with the peer CE devices). This credential will be used for the 350 generation of the keys for all the Security Associations the 351 considered CE participates in. 353 - VPN identifier: an identifier that uniquely identifies the VPN that 354 the customer belongs to. The VPN identifier defined in [RFC2685] can 355 be used for this purpose, or any unique identifier the PPVPN WG 356 agrees upon. Note that the use of this VPN identifier will be 357 necessary when one site is allowed to be part of more than one VPN, 358 but that this specification does not currently specify that scenario. 359 Another feature that may require the use of a unique VPN identifier 360 is the IKE-based membership discovery mechanism described in section 361 3.2. 363 This means that the VPN database (identified by a VPN identifier) of 364 the SP's management system contains a list of all the CE devices 365 belonging to the specified VPN, a description of the topology (full 366 mesh, hub&spoke, etc.) and some security-related information related 367 to every CE-to-CE tunnel. 369 Note that every CE also needs to be configured as to align the 370 routing within the VPN with the tunneling between VPN sites. Section 371 4 describes these issues in more detail. 373 3.2 Updating configuration information 375 One of the most important requirements relating to scalability for 376 PP-VPNs is that the addition/deletion of a certain site to/from an 377 existing VPN should be possible with a minimal of configuration 378 effort. Manual configuration of the information related to the new 379 site into every existing CE in the particular VPN is not a scalable 380 option. An automatic mechanism for membership discovery/distribution 381 is therefor required. 383 The CE's IP address in the SP's realm, the VPN-ID of the VPN it 384 belongs to, the 'role' of the new site in the existing topology (hub, 385 spoke, etc.), and the necessary security information need to be 386 configured in the concerned VPN database. 388 Different methods to achieve the requested 'automatic' behavior are 389 possible. This section describes some possible approaches but does 390 not claim to be exhaustive. 392 o using the SP's management system 394 In this approach, the customer notifies the SP of the site to be 395 added (out of band), and the SP's management system takes care of 396 configuring its VPN database, takes care of provisioning the new 397 CE device and takes care of updating the other CE devices that 398 belong to the considered VPN. This provisioning also initiates the 399 IPsec signaling between the new CE device and the existing CE 400 devices. 402 o pushing information from the SP's VPN database 404 This approach can be seen as a more detailed description of an 405 example of the previous approach. 407 The customer first notifies the SP of the site to be added. The SP 408 then configures its VPN database with the new membership 409 information. This updating of the VPN database will trigger an 410 information exchange between the SP's VPN database and the 411 concerned CE devices (the new CE device and all the CE devices it 412 has to peer with). This distribution of the updated information 413 happens over a secured 'management channel', via a configuration 414 protocol (such as COPS, DHCP, LDAP, SNMP, etc.). 416 This method implies that the protocol used for the distribution of 417 the configuration information to the CE devices should be usable 418 in a "PUSH" mode from 'server' to 'client' (the management system 419 - server - pushes the updated information to the concerned parties 420 - clients -). It is to be noted that some information distribution 421 technologies such as LDAP are natively not PUSH oriented. If the 422 VPN configuration is stored using such a technology, it is 423 necessary to define a mechanism that enables the CE to be 424 triggered so as to fetch VPN configuration from its repository. 425 Such a mechanism could be based on the use of SNMP messages sent 426 to the CE device, with specific variables that trigger the fetch 427 operation. 429 Note that a solution using this method should integrate it in a 430 reliable architure. 432 o using the SA signaling protocol (IKE) 434 The customer first notifies the SP of the site to be added. The SP 435 then configures the new CE device and its VPN database (this could 436 eventually be done manually). When the new CE device is configured 437 with the required configuration information, it will start the 438 IPsec signaling (via IKE or its successor) with the peer CE 439 devices it is configured with. 441 When a peer CE device (that already belongs to the considered VPN) 442 receives an initial IPsec signaling message, it MUST check whether 443 the initiating CE device belongs to the set of CE devices the 444 considered CE needs to peer with, by looking at its VPN 445 configuration information. If the initiating CE device does not 446 belong to that set according to its VPN configuration information, 447 the CE device needs to update its VPN configuration information by 448 fetching the 'latest' VPN configuration information from the SP's 449 VPN database (e.g. using a protocol for database retrieval such as 450 COPS, DHCP, FTP, HTTP, LDAP, etc.) over the secured management 451 channel. If after the updating of the VPN configuration 452 information, the initiating CE device is still not part of the CE 453 devices the considered CE device has to peer with, then the 454 considered CE device MUST reject the incoming IPsec SA 455 establishment. If the initiating CE device belongs to the set of 456 CE devices that the considered CE device must peer with, then the 457 incoming IPsec SA establishment should be accepted and an IPsec 458 'tunnel' should be established. 460 The details of this procedure are outside of the scope of this 461 document. See [CE-SOL] for a detailed example. 463 3.3 Setting up the VPN tunnels 465 When one VPN site sends traffic to another VPN site belonging to the 466 same VPN, these IP packets will be secured via IPsec. This means that 467 an IPsec Security Association is needed between each pair of sites 468 that directly exchange private VPN data with each other. 470 The Internet Key Exchange protocol (IKE, [IKE]) or its successor will 471 be used for the purpose of automatic setup of security associations 472 between VPN sites within the same VPN. 474 These dynamically established Security Associations can lead to 475 'permanent' IPsec-secured tunnels. These tunnels are always available 476 and not traffic-triggered. It is then required to frequently re- 477 negotiate the SA (via IKE) before the IPsec timers of the connection 478 time out. The set-up of a 'permanent' IPsec tunnel can be triggered 479 by the configuration of a new peer CE device within the same VPN. An 480 advantage of this method is that the IPsec tunnel is always 481 available, and that eventual traffic does not encounter an extra 482 delay due to the setup time of a new SA. The use of 'permanent' IPsec 483 tunnels is recommended for CE-based site-to-site VPNs. 485 Provider provisioned CE-based IPsec VPNs as described by this 486 document SHOULD use 'permanent' IPsec Security Associations when 487 dynamic routing through IPsec-secured tunnels is used. 489 Alternatively, the IPsec SA setup can be triggered by the effective 490 (data) traffic flow going from one site to another. In this case, the 491 arrival of data packets at the CE device, coming from within the VPN 492 site and going to another VPN site, will be noticed by the CE's IPsec 493 or routing database, and an IKE exchange will be initiated to set up 494 an IPsec secured connection between both parties. Once the secure 495 tunnel is set up, the data packets can flow from one site to the 496 other in a secure way. When no traffic flows for a certain duration 497 of time, the secure tunnel will be torn down again. An advantage of 498 this method is that an IPsec tunnel is only to be maintained when 499 there is effectively traffic flowing. A disadvantage is the extra 500 delay introduced for the traffic during IKE signaling and the 501 interaction with the tunneled inter-site VPN routing information 502 distribution. 504 Provider provisioned CE-based IPsec VPNs as described by this 505 document MAY use traffic-driven IPsec SA establishment when static 506 intra-VPN inter-site routing is used (no dynamic routing through the 507 IPsec tunnels), see section 4.3. Provider provisioned CE-based IPsec 508 VPNs as described by this document SHOULD NOT use traffic-driven 509 IPsec SA establishment when dynamic site-to-site routing through the 510 IPsec-secured tunnels is used. 512 The CE configuration determines whether traffic-driven SA 513 establishment is used or not, and whether dynamic routing through 514 IPsec tunnels is used or not. 516 Note that IPsec tunnels are unidirectional in nature, but that the 517 set up of one direction is accompanied by the set up of the reverse 518 direction IPsec tunnel. 520 This document describes two possible ways to use IPsec in CE-based 521 VPN scenarios (see section 5): in 'transport mode' or in 'tunnel 522 mode'. The CE configuration, IKE exchange and resulting SA's must 523 specify which mode will be used. 525 Note that the number of peer CE devices with which a specific CE 526 device must have an IPsec connection to secure the data traffic, is 527 dependent on the specific 'role' of the site in the considered VPN. A 528 hub CE will for example have a larger number of tunnels to support 529 than a spoke device. 531 3.4 VPN resilience 533 When IPsec tunnels are used for VPN site-to-site connection, many 534 times it is important for a SP to provide its customers with 535 connection resilience. The site-to-site VPN could be broken due to 536 either a VPN link failure or a VPN node failure. VPN resilience 537 support would require both VPN node redundancy and VPN link 538 redundancy. 540 To support VPN node redundancy, extra CE routers can be placed. Two 541 deployed CE routers can provide fail-over and potentially load 542 balancing support. It is possible that only one end of a VPN link has 543 redundancy. For example, in a hub-spoke topology, the hub node is 544 more important than a spoke node. It is not unusual to provide 545 redundancy just to the hub router. 547 The VPN link resilience support comes from two levels: IPsec tunnel 548 level and physical link level. To provide physical link redundancy, a 549 customer may subscribe two links from the SP. At the IPsec tunnel 550 level, a customer may set up more than one IPsec tunnel. If the 551 remote site has only a single CE device, both tunnels will terminate 552 at the same device. If the remote site has two CE devices, each 553 tunnel may terminate at different CE devices. 555 When the redundant VPN links connect to two separate CE devices at 556 the remote site, the user (or the SP) must decide how to split the 557 traffic between the two VPN links. One choice is to designate one 558 link as the primary link which carries all the traffic and leave the 559 other idle link as the backup. The other choice is to divide the 560 traffic between the two links. When two links are used, the important 561 issue is to detect any link failure and divert the traffic to the 562 healthy link. One way to achieve this is to run routing keep-alive 563 through both tunnels. When a link is down, the routing protocol is 564 able to discover the link outage and reroute the traffic accordingly. 566 4. Exchanging and maintaining VPN routes 568 One of the requirements for PP CE-based VPNs is that dynamic routing 569 is not only supported within individual VPN sites, but also between 570 the different VPN sites of a specific VPN. This means that when a 571 change in the routing information in a specific site occurs, the 572 other sites that belong to the same VPN must be notified of that 573 change. 575 This document assumes that the routing within a VPN site is 576 controlled by the VPN customer, and thus is outside of the scope of 577 this specification. 579 On the other hand, the role of the CE device with regards to routing, 580 the interaction between the intra-site and inter-site routing and the 581 relationship between routing and VPN tunnels are addressed in this 582 specification. For more detailed aspects concerning issues with 583 regards to routing and CE-based IPsec VPNs, we refer to [TOUCH], 584 [DUFFY] and [KNIGHT]. 586 4.1 The CE device and VPN routing 588 On the customer network side, a CE router connects to internal 589 networks of an enterprise, where one or more subnets can reside. Many 590 times, the CE router may interact with another internal router. 592 The CE is involved in (i) the intra-site routing, (ii) the VPN tunnel 593 termination, and (iii) the inter-site VPN routing. The CE device 594 could be an integrated device providing both routing and IPsec tunnel 595 termination. Sometimes, a dedicated VPN terminator may be used. 596 Implementations in which the VPN tunnel terminator resides on a 597 firewall are also very common. For the sake of simplicity, we assume 598 that the CE router is an integrated device that participates in the 599 intra-site routing (e.g. via an IGP) and at the same time terminates 600 VPN tunnels. 602 In the context of this document, the routing aspects within a VPN 603 site (intra-site routing information distribution) are controlled by 604 the VPN customer. The role of the SP is either to completely manage 605 the inter-site reachability distribution or to configure the CE 606 devices in such a way that the customer may transparently run routing 607 protocols (or configure static routes) through the VPN tunnels. 609 4.2 IPsec and routing 611 IPsec is a layer 3 tunneling protocol, which operates purely at the 612 IP layer. The IETF IPsec Working Group specifies the IPsec standards 613 ([IPSEC], [RFC2402], [RFC2406], [RFC2407], [RFC2408], and [IKE]). The 614 interaction between IPsec and layer 3 routing is often troublesome 615 and has been described in [DUFFY], [TOUCH] and [KNIGHT]. Depending on 616 individual implementations, difficulty may arise when an IPsec user 617 wants to support robust routing across IPsec VPNs sites. 619 Details regarding the problems of the interaction between VPN routing 620 and VPN tunneling, and some proposed solutions to counter these 621 issues, can be found in [DUFFY], [TOUCH] and [KNIGHT]. 623 4.3 Mechanisms to exchange VPN routes between VPN sites 624 This document describes two alternative mechanisms for the purpose of 625 exchanging VPN routes between VPN sites. The mechanism that is in use 626 for a particular tunnel is identified by the CE configuration 627 information. 629 4.3.1 Tunneling routing information between CE devices through the IPsec 630 tunnels. 632 In the first mechanism to exchange VPN reachability information, 633 normal routing protocol messages are tunneled through the IPsec- 634 secured tunnels between peering sites. The CE-to-CE IPsec-secured 635 tunnels between VPN sites are then being seen as point-to-point links 636 by the customer networks and are inserted as such in the routing 637 protocol functions of the CE devices. This means that when a change 638 in the reachability occurs in one particular site, a routing protocol 639 (such as RIP, OSPF, etc.) will take care of the distribution of the 640 new reachability information within the site, but also to all other 641 sites, through the VPN tunnels that the considered CE is peering 642 with. 644 When routing protocol messages are tunneled through the IPsec-secured 645 tunnels ('dynamic routing through IPsec-secured tunnels') as per this 646 section, IPsec transport mode secured IP-in-IP tunnels as per [TOUCH] 647 SHOULD be used (in contrast to IPsec tunnel mode tunnels). 649 Note that other approaches may use a combination of dynamic routing 650 and IPsec tunnel mode tunnels, though it is not clear how 651 interoperability will then be assured. 653 Another issue to consider is the fact that using a traffic-driven 654 tunnel establishment mechanism and at the same time using an approach 655 whereby a routing protocol (with a keep-alive mechanism) runs on top 656 of the VPN tunnel, does not seem currently applicable: the delay 657 introduced by the tunnel establishment phase could lead to a loss of 658 routing updates and the routing protocol's keep-alive mechanism could 659 interact with the tunnel establishment in an undesired way. Therefor, 660 when dynamic routing is used through IPsec-secured CE-to-CE tunnels, 661 traffic-driven SA establishment SHOULD NOT be used. 663 4.3.2 Exchanging VPN reachability information via SP's management 665 In non-dynamic environments, SP's management can distribute static 666 routes to the CE devices. 668 When CE-to-CE IPsec tunnel mode tunnels are used (with the complete 669 SPD-controlled filtering), a management-based inter-site reachability 670 information distribution SHOULD be used. 672 When traffic-driven SA establishment is used, a management-based 673 inter-site reachability information distribution SHOULD be used. 675 Within the sites themselves, the CE device may then inject the 676 updated reachability information into the local routing protocol 677 function. 679 Note that this method does not require the use of the same 680 'management protocol' for the configuration of the CE device and for 681 the dynamic exchange of reachability information. A dedicated 682 protocol may be used for that purpose. 684 4.3.3 Applicability of the mechanisms to exchange VPN routes between the 685 VPN sites 687 The 'tunneling approach' (as described in section 4.3.1) does not 688 require a new interaction between the customer and the SP and offers 689 transparent routing features to the VPN customer. Existing routing 690 protocols can be used and the SP is not involved with the propagation 691 of routing information updates. It prohibits some specific IPsec 692 features though (such as traffic-initiated SA establishment, and the 693 complete use of SPD-based filtering). 695 The 'management approach' (as described in section 4.3.2) allows for 696 the full use of specific IPsec features, but requires a new 697 interaction between the CE device and the SP, and breaks the VPN 698 customer's routing transparency. The SP participates in the inter- 699 domain distribution of routing information. 701 4.4 Relationship between VPN membership, VPN tunnel status and routing 703 When VPN membership changes, VPN tunnels may need to be intentionally 704 deleted, and this change needs to be reflected in the routing 705 information of all sites belonging to the VPN (see section 6). 707 But VPN tunnels can also un-intentionally break for a variety of 708 reasons. The routing within the VPN will be affected and updated 709 information must be distributed over all VPN sites. 711 5. Tunneling IP traffic (user data) among VPN sites 713 This section describes the processes that an IP packet that is sent 714 from one VPN site to another will go through. This is dependent on 715 the way that IPsec is used. This document describes two possible ways 716 to use IPsec in CE-based VPN implementations: IPsec in tunnel mode, 717 and IPsec in transport mode. 719 An IP packet that is sent by an IP device in a certain site and 720 destined for an IP device in another site belonging to the same VPN, 721 will be forwarded as follows. 723 The device in the sending site sends an IP packet (using a private 724 address space) on its LAN network. The next hop for this destination 725 IP address will (at some point in time) be the site's CE device 726 (according to the routing/forwarding in the VPN site). The processing 727 by the CE device now is dependent on the implemented mode for IPsec. 729 The use of IPsec in tunnel mode has the advantage that the complete 730 range of SPD-checks remain usuable, but has the disadvantage that 731 dynamic routing through the tunnels is not supported. The use of 732 IPsec in transport mode secured IP-in-IP tunnels has the advantage 733 that dynamic routing through the tunnels is fully supported, but has 734 the disadvantage that the complete range of SPD-checks is not 735 supported. 737 Note that the following description is not meant to specify an 738 implementation strategy; any implementation procedure wich produces 739 the same results is acceptable. 741 o IPsec in tunnel mode 743 When IPsec is used in tunnel mode in this context, the IPsec 744 driver in the CE device must do the following: 746 - analyze the private IP packets arriving from within the site and 747 select/setup an appropriate SA with the appropriate destination CE 748 device. 750 - authenticate and/or encrypt the private IP packet according to 751 the (tunnel mode-specific) rules described in the SA, AND 752 encapsulate the packet in an IPsec header AND encapsulate the 753 packet in a new 'outer' IP header. This 'outer' IP header has the 754 CE's non-private (i.e. routable in the SP's realm) IP address in 755 the source IP address field and the destination CE's non-private 756 (i.e. routable in the SP's realm) IP address in the destination IP 757 address field. 759 o IPsec in transport mode (see also [TOUCH] for a detailed 760 specification) 762 When IPsec is used in transport mode in this context, the CE 763 device must first analyze the private IP packets arriving from 764 within the site and select the appropriate destination CE, based 765 on the routing/forwarding information. The CE device then 766 encapsulates the private IP packet into a new IP packet (IP-in-IP 767 encapsulation/tunneling), with the own non-private (i.e. routable 768 in the SP's realm) IP address in the source address field of the 769 new header and the destination CE's non-private (i.e. routable in 770 the SP's realm) IP address in the destination address field of the 771 new header. The CE device then processes this new IP packet to its 772 IPsec driver. 774 The IPsec driver in the CE device must then do the following: 776 - analyze the IP packets that have been IP-in-IP encapsulated and 777 select the appropriate SA (based on the packet's outer header 778 destination address). 780 - authenticate and/or encrypt the private IP packet according to 781 the (transport mode-specific) rules described in the SA and insert 782 an IPsec header (according to IPsec in transport mode). 784 The CE device then sends the IPsec packet to the PE device, and the 785 IPsec packet will then be forwarded using 'normal' IP forwarding 786 across the SP's network, based on the outer header's IP destination 787 address, that is the destination CE's 'global' (i.e. routable in the 788 SP's realm) IP address. The egress PE device will also only examine 789 the outer IP header and send the IP(sec) packet to the destined CE 790 device. The egress CE device will recognize itself as the destination 791 node (the IP packet has the CE's IP address in the outer IP 792 destination address field). The destination CE's IPsec driver will 793 then, based on the appropriate Security Association (identified by 794 the packet's SPI field in the IPsec header), perform IPsec 795 authentication and/or decryption. Dependent on whether tunnel mode or 796 transport mode IPsec is used, the packet will be decapsulated by the 797 IPsec driver itself or sent to the IP-in-IP decapsulation function. 798 The resulting (private) IP packet will then be further processed in 799 the CE's IP forwarding table and send on the LAN network to the 800 appropriate destination IP device. 802 Note that IPsec tunnels might unintentionally terminate or break. 803 This may have serious consequences if VPN membership and VPN routing 804 information is not changed accordingly within the VPN. Indeed, the 805 unnoticed termination of a VPN tunnel can result in the creation of 806 black holes. 808 This means that a mechanism must exist to monitor the state of the 809 VPN tunnels. The following possibilities are identified: (i) the use 810 of an IPsec-specific keep-alive mechanism [IPSEC-DPD]; (ii) when a 811 routing protocol runs on top of the IPsec VPN tunnel (see section 812 4.3.1), the routing protocol's keep-alive mechanism can serve that 813 purpose; and (iii) the SP's management system could directly control 814 the state of the VPN tunnels. 816 6. Deleting an existing VPN site 818 When the VPN customer decides to delete an existing site from a 819 certain VPN, the customer first needs to inform the SP. The SP will 820 change the VPN's configuration information accordingly in its VPN 821 database. 823 In analogy with the configuration update mechanisms described in 824 section 3.2, multiple approaches exist to delete a specific site from 825 an existing VPN. 827 The SP can gracefully tear down all the concerned IPsec tunnels at 828 both ends via either manual configuration or via a re-provisioning of 829 all impacted CE devices with the used management system. IKE will 830 then be used to tear down the IPsec security associations. 831 Alternatively, the IKE sessions could be just timed out. 833 Alternatively, when IKE-based discovery is used, the SP will update 834 its VPN database and will provision the to-be deleted CE to tear down 835 its IPsec connections via IKE. The peering CE devices will then 836 update their VPN configuration information as described in section 837 3.2. 839 In the meantime, if a routing protocol runs on top of the VPN tunnels 840 (and keep-alives are used), it will discover the topology change and 841 update the necessary routing information automatically. If on the 842 other hand, the SP management takes care of the inter-site routing 843 information distribution, it will have to update the routes in the 844 affected CEs when VPN tunnels are deleted. 846 7. Provider provisioned CE-based VPNs and NAT 848 NAT provides address translation between two realms, such as between 849 the private address space and the public address space. For site-to- 850 site intranet VPN, the tunneled data usually remain in the same 851 customer network address space. NAT is usually not required, unless 852 two sites have overlapping address spaces. In that case, NAT can be 853 used to solve the address-overlapping problem. 855 In normal IPsec tunnel mode operation, after the user data is 856 encapsulated by IPsec, the resulted packets are protected by packet 857 encryption and/or authentication. Any further NAT changes on the 858 packets will be detected at the receiving tunnel end, resulting in 859 the packets being dropped. Currently the IPsec Working Group is 860 working on a new mechanism so that IPsec packet can be safely NATed. 861 Before the IPsec WG finalizes the IPsec over NAT standards, this 862 draft assumes that there is no NAT function performed between the two 863 IPsec tunnel end points. 865 The scenario in which NAT applies is when the CE router serves a 866 split stack function and provides both site-to-site VPN connection 867 and direct Internet access. In this case, customer address space 868 traffic is separated into two streams, one part for site-to-site 869 private traffic and one part for direct Internet traffic. In this 870 case the CE device performs NAT processing for the direct Internet 871 traffic. The NAT function performed by the CE router takes care of 872 the customer address space to public Internet address space 873 conversion. Note that in the case that a certain site has both VPN 874 and Internet access, a firewall should be configured at the site's CE 875 device. 877 See [CE-SOL] for more details concerning solutions for simultaneous 878 VPN and Internet Access connectivity. 880 8. Extranet functionality with provider provisioned CE-based VPNs 882 For the time being, this document deals mostly with intranet 883 functionality provided by CE-based VPNs. The provisioning of an 884 extranet service will affect the routing, tunnel topology and 885 security features of the concepts described so far. The PP CE-based 886 extranet VPN functionality is TBD. 888 9. Quality of Service 890 TBD 892 10. Security Considerations 894 The security aspects of what is presented in this document are 895 implicitly discussed in most of the sections. This draft is for a 896 large part focussing on security aspects. 898 Note that the security of the mechanisms presented here is highly 899 dependent on the following factors: 901 - the security of the 'management channel', used by the management 902 protocol to configure the VPN CE devices. 904 - the security of the CE-device itself 906 - the security aspects of the credentials: the IPsec credential 907 must be generated, provisioned, updated, and stored securely 909 - for a VPN with a complex topology, every tunnel must use the 910 same grade of security strength, otherwise, a single weak link 911 degrades the whole VPN 913 11. Acknowledgements 915 The authors would like to thank the following persons for their 916 valuable contributions to this document: Mahadevan Iyer, Cheng-Yin 917 Lee, Lars Eggert, Brian Gleeson, Archana Khetan, Paul Knight, Sankar 918 Ramamoorthi, Eric Rosen, Michael Choung Shieh, Joe Touch, Eric 919 Vyncke, S. Felix Wu, Yu-Shun Wang, Alex Zinin. 921 12. References 923 [CE-SOL] De Clercq, J., Lee, C., Knight, P., "Provider Provisioned 924 CE-based Virtual Private Network solution using IPsec and HTTP", 925 draft-declercq-ppvpn-ce-based-sol-00.txt, Work in progress 927 [DUFFY] Duffy, M., "Framework for IPsec Protected Virtual Links for 928 PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00.txt, Work in progress 930 [FRAMEWORK] Callon, R. et al., "A Framework for Layer 3 Provider 931 Provisioned Virtual Private Networks", draft-ietf-ppvpn-framework- 932 0x.txt, Work in progress 934 [GRE-CE] Khetan, A., et al., "Use of GRE for routing support in IPsec 935 VPNs", draft-khetan-sp-greipsec, Work in progress 937 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", 938 November 1998, RFC 2409 940 [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the 941 Internet Protocol", November 1998, RFC 2401 943 [IPSEC-DPD] Huang, G., Beaulieu, S., Rochefort, D., "A Traffic-Based 944 Method of Detecting Dead IKE Peers", draft-ietf-ipsec-dpd-0x.txt, 945 Work in progress 947 [KNIGHT] Knight, P., Gleeson, B., "A Method to Signal and Provide 948 Dynamic Routing in IPsec VPNs", draft-knight-ppvpn-ipsec-dynroute, 949 Work in progress 951 [LEE-DHCP] Lee, C.Y., "Customer Equipment Auto-configuration", March 952 2002, work in progress 954 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", 955 November 1998, RFC 2402 957 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 958 (ESP)", November 1998, RFC 2406 960 [RFC2407] Piper, D., "The Internet IP Security Domain of 961 Interpretation for ISAKMP" November 1998, RFC 2407 963 [RFC2408] Maughan, D., et al., "Internet Security Association and Key 964 Management Protocol (ISAKMP)", November 1998, RFC 2408 966 [TOUCH] Touch, J. and Eggert, L., "Use of IPSEC transport mode for 967 Virtual Networks", draft-touch-ipsec-vpn-0x.txt, Work in progress 969 13. Authors' Addresses 971 Jeremy De Clercq 972 Alcatel 973 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 974 E-mail: jeremy.de_clercq@alcatel.be 976 Olivier Paridaens 977 Alcatel 978 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 979 E-mail: olivier.paridaens@alcatel.be 981 Cliff Wang