idnits 2.17.1 draft-ietf-l3vpn-ce-based-02.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. == 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 225: '...s. The CE device MUST be reachable fro...' RFC 2119 keyword, line 264: '...ng the CE device MUST always be the CE...' RFC 2119 keyword, line 316: '... same VPN MAY be interconnected via ...' RFC 2119 keyword, line 434: '... devices SHOULD support both modes o...' RFC 2119 keyword, line 503: '... the considered CE SHOULD subsequently...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 137 has weird spacing: '...ctivity with ...' -- 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 2004) is 7376 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: 'IKEv2' is mentioned on line 474, but not defined == Unused Reference: 'LEE-DHCP' is defined on line 1151, but no explicit reference was found in the text -- 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' -- No information found for draft-ietf-l2tpext-l2tp-base-0x - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L2TP' ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT') ** 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 (~~), 4 warnings (==), 14 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 5 Andrew Krywaniuk 6 Cliff Wang 8 February 2004 9 Expires August, 2004 11 An Architecture for 12 Provider Provisioned CE-based Virtual Private Networks 13 using IPsec 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months. Internet-Drafts may be updated, replaced, or obsoleted by 28 other documents at any time. It is not appropriate to use Internet- 29 Drafts as reference material or to cite them other than as a 30 ``working draft'' or ``work in progress.'' 32 To view the entire list of current Internet-Drafts, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 35 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific 36 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 38 Distribution of this memo is unlimited. 40 Abstract 42 This document describes the procedures for a Service Provider to 43 offer Virtual Private Network Services to its customers by 44 provisioning the CE devices on behalf of the customer. The IPsec 45 technology is used to protect the customer traffic. 47 Table of Contents 48 1. Introduction ................................................ 2 49 2. Reference Model ............................................. 3 50 2.1 Entities in the Reference Model ............................. 3 51 2.2 IP Connectivity between CE and PE devices ................... 5 52 2.3 Assumed Service Provider's Infrastructure ................... 7 53 3. Configuring the CE-based VPN ................................ 8 54 3.1 Initializing the SP's VPN database .......................... 8 55 3.2 Pre-configuration of the CE device .......................... 9 56 3.3 Fetching the VPN configuration information .................. 10 57 3.4 Establishing the (secure) VPN tunnels ....................... 10 58 3.5 Updating the VPN configuration information .................. 13 59 3.6 Removing an existing VPN site ............................... 13 60 4. Exchanging and maintaining VPN routes ....................... 14 61 4.1 The CE device and VPN routing ............................... 15 62 4.2 IPsec and routing ........................................... 16 63 4.3 Exchanging VPN routes between VPN sites ..................... 16 64 5. Tunneling IP traffic (user data) among VPN sites ............ 17 65 6. CE-based VPN and Internet ................................... 19 66 6.1 Allowing both VPN connectivity and Internet connectivity .... 19 67 6.2 Prohibiting or restricting Internet connectivity from within 68 a CE-based VPN .............................................. 22 69 7. Security Considerations ..................................... 24 70 8. Acknowledgements ............................................ 25 71 9. References .................................................. 25 72 10. Authors' Addresses .......................................... 26 74 1. Introduction 76 The L3VPN framework document [FRAMEWORK] identifies three basic 77 provider provisioned VPN types : Provider Provisioned Network Based 78 (also termed PE-based) Layer 3 VPNs, Provider Provisioned Layer 2 79 VPNs and Provider Provisioned CE-based VPNs. 81 This document describes a method enabling a Service Provider to offer 82 IP VPN services to its customers by provisioning the CE devices on 83 behalf of the customer (Provider Provisioned CE-based VPNs). This 84 document describes which parameters need to be provisioned, but not 85 which protocol to use for the provisioning. 87 For a CE-based VPN to be set up under the SP's control, the VPN 88 customer informs the Service Provider of which sites (identified by a 89 set of CE devices) should become part of the considered VPN and what 90 the requested topology of the VPN should look like. The SP then 91 configures and updates its VPN database, and then provisions and 92 manages the Customer's VPN. 94 The model proposed in this document uses the IPsec protocol suite for 95 the purpose of securely tunneling the customer VPN traffic and the 96 inter-site reachability information distribution. 98 2. Reference Model 100 The reference model upon which the mechanisms and procedures 101 described in this document are based, is taken from the CE-based VPN 102 reference model described in [FRAMEWORK]. The most important aspects 103 of that framework model and the restrictions that are relevant to 104 this document are described in this section. 106 +---------+ +------------------------------------+ +---------+ 107 | | | | | | 108 | | | +------+ +------+ : +------+ 109 +------+ : | | | | | | : | CE | 110 | CE | : | | | P | | PE | : |device| 111 |device| : +------+ VPN tunnel |router| |router| : | of | 112 | of |=:====================================================:=|VPN A| 113 |VPN A| : | | +------+ +------+ : +------+ 114 +------+ : | PE | | | : | 115 +------+ : |router| | | : | 116 | CE | : | | VPN tunnel +------+ : +------+ 117 |device|=:====================================================:=| CE | 118 | of | : +------+ | PE | : |device| 119 |VPN B| : | | |router| : | of | 120 +------+ : | | +------------+ +------------+ | | : |VPN B| 121 | : | | | Customer | | Network | +------+ : +------+ 122 |Customer | | | management | | management | | | : | 123 |interface| | | function | | function | | |Customer | 124 | | | +------------+ +------------+ | |interface| 125 | | | | | | 126 +---------+ +------------------------------------+ +---------+ 127 | Access | |<---------- SP network(s) --------->| | Access | 128 | network | | | | network | 130 Figure 1: Reference model for provider provisioned CE-based VPNs 132 2.1 Entities in the reference model and Terminology 134 o Customer Edge (CE) device 136 In the context of this solution, a CE device is a router located 137 at the edge of a customer site, that has IP connectivity with a 138 SP's PE device (not necessarily Internet connectivity). A CE 139 device maintains one or more VPN tunnel endpoints. The VPN- 140 specific functions in the CE device are provisioned by the SP. 142 Note that other functions that are normally applied by the PE 143 router may need to be performed by the CE device in this context 144 (e.g. NAT functionality, QoS classification, etc.). These 145 functions may be managed by the SP or alternatively be managed by 146 the VPN customer, depending on the applicable service contract. 148 The CE device may also provide general (non VPN-oriented) Internet 149 connectivity for the customer network. Such connectivity may be 150 achieved via the SP's PE router that provides the VPN connectivity 151 or some other router (of the same or another SP). In such a 152 situation, the CE device must be able to distinguish between 153 traffic to be sent through a VPN and traffic to be sent outside 154 any VPN. Section 6 of this document discusses this in more 155 details. 157 CE devices in a CE-based VPN model differ from CE devices in a 158 PE-based VPN model in that they need to support VPN-specific 159 functions. With CE-based PPVPNs, the VPN awareness is pushed even 160 further towards the edges of the provider networks. 162 o Provider Edge (PE) router 164 In the context of Provider Provisioned CE-based VPNs, a PE router 165 is a router, located at the edge of the Service Provider's 166 network, that does not have any VPN-specific functionality. A PE 167 router is attached via an access connection to one or more CE 168 devices, and offers possibly limited or restricted IP 169 connectivity over the access connections to these CE devices. 171 o SP network 173 A SP network is a network administrated by a single service 174 provider. In the context of PP CE-based VPNs, the SP who owns the 175 SP network can also be the VPN provider (managing the CE devices). 176 This can lead to operational advantages (e.g. for offering QoS). 177 Alternatively, the SP owning the SP network may be an ISP offering 178 Internet connectivity, while an other entity may provision the VPN 179 service. This configuration allows for inter-SP and Internet-wide 180 VPN scenarios. 182 o Access connection 184 An access connection represents a layer 2 connectivity between a 185 CE device and a PE router. This includes dedicated physical 186 circuits, logical circuits (such as Frame Relay and ATM), IP 187 tunnels (e.g., using IPsec, L2TP) and shared medium access (such 188 as Ethernet-based access). In the context of provider provisioned 189 CE-based VPNs, the CE device and the PE router have layer 3 190 connectivity over the Access Connection. 192 o VPN tunnel 194 A VPN tunnel is a logical link between two entities which is 195 created by encapsulating packets within an encapsulating header 196 for purpose of transmission between those two entities for support 197 of VPNs. In the context of provider provisioned CE-based VPNs, a 198 VPN tunnel is an IP tunnel (e.g., using IPsec [IPSEC], L2TP 199 [L2TP], GRE [GRE], IP-in-IP [IPinIP]) between two CE devices over 200 the SP's network. In the context of this document, a VPN tunnel is 201 achieved using IPsec in tunnel mode or via an IP-in-IP tunnel 202 protected by IPsec in transport mode between two CE devices. 203 [GRE-CE] describes how to use GRE encapsulation for CE to CE 204 tunneling in a CE-based IPsec VPN scenario. 206 o Security Association (SA) 208 Throughout this document, the acronym SA will be used to denote an 209 IPsec Security Association. 211 2.2 IP connectivity between CE and PE devices 213 CE devices operating in a PP CE-based VPN will operate in two 214 independent IP routing spaces. 216 The first routing space is the VPN routing space. Hosts and routers 217 within the VPN will use IP addresses that belong to this VPN routing 218 space. The CE router will participate in this VPN routing space, and 219 will create VPN tunnels (virtual links) to be used as virtual 220 interfaces by this VPN routing space. 222 The second routing space is the SP's routing space. Every CE device 223 that belongs to a PP CE-based VPN is identified by an IP address that 224 is routable in the SP's network. This IP address may be a global IP 225 address or a private IP address. The CE device MUST be reachable from 226 the SP's core network via this IP address. 228 In order to easily differentiate between these two routing spaces, 229 this document uses the following convention: IP addresses belonging 230 to the VPN's routing realm will be followed by a 'v' between 231 brackets: address (v); IP addresses belonging to the service 232 provider's routable space will be followed by a 's' between brackets: 233 address (s). 235 These two routing spaces may use overlapping address spaces and thus 236 need to be kept separate in the CE devices. The way this is done is 237 largely implementation dependent. This may be by using two separate 238 sets of (virtual) routing and forwarding tables (figure 2). These 239 routing tables may then run independent routing protocols. 241 Only the CE's IP address (s) needs to be reachable in the provider's 242 core network. This means that this approach requires only one IP 243 address (s) per CE device to be injected in the core network. A CE 244 device should not inject other routes into the SP's network (one 245 exception is for Internet Access scenarios, that are discussed in 246 section 6). In many cases, this CE's IP address (s) may be an IP 247 address assigned by the SP who owns the core network. As such, 248 aggregate routes can be distributed by the PE devices into the core 249 network. 251 The CE device and the PE device may be routing protocol peers in the 252 SP's routing space. Alternatively, a default route (s) (towards the 253 PE) may be statically configured in the SP's routing space on the CE 254 device, and the CE device's IP address (s) statically configured on 255 the PE. The CE device should not inject SP's routes (s) towards the 256 other routers within its VPN site (except in the context of the 257 Internet Access scenarios described in section 6). 259 Note that, when the CE device is attached to only one PE device, via 260 only one (sub-)interface, the CE's implementation can be fairly 261 straightforward (see figure 3). With regards to the SP routing space, 262 the CE device then acts as a host, having only one outgoing 263 interface. The source IP address (s) (of the _outer_ IP header) of 264 all packets leaving the CE device MUST always be the CE's identifier, 265 and the IP next hop will always be the PE device to which it is 266 attached. On the CE, no routing decisions need to be performed in the 267 provider's routing space and only one forwarding action is possible. 269 The following figures give an overview of the routing spaces in the 270 CE device. Note that this description is merely an example and is not 271 meant to specify a particular implementation: every implementation 272 that results in the same behaviour described throughout this 273 specification is acceptable. 275 Section 5 describes the end-to-end processing of customer data- 276 packets in more details. 278 CE device 279 ---------------------------------------------------------- 280 | ____________ ======== |I| ______________ __|__ PE_1 281 | |routing and | ======== |P| |routing and | / | 282 | |forwarding | ======== |s| |forwaring in |< | 283 | |in VPN space| ======== |e| --- |provider space| |__|__ PE_2 284 | | IP(v) | ======== |c| | IP(s) | | 285 | ------------ = = = = | | -------------- | 286 | IP(v)-in-IP(s) | 287 |__________________________________________________________| 289 <- - - - - - - - - - - - -><- - - - - - - - - - - - - - - - - - - - > 290 VPN space SP space 291 figure (2): routing spaces in the CE device 292 (''VPN space'' = customer ''private'' space) 294 ---------------------------------------------- 295 | ____________ ========== to CE_2 |I| | 296 | |routing and | ========== to CE_3 |P| | 297 | |forwarding | ========== to CE_4 |s|----|--- PE 298 | |in VPN space| ========== to CE_5 |e| | 299 | | IP(v) | ========== to CE_6 |c| | 300 | ------------ = = = = = | | | 301 | IP(v)-in-IP(s) | 302 |______________________________________________| 304 <- - - - - - - - - - - - ><- - - - - - - - - - - - - - - -> 305 VPN space SP space 306 figure (3): the CE is connected to only one PE device 308 Note that there are no routing protocols operating in both routing 309 spaces simultaneously. Packets can only go from one routing space to 310 the other routing space via either (IP-in-IP) tunneling or after 311 firewall and possibly NAT processing (as described in section 6). 313 This approach enables the CE devices to reach each other via tunnels 314 over the SP's network, but does not prevent the interconnection of CE 315 devices via so-called "backdoor routes". CE devices belonging to the 316 same VPN MAY be interconnected via "backdoor routes". If "backdoor 317 routes" are present in a certain VPN, the VPN's routing protocol 318 metrics will dictate which routes will be used as the prefered routes 319 for certain destinations. 321 2.3 Assumed Service Provider's infrastructure 323 The service provider maintains a secured VPN database (e.g. on a 324 centralized server). One such VPN database may be used for the 325 provisioning of many VPNs. As the number of VPNs to be provisioned 326 grows, other servers may be deployed. As such, the scalability of no 327 single device is dependent on the total number of VPNs. 329 In order to provide a reliable service, the SP may choose to deploy 330 backup VPN database servers that it keeps synchronized with the 331 primary server. 333 The Service Provider's VPN management infrastructure needs to have a 334 secure provisioning channel to every attached CE device. This secure 335 provisioning channel will be used to exchange VPN-specific 336 configuration information between the SP's VPN database and the CE 337 devices. 339 Note that this document does not prescribe one particular protocol 340 for this provisioning channel. Some examples are: SOAP/XML/HTTP/TLS, 341 CLI/Telnet/SSH, an IPsec-protected remote configuration protocol, 342 etc. 344 As the SP will be responsible for provisioning the secure tunnels 345 between the CE devices, it needs to deploy a key management system. 347 3. Configuring the CE-based VPN 349 As was noted before, this specification does not describe the 350 protocol to use as a remote management protocol to provision CE 351 devices. It does however describe with which information CE devices 352 need to be pre-provisioned, and which parameters need to be 353 configurable via this management protocol by the Service Provider. 355 3.1 Initializing the VPN database 357 As a first step in the VPN configuration process, the Service 358 Provider configures its VPN database with a new VPN entry and with 359 the IP addresses (s) of the CE devices belonging to the VPN, and with 360 a description of the VPN's topology. 362 For every CE device, the following information must be configured and 363 maintained in the VPN database: 365 - the security information that is necessary for the secure remote 366 management protocol. This information should allow for mutual 367 authentication between CE and SP's VPN server, and for encryption 368 of the management data. The detials of this information will 369 depend on the particular protocol (stack) used for remote 370 management 372 - the security information that is necessary for the CE device to 373 establish and maintain Security Associations with its peer CE 374 devices belonging to the same VPN; section 3.3 defines which is 375 the minimal set of information a CE device should be able to 376 retrieve/receive fromt the SP's VPN management server. 378 3.2 Pre-configuration of the CE device 380 This document uses the term "pre-configuration" for the initial 381 provisioning of a CE device. This pre-configuration happens before a 382 CE is attached to a VPN (before the considered site actively belongs 383 to the VPN). This pre-configuration can be performed by the SP before 384 shipping the CE device to the customer's premises. Alternatively, the 385 SP can pre-provision the CE device manually at the customer's 386 premises. Another possibility is for the SP to tell the customer how 387 to pre-provision its CE device. Finally other scenarios such as 388 remote management with for example secured SNMP are also possible. 390 Every CE device participating in a VPN needs to be pre-provisioned 391 with the necessary configuration information that enables it to 392 establish a secure communication path with the SP's VPN server. 394 The CE device must be configured with the IP address (s) of the 395 Service Provider's VPN server or with a URL to the required CE's 396 VPN information on the Service Provider's VPN database. 398 The CE device must be configured with the security information 399 required by the SP's secure remote management protocol (stack). 401 And finally, the CE device must be ''pre-configured'' with the CE's 402 IP address (s) in the SP's space. 404 As mentioned before, the CE device is identified by an IP address (s) 405 that belongs to the Service Provider's routing space. This IP address 406 (s) may be an IP address assigned by the SP and manually configured 407 on the CE device, together with the other (pre-) configuration 408 information (this would require this IP address (s) to be configured 409 as a static route on the attached PE too). Alternatively, the CE may 410 dynamically obtain this IP address (s), using for example DHCP or 411 IPCP over the CE-PE link. Yet another possibility is that the CE 412 device has obtained a (global) IP address (s) from an ISP, and that 413 the VPN customer communicates this IP address (s) to the VPN Service 414 Provider. Note that the CE device needs to maintain this same IP 415 address (s) at least for the duration of its VPN membership. 417 Note that other information, such as timer-parameters etc. may be 418 configurable by the SP. These parameters can be provisioned by the SP 419 at pre-configuration time. 421 3.3 Fetching the VPN configuration information 423 The VPN service is initialized by the CE device by retrieving the VPN 424 configuration information from the SP's VPN database using the 425 appropriate secure remote configuration channel. 427 The CE device will retrieve from the SP's VPN server the information 428 that is necessary to establish IPsec-secured tunnels with the other 429 CE devices that belong to the same VPN (and to which it should 430 establish a virtual VPN link - dependend on the VPN topology). The SP 431 may choose to let the CE devices authenticate the IKE negotiations 432 between CE devices using (i) pre-shared keys or (ii) digital 433 signatures and certificates. The IPsec implementation on the CE 434 devices SHOULD support both modes of authentication. 436 (i) in case of pre-shared keys, the following information is to be 437 retrieved from the SP's VPN server: 439 - a list of tuplets 442 (SA information = the necessary information to negotiate a SA 443 with the peer CE: security protocol, Diffie-Hellman group, 444 IPsec transforms, etc. The (optional) presence of this 445 information will overwrite possible default values in the CE) 447 (tunnel information : traffic-driven tunnel or 'permanent' 448 tunnel; tunnel mode IPsec or transport mode IPsec over an IP- 449 in-IP encapsulation; dynamic routing trough the tunnel or not) 451 (ii) in case of digital signature authentication, the following 452 information is to be retrieved from the SP's VPN server: 454 - a pair 456 - a certificate for the public key 458 - a public key from the Certificate Authority 460 - a list of tuplets 463 The above information is maintained on the SP's VPN server, and sent 464 to the CE device when necessary. 466 3.4 Establishing the (secure) VPN tunnels/SAs 468 When one Site sends traffic to another Site belonging to the same 469 VPN, these IP packets will be secured via IPsec. This means that an 470 IPsec Security Association is needed between each pair of sites that 471 directly exchange private VPN data with each other. 473 The Internet Key Exchange protocol (IKE, [IKE]) or its successor 474 IKEv2 [IKEv2] will be used for the purpose of automatic setup of 475 security associations between VPN sites within the same VPN. The CE 476 devices will use the information that they have retrieved (or 477 received) from the SP's VPN server to negotiate SAs with their peers, 478 using IKE(v2). 480 The succesfull establishment of such a 'VPN' IPsec SA between two CEs 481 will result in the auto-configuration of a new VPN tunnel (or virtual 482 link) between the two considered CE devices. 484 As explained in section 5 of this memo, a 'VPN tunnel' is either an 485 IP-in-IP tunnel protected by an IPsec transport mode SA or 486 alternatively a tunnel mode IPsec SA. In both cases, the VPN tunnel 487 is established once the protecting SA is established. 489 These dynamically established SAs can be set-up and maintained 490 independently of the presence of actual inter-site user traffic, 491 resulting in 'permanent' IPsec tunnels. These tunnels are then always 492 available and not traffic-triggered. It is then required to 493 frequently re-negotiate the SA (via IKE(v2)) before the IPsec timers 494 of the connection time out. The set-up of a 'permanent' IPsec tunnel 495 will be triggered by the configuration of a new peer CE device within 496 the same VPN. An advantage of this method is that the IPsec tunnel is 497 always available, and that eventual traffic does not encounter an 498 extra delay due to the setup time of a new SA. The use of 'permanent' 499 IPsec tunnels is recommended for CE-based site-to-site VPNs. 501 A CE device that first joins a VPN must retrieve the initial VPN 502 configuration information from the SP's VPN server. Next, for 503 'permanent' IPsec tunnels, the considered CE SHOULD subsequently 504 establish "VPN tunnel SAs" (using IKE) with every peer CE device 505 listed in the VPN configuration information. 507 o if the IKE negotiation is accepted and authentication succeeds, 508 the SA is successfuly established. 510 o if the IKE negotiation is refused or the authentication fails, 511 the IKE negotiation must be stopped and the SA not be established; 512 the CE device SHOULD then wait for a time interval larger than a 513 certain minimum value (to be configured, depending on e.g. the 514 responsiveness of the auto-discovery mechanism) and then try 515 negotiating the SA with the considered peer again. After a new 516 failure, the CE device SHOULD retry after a certain period of time 517 (t1, to be configured). This process SHOULD continue with 518 exponential backoff of t1 until a certain limit (to be configured) 519 upon which an alarm MUST trigger human interaction. 521 Provider provisioned CE-based IPsec VPNs as described by this 522 document SHOULD use 'permanent' IPsec Security Associations when 523 dynamic routing through IPsec-secured tunnels is used. 525 Alternatively, the IPsec SA setup can be triggered by the effective 526 (data) traffic flow going from one site to another. In this case, the 527 arrival of data packets at the CE device, coming from within the VPN 528 site and going to another VPN site, will be noticed by the CE's IPsec 529 or routing database, and an IKE exchange will be initiated to set up 530 an IPsec secured connection between both parties. Once the secure 531 tunnel is set up, the data packets can flow from one site to the 532 other in a secure way. When no traffic flows for a certain duration 533 of time, the secure tunnel will be torn down again. An advantage of 534 this method is that an IPsec tunnel is only to be maintained when 535 there is effectively traffic flowing. A disadvantage is the extra 536 delay introduced for the traffic during IKE signaling and the 537 difficult interaction with the tunneled inter-site VPN routing 538 information distribution. 540 Provider provisioned CE-based IPsec VPNs as described by this 541 document MAY use traffic-driven IPsec SA establishment when static 542 intra VPN inter-site routing is used (no dynamic routing through the 543 IPsec tunnels), see section 4.3. Provider provisioned CE-based IPsec 544 VPNs as described by this document SHOULD NOT use traffic-driven 545 IPsec SA establishment when dynamic site-to-site routing through the 546 IPsec-secured tunnels is used. 548 The CE configuration determines whether traffic-driven SA 549 establishment is used or not, and whether dynamic routing through 550 IPsec tunnels is used or not. 552 The procedures described in this memo can be used together with 553 [IPSEC-DPD] that offers a mechanism to efficiently keep IPsec SAs 554 alive. 556 Note that IPsec tunnels are unidirectional in nature, but that within 557 the application of this specificiation, the set-up of one direction 558 MUST be accompanied by the set-up of the reverse direction IPsec 559 tunnel. 561 This document describes two possible ways to use IPsec in CE-based 562 VPN scenarios (see section 5): in 'transport mode' or in 'tunnel 563 mode'. The CE configuration, IKE exchange and resulting SA's must 564 specify which mode will be used. 566 Note that the number of peer CE devices with which a specific CE 567 device must have an IPsec connection to secure the data traffic, is 568 dependent on the specific 'role' of the site in the considered VPN. A 569 hub CE will for example have a larger number of tunnels to support 570 than a spoke device. 572 3.5 Updating VPN configuration information 574 An important requirement for the scalability of L3VPNs is the 575 availability of an 'auto-discovery' mechanism. Such an 'auto- 576 discovery' mechanism should for example make sure that the 577 addition/deletion of a VPN site to/from an existing VPN is possible 578 by only configuring the 'new' CE device (and the SP's VPN database): 579 the existing VPN sites should automatically 'discover' the new site 580 in a reliable and secure manner. 582 The precise autodiscovery mechanism and related protocol actions will 583 highly depend on the remote management protocol in use. As such this 584 document does not describe a specific autodiscovery mechanism, and 585 the principles of this document remain interoperable with any 586 autodiscovery mechanism. 588 The remote management protocol can operate in a 'push' model (when a 589 new CE device is added to the VPN, the VPN server pushes the new VPN 590 configuration information to all existing CE devices from that VPN), 591 in a 'pull' model (CE devices periodically download their VPN 592 configuration information from the SP's VPN server, or after 593 receiving tunnel establishment requests from unknown CE devices), or 594 in a combined mode (the SP's VPN server sends a 'notification' to the 595 CE devices that tells them to update their VPN configuration 596 information by downloading it from the VPN server). The different 597 modes and the applied protocol dynamics will have different 598 reliability characteristics. 600 3.6 Removing an existing VPN site 602 When the VPN customer wants to remove an existing site from a certain 603 VPN, this customer first informs the VPN SP. The SP will then update 604 the VPN database on the centralized server. 606 Different approaches can then be used. The SP can provision the 607 considered CE device to delete its VPN information and to tear-down 608 the IPsec SA's using IKE(v2). After completion of the IKE tear-down 609 proces, the peering CE devices must not attempt to re-establish the 610 deleted SA. At this stage, the VPN tunnels are actually removed, and 611 the routing protocols operating through the tunnels in the VPN's 612 routing space will notice the topology change and react 613 appropriately. The periodical retrieval of the VPN configuration 614 information from the VPN database by the other CE devices will then 615 make sure that the removed CE's information is no longer available. 616 The discussed provisioning action can happen in the same way as the 617 pre-provisioning action described in section 3.1, i.e. via manual 618 configuration, via remote management or via interaction with the 619 customer. 621 Alternatively, the SP will not provision the to-be-removed CE 622 individually but the removal of the information relevant to the 623 considered CE from the VPN database will ultimately automatically 624 result in the removal of the CE from the VPN: peer CEs will notice 625 the removal of the particular CE from their updated configuration 626 file and will tear-down the appropriate SA using IKE(v2); the 627 deletion of active SAs will effectively remove the VPN tunnels and 628 the routing protocols running through the VPN tunnels will discover 629 the topology changes and react accordingly. The to-be-removed CE will 630 not be able to retrieve VPN information from the VPN database and 631 will delete all its VPN information and try to tear-down the 632 remaining SAs. 634 4. Exchanging and maintaining VPN routes 636 One of the requirements for PP CE-based VPNs is that dynamic routing 637 is not only supported within individual VPN sites, but also between 638 the different VPN sites of a specific VPN. This means that when a 639 change in the routing information in a specific site occurs, the 640 other sites that belong to the same VPN must be notified of that 641 change. 643 This section deals with the exchange of routing information in the 644 customer VPN's routing space (v). As depicted in figure 4, this 645 exchange of routing information happens over the VPN tunnels and is 646 as such transparant for the SP's network. CE devices MUST NOT leak 647 VPN routes into the SP's network and MUST NOT leak routes from the 648 SP's routing space into the VPN sites, unless explicitly configured 649 to do so (as e.g. explained in section 6 of this document). 651 routing adjacency (VPN space) 652 ______________________________________________________ 653 CE_1 | | CE_2 654 -------|----------------- ---------------|------- 655 | _____V____ === |I| | | |I| === ____V_____ | 656 | |routing/ |=======|P|==|===== VPN tunnel ===|=|P|======|routing/ | | 657 | |forwarding| === |s| | | |s| === |forwarding| | 658 | |VPN space | === |e| |-- PE - core - PE --| |e| === |VPN space | | 659 | ---------- =====|c|==|= | |c| = = ---------- | 660 | IP-in-IP | || | IPinIP | 661 |_________________________| == to CE_3 ----------------------- 663 --- VPN space ---><--------- SP's routing space ------><-- VPN space -- 665 figure 4: tunnelled routing adjacency in the VPN routing space 667 This document assumes that the routing within a VPN site is 668 controlled by the VPN customer, and thus is outside of the scope of 669 this specification. 671 4.1 The CE device and VPN routing 673 On the customer network side, a CE router connects to internal 674 networks of an enterprise, where one or more subnets can reside. Many 675 times, the CE router may interact with another internal router. And 676 sometimes, "backdoor links" between routers of different sites of the 677 same VPN exist. 679 In the VPN routing space (v), the CE is involved in (i) the intra- 680 site routing, (ii) the VPN tunnel termination, and (iii) the inter- 681 site VPN routing. 683 The CE device could be an integrated device providing both routing 684 and IPsec tunnel termination. Sometimes, a dedicated VPN terminator 685 may be used. Implementations in which the VPN tunnel terminator 686 resides on a firewall are also very common. For the sake of 687 simplicity, we assume that the CE router is an integrated device that 688 participates in the intra-site routing (e.g. via an IGP) and at the 689 same time terminates VPN tunnels. 691 In the context of this document, the routing aspects within a VPN 692 site (intra-site routing information distribution) are controlled by 693 the VPN customer. 695 As was explained earlier, the SP's dynamic VPN discovery scheme and 696 tunnel establishment mechanism provides the CE device with secure 697 (virtual) links towards other CE devices in the same VPN. Whether the 698 intra-VPN inter-site routing aspects that make use of these virtual 699 links are managed by the customer or by the SP is dependent on the 700 service contract. In many situations, the SP will configure the 701 necessary routing protocol information at pre-configuration time (see 702 section 3.1), in close colaboration with the customer. 704 An important requirement for the routing protocol implementation that 705 is configured to exchange reachability information through the 706 inter-site tunnels, is that it must be able to autonomously deal with 707 dynamically created new inter-site links. 709 4.2 IPsec and routing 711 IPsec is a layer 3 security protocol, which operates purely at the IP 712 layer. The IETF IPsec Working Group currently specifies the revisions 713 of the IPsec standards ([IPSEC], [RFC2402], [RFC2406], [RFC2407], 714 [RFC2408], and [IKE]). The interaction between IPsec and layer 3 715 routing was often troublesome and has been described in [TOUCH], 716 [KNIGHT] and [DUFFY]. Depending on individual implementations, 717 difficulty may arise when an IPsec user wants to support robust 718 routing across IPsec-interconnected VPNs sites. 720 Details regarding the problems of the interaction between VPN routing 721 and VPN tunneling, and some proposed solutions to counter these 722 issues, can be found in [TOUCH], [DUFFY] and [KNIGHT]. 724 4.3 Exchanging VPN routes between VPN sites 726 In the proposed mechanism to exchange VPN reachability information 727 between VPN sites, routing protocol messages are tunneled through the 728 IPsec-secured tunnels between peering sites. The CE-to-CE IPsec- 729 secured tunnels between VPN sites are then being seen as point-to- 730 point links by the customer networks and are interpreted as such by 731 the routing protocol functions of the CE devices. This means that 732 when a change in the reachability occurs in one particular site, a 733 routing protocol (such as RIP, OSPF, etc.) will take care of the 734 distribution of the new reachability information within the site, but 735 also to all other sites, through the VPN tunnels that the considered 736 CE is possibly maintaining. 738 As the described architecture allows for the dynamic creation of 739 inter-site (IPsec-protected) VPN links, the routing protocol 740 implementation(s) operating on the CE device MUST be able to support 741 this. 743 Although very often it will be the SP's responsibility to configure 744 the CE's routing information at pre-configuration time, the service 745 aggreement MAY specify that routing on the CE device falls under the 746 customer's management. 748 When routing protocol messages are tunneled through the IPsec-secured 749 tunnels ('dynamic routing through IPsec-secured tunnels') as per this 750 section, IPsec transport mode secured IP-in-IP tunnels as per [TOUCH] 751 SHOULD be used (in contrast to IPsec tunnel mode tunnels). 753 Note that other approaches may use a combination of dynamic routing 754 and IPsec tunnel mode tunnels, though it is not clear how 755 interoperability will then be assured. 757 Another issue to consider is the fact that using a traffic-driven 758 tunnel establishment mechanism and at the same time using an approach 759 whereby a routing protocol (with a keep-alive mechanism) runs on top 760 of the VPN tunnel, does not seem currently applicable: the delay 761 introduced by the tunnel establishment phase could lead to a loss of 762 routing updates and the routing protocol's keep-alive mechanism could 763 interact with the tunnel establishment in an undesired way. 764 Therefore, when dynamic routing is used through IPsec-secured CE-to- 765 CE tunnels, traffic-driven SA establishment SHOULD NOT be used. 767 5. Tunneling IP traffic (user data) among VPN sites 769 This section describes the processes that an IP packet that is sent 770 from one VPN site to another will go through. This is dependent on 771 the way that IPsec is used. This document describes two possible ways 772 to use IPsec in CE-based VPN implementations: IPsec in tunnel mode, 773 and IPsec in transport mode. 775 An IP packet that is sent by an IP device in a certain site and 776 destined for an IP device in another site belonging to the same VPN, 777 will be forwarded as follows. 779 The device in the sending site sends an IP packet (possibly using a 780 private address space) on its LAN network. The next hop for this 781 destination IP address will (at some point in time) be the site's CE 782 device (according to the routing/forwarding in the VPN site). The 783 processing by the CE device now is dependent on the implemented mode 784 for IPsec. 786 The use of IPsec in tunnel mode has the advantage that the complete 787 range of SPD-checks remain usuable, but has the disadvantage that 788 dynamic routing through the tunnels is not supported. The use of 789 IPsec in transport mode secured IP-in-IP tunnels has the advantage 790 that dynamic routing through the tunnels is fully supported, but has 791 the disadvantage that the complete range of SPD-checks is not 792 supported. 794 Note that the following description is not meant to specify an 795 implementation strategy; any implementation procedure wich produces 796 the same results is acceptable. 798 o IPsec in transport mode (see also [TOUCH] for a detailed 799 specification) 801 When IPsec is used in transport mode in this context, the CE 802 device must first analyze the private IP packets arriving from 803 within the site and select the appropriate outgoing interface and 804 required encapsulation, based on the VPN routing/forwarding 805 information. For a destination located in an other site, the 806 outgoing interface will be a virtual interface (a VPN tunnel) and 807 the required encapsulation will be IP-in-IP, using the considered 808 CE's IP address (s) as the source address in the outer IP 809 encapsulation header and a peer CE's IP address (s) in the outer 810 IP encapsulation header's destination address field. The CE device 811 then processes this new IP packet to its IPsec driver. 813 The IPsec driver in the CE device must then do the following: 815 - analyze the IP packets that have been IP-in-IP encapsulated and 816 select the appropriate SA (based on the packet's outer header 817 destination address (s)). 819 - authenticate and/or encrypt the private IP packet according to 820 the (transport mode-specific) rules described in the SA and insert 821 an appropriate IPsec header (according to IPsec in transport 822 mode). 824 o IPsec in tunnel mode 826 When IPsec is used in tunnel mode in this context, the IPsec 827 driver in the CE device must do the following: 829 - analyze the private IP packets arriving from within the site and 830 select/setup an appropriate SA with the appropriate destination CE 831 device. 833 - authenticate and/or encrypt the private IP packet according to 834 the (tunnel mode-specific) rules described in the SA, AND 835 encapsulate the packet in an IPsec header AND encapsulate the 836 packet in a new 'outer' IP header. This 'outer' IP header has the 837 CE's non-private (i.e. routable in the SP's realm) IP address in 838 the source IP address field and the destination CE's non-private 839 (i.e. routable in the SP's realm) IP address in the destination IP 840 address field. 842 The CE device then sends the IPsec packet to the PE device, and the 843 IPsec packet will then be forwarded using 'normal' IP forwarding 844 across the SP's network, based on the outer header's IP destination 845 address (s), that is the destination CE's 'global' (i.e. routable in 846 the SP's realm) IP address. The packet will be forwarded to the 847 egress PE who will also only examine the outer IP header and send the 848 IP(sec) packet to the destined CE device. The egress CE device will 849 recognize itself as the destination node (the IP packet has the CE's 850 IP address (s) in the outer IP destination address field) and process 851 the IPsec packet to the IPsec driver that will then, based on the 852 appropriate Security Association (identified by the packet's SPI 853 field in the IPsec header), perform IPsec authentication and/or 854 decryption. Dependent on whether tunnel mode or transport mode IPsec 855 is used, the packet will be decapsulated by the IPsec driver itself 856 or sent to the IP-in-IP decapsulation function. The resulting 857 (private) IP packet (v) will then be further processed in the CE's 858 VPN IP forwarding table and send on the LAN network to the 859 appropriate next hop router or destination IP device. 861 Note that IPsec tunnels might unintentionally terminate or break. 862 When dynamic routing is not supported through the inter-site VPN 863 tunnels, this may have serious consequences if VPN membership and VPN 864 routing information are not changed accordingly within the VPN. 865 Indeed, the unnoticed termination of a VPN tunnel can result in the 866 creation of black holes. 868 This means that a mechanism must exist to monitor the state of the 869 VPN tunnels. When dynamic inter-site VPN routing is used, the routing 870 protocol that runs on top of the IPsec VPN tunnels will serve that 871 purpose. When dynamic inter-site routing is not used, the following 872 alternatives are possible: (i) the use of an IPsec-specific keep- 873 alive mechanism [IPSEC-DPD] and (ii) a SP-proprietary mechanism. 875 6. CE-based VPN and Internet 877 6.1 Allowing both VPN connectivity and Internet connectivity 879 In many VPNs, sites will need to both access the public Internet as 880 well as to access other sites within the same VPN. 882 In order to achieve this, some sites within the VPN will obtain 883 Internet Access by means of an "Internet Gateway" that is attached 884 via one of its interfaces to an ISP's PE device. Such an Internet 885 Gateway may for example be a firewall and may need to implement 886 network address translation functions. The ISP may be the same SP 887 that offers the VPN service, or it may be a different SP. The PE to 888 which the Internet Gateway is connected may be the same PE to which 889 the CE is connected or it may be an other PE. 891 The Internet Gateway may be a separate device, or alternatively the 892 Internet Gateway functions may be integrated into the CE device. When 893 the Internet Gateway functions are integrated into the CE device, the 894 CE-PE interface used by the Internet Gateway functions may be the 895 same or a different interface than the interface used by the VPN 896 tunnels. In further discussions, we'll assume that the Internet 897 Gateway is a separate device. 899 The service contract will define whether the Internet Gateway will be 900 managed by the SP or by the VPN customer. 902 Note that when Internet Access is offered within a VPN, the address 903 spaces used within the VPN must be non-overlapping. This means that 904 the VPN SHOULD either use global addresses that have been assigned to 905 the VPN customer, or private addressing in combination with NAT 906 [NAT]. 908 The sites that have Internet Access via an Internet Gateway will have 909 a default route (v) pointing to their Internet Gateway and may be 910 distributing a default route via their CE towards the other CEs of 911 the same VPN through the VPN tunnels. This provides Internet Access 912 for all the VPN sites. Note that other sites (that don't have their 913 own Internet Gateway) must not distribute default routes in this 914 scenario. A site that has distributed a default route to other sites 915 for Internet Access should have either a default route to its 916 Internet Gateway or Internet routes (leading to its Internet Gateway) 917 in its forwarding table (of the VPN routing space). 919 VPN site <---- : 920 : 921 ---------- to Internet : 922 _____| Internet |----------------:-- PE_2 923 | | Gateway | : 924 | ---------- : 925 --------|--------------------------- : 926 | default | : 927 | route to | : 928 | _____|______ | : 929 | | | ===== CE2 |I| | : 930 ----|--|routing and | ===== CE3 |P| | : 931 | |forwarding | ===== CE4 |s| -->|-----:-- PE_1 932 ----|--|in VPN space| ===== CE5 |e| | : 933 | ------------ = = = |c| | : 934 | IP-in-IP | : 935 |______CE device_____________________| : 936 <--- : 937 intra : 938 site : 939 : 940 figure 5: Internet Access from within a VPN 942 The Internet Gateway will process (e.g. firewall + NAT) all traffic 943 coming from within the VPN and, if accepted, send it to the PE with 944 which it interfaces. As such the Internet Gateway effectively is the 945 device that interfaces between the VPN routing space and the 946 SP's/Internet routing space. Note that traffic that leaves a VPN via 947 an Internet Gateway will not be IP-in-IP encapsulated and will not be 948 IPsec processed. The traffic coming from the gateway will then be 949 forwarded according to the PE's (default/Internet) forwarding table. 951 In order to allow for traffic in the reverse direction (from the 952 Internet to the VPN sites), the ISP connected to the Internet Gateway 953 must distribute, to the Internet, routes that lead to addresses that 954 are within the VPN. NAT-like techniques may also be used. As such 955 there will be routes that will lead from the Internet to the site's 956 Internet Gateway. The Internet Gateway will process traffic coming 957 from the Internet and, if accepted, send it into the VPN site where 958 intra-VPN routing and forwarding will lead the packets to their 959 destination. This distribution of routes that lead to addresses 960 within the VPN towards the Internet is independent of any intra-VPN 961 route distribution as described elsewhere within this specification. 962 Note also that normally the internal structure of the VPN will remain 963 invisible to the outside world. 965 When the Internet Gateway functions are implemented in the CE device 966 and the CE device is attached via only one (sub-)interface towards 967 only one PE device, inspection of the packets coming from the PE will 968 indicate whether the concerned traffic is intra-VPN traffic (when the 969 packet is an IPsec packet with the CE device's own IP address (s) in 970 the outer header's destination address field and the encapsulated 971 payload is an IP-in-IP encapsulated private IP packet (v), and a 972 matching SA is found), or control-plane traffic (IKE(v2) or VPN 973 remote management traffic: when the inspected packets conform to the 974 control plane's policies), or VPN <--> Internet traffic (then the 975 Internet Gateway function will decide whether the considered packets 976 will be accepted, (translated), and forwarded or not). 978 In the above discussed procedures, some sites will access the 979 Internet via a VPN tunnel that leads to another site of the same VPN, 980 because they don't have an own Internet Gateway, and will forward the 981 traffic according to the default route. Ultimately though, Internet 982 traffic will always go via an Internet Gateway before 983 entering/leaving a VPN. 985 Further note that the PE to which the Internet Gateway is attached 986 doesn't necessarily need to carry all the Internet routes; a default 987 route to an other Internet router suffices. 989 6.2 Prohibiting or restricting Internet connectivity from within a CE- 990 based VPN 992 In the approach described in this document, the CE device sends IP 993 packets (s) to the VPN-unaware PE device and receives IP packets from 994 that PE device. The PE device forwards these packets based on the IP 995 addresses (s) in the (outer) IP header. The packets received by the 996 PE are as such either packets that are routable within the SP's 997 private scope, or either in the public Internet's scope. This section 998 discusses the implications hereof with regards to security and access 999 control. 1001 o traffic that the CE sends to the PE 1003 Following the procedures described in this document, three types 1004 of 'VPN' traffic can be sent by the CE device towards the PE 1005 device: 1007 (i) customer VPN traffic: intra-VPN traffic sent from one VPN site 1008 to an other VPN site; these packets will always have the sending 1009 CE's IP address (s) in the IP header's source IP address field, 1010 the IP address (s) of a peer CE device of the same VPN in the IP 1011 header's destination IP address field, and will always contain an 1012 IPsec header; 1014 (ii) secure remote management traffic: this comprises both the 1015 traffic to establish the secure management channel (e.g. IPsec or 1016 secure TLS) and the traffic to download the VPN configuration 1017 file; these packets will always have the CE's IP address (s) in 1018 the IP header's source IP address field; 1020 (iii) IKE(v2) traffic: the IP packets sent between CE devices in 1021 order to establish SAs; these packets will always have the CE's IP 1022 address (s) in the IP header's source IP address field. 1024 o traffic that the CE receives from the PE 1026 Following the procedures described in this document, the same 1027 three types of traffic can be received by the CE device from the 1028 PE device. As such, the CE device should perform the following 1029 actions: 1031 + for IP packets that have the CE's own IP address (s) in the 1032 outer IP header's destination address field and that have an IPsec 1033 header: process the packets through the CE router's IPsec deamon 1034 where conformance with an existing SA will be checked, and the 1035 packets further processed; 1037 + for IKE(v2) packets that have the CE's own IP address (s) in the 1038 outer IP header's destination address field: process according to 1039 the tunnel establishment procedures described in this 1040 specification; 1042 + for IP packets that have the CE's own IP address (s) in the 1043 outer IP header's destination address field and that correspond to 1044 secured management traffic: process according to the VPN secure 1045 remote management procedures, which will depend on the used 1046 management protocols; 1048 + for CE devices that have an integrated Internet Gateway role: 1049 process all other packets to the Internet Gateway module; 1051 + for CE devices that don't have an integrated Internet Gateway 1052 role: drop all other IP packets, unless explicitly allowed by 1053 complementary procedures that are out of scope of this memo. 1055 o SP's control over CE initiated traffic 1057 Note that with this specification's concepts, the PE device that 1058 receives traffic from a CE device has no means to verify whether 1059 the received traffic is intra-VPN traffic, or traffic that is sent 1060 to for example an other VPN or e.g. to the Internet. 1062 From a VPN data privacy point of view, this has no implications, 1063 as the security is enforced at the CE devices themselves: traffic 1064 that doesn't conform to the security associations or other policy 1065 rules will be dropped at the CE. 1067 One remaining issue is that customers might use CE devices (that 1068 have been granted VPN access) to access services they have not 1069 been granted access for, via the PE device. Although this would 1070 possibly compromise the security of the customer's own VPN, the SP 1071 may want to deploy measures to prevent this without bringing full 1072 VPN knowledge to the PE. One way of doing this would be by using 1073 specific IP address ranges for VPN purposes and to have specific 1074 access lists configured on the PE devices (this has inter-SP and 1075 Internet transparency issues though). Note that maintaining, at 1076 every PE, a list of would add a 1077 considerable management burden and is as such not advised. Another 1078 strategy for the SP would be not to care about the particularities 1079 of the traffic and treat it as it treats public Internet traffic 1080 (and as such to only control the total of the resources consumed 1081 by particular access connections). 1083 Taking into consideration that in many cases, VPNs will also need 1084 to be able to access the public Internet, and that the above 1085 problem does not seem to be an important thread for the SP nor the 1086 VPN customer, this issue is not considered as a major drawback for 1087 the deployment of the discussed VPN approach. 1089 7. Security Considerations 1091 The security aspects of what is presented in this document are 1092 implicitly discussed in most of the sections. This draft is for a 1093 large part focussing on security aspects. 1095 Note that the security of the mechanisms presented here is highly 1096 dependent on the following factors: 1098 - the security of the 'management channel', used by the management 1099 protocol to configure the VPN CE devices. 1101 - the security of the site and of the CE-device itself 1103 - the security aspects of the credentials: the IPsec credential 1104 must be generated, provisioned, updated, and stored securely 1106 - for a VPN with a complex topology, every tunnel must use the 1107 same grade of security strength, otherwise, a single weak link 1108 degrades the whole VPN 1110 8. Acknowledgements 1112 The authors would like to thank the following persons for their 1113 valuable contributions to this document: Lars Eggert, Brian Gleeson, 1114 Archana Khetan, Sankar Ramamoorthi, Eric Rosen, Michael Choung Shieh, 1115 Joe Touch, Eric Vyncke, S. Felix Wu, Yu-Shun Wang, Cliff Wang, Alex 1116 Zinin. 1118 9. References 1120 [DUFFY] Duffy, M., "Framework for IPsec Protected Virtual Links for 1121 PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00.txt, October 2002, Work in 1122 Progress 1124 [FRAMEWORK] Callon, R. et al., "A Framework for Provider Provisioned 1125 Virtual Private Networks", draft-ietf-ppvpn-framework-0x.txt, Work in 1126 progress 1128 [GRE] Farinacci, D. et al., "Generic Route Encapsulation", March 1129 2000, RFC 2784 1131 [GRE-CE] Khetan, A., et al., "Use of GRE for routing support in IPsec 1132 VPNs", draft-khetan-sp-greipsec, Work in progress 1134 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", 1135 November 1998, RFC 2409 1137 [IPinIP] Perkins, C., "IP encapsulation within IP", October 1996, RFC 1138 2003 1140 [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the 1141 Internet Protocol", November 1998, RFC 2401 1143 [IPSEC-DPD] Huang, G., Beaulieu, S., Rochefort, D., "A Traffic-Based 1144 Method of Detecting Dead IKE Peers", draft-ietf-ipsec-dpd-0x.txt, 1145 Work in progress 1147 [KNIGHT] Knight, P., Gleeson, B., "A Method to Signal and Provide 1148 Dynamic Routing in IPsec VPNs", draft-knight-ppvpn-ipsec-dynroute, 1149 Work in progress 1151 [LEE-DHCP] Lee, C.Y., "Customer Equipment Auto-configuration", March 1152 2002, work in progress 1154 [L2TP] Lau, J., et al., "Layer Two Tunneling Protocol (Version 3)", 1155 draft-ietf-l2tpext-l2tp-base-0x.txt, Work in progress 1157 [NAT] Srisuresh, P., Egevang, K., "Traditional IP Network Address 1158 Translator (Traditional NAT)", January 2001, RFC 3022 1160 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", 1161 November 1998, RFC 2402 1163 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 1164 (ESP)", November 1998, RFC 2406 1166 [RFC2407] Piper, D., "The Internet IP Security Domain of 1167 Interpretation for ISAKMP" November 1998, RFC 2407 1169 [RFC2408] Maughan, D., et al., "Internet Security Association and Key 1170 Management Protocol (ISAKMP)", November 1998, RFC 2408 1172 [TOUCH] Touch, J. and Eggert, L., "Use of IPSEC transport mode for 1173 Virtual Networks", draft-touch-ipsec-vpn-0x.txt, Work in progress 1175 10. Authors' Addresses 1177 Jeremy De Clercq 1178 Alcatel 1179 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 1180 E-mail: jeremy.de_clercq@alcatel.be 1182 Olivier Paridaens 1183 Alcatel 1184 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 1185 E-mail: olivier.paridaens@alcatel.be 1187 Cliff Wang 1188 E-mail: cliff.wang@us.army.mil