idnits 2.17.1 draft-ietf-l3vpn-ce-based-01.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 226: '...s. The CE device MUST be reachable fro...' RFC 2119 keyword, line 265: '...ng the CE device MUST always be the CE...' RFC 2119 keyword, line 317: '... same VPN MAY be interconnected via ...' RFC 2119 keyword, line 435: '... devices SHOULD support both modes o...' RFC 2119 keyword, line 504: '... the considered CE SHOULD subsequently...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 138 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 (October 2003) is 7493 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 475, but not defined == Unused Reference: 'LEE-DHCP' is defined on line 1156, 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 October 2003 9 Expires April, 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. Quality of Service .......................................... 24 70 8. Security Considerations ..................................... 24 71 9. Acknowledgements ............................................ 25 72 10. References .................................................. 25 73 11. Authors' Addresses .......................................... 26 75 1. Introduction 77 The L3VPN framework document [FRAMEWORK] identifies three basic 78 provider provisioned VPN types : Provider Provisioned Network Based 79 (also termed PE-based) Layer 3 VPNs, Provider Provisioned Layer 2 80 VPNs and Provider Provisioned CE-based VPNs. 82 This document describes a method enabling a Service Provider to offer 83 IP VPN services to its customers by provisioning the CE devices on 84 behalf of the customer (Provider Provisioned CE-based VPNs). This 85 document describes which parameters need to be provisioned, but not 86 which protocol to use for the provisioning. 88 For a CE-based VPN to be set up under the SP's control, the VPN 89 customer informs the Service Provider of which sites (identified by a 90 set of CE devices) should become part of the considered VPN and what 91 the requested topology of the VPN should look like. The SP then 92 configures and updates its VPN database, and then provisions and 93 manages the Customer's VPN. 95 The model proposed in this document uses the IPsec protocol suite for 96 the purpose of securely tunneling the customer VPN traffic and the 97 inter-site reachability information distribution. 99 2. Reference Model 101 The reference model upon which the mechanisms and procedures 102 described in this document are based, is taken from the CE-based VPN 103 reference model described in [FRAMEWORK]. The most important aspects 104 of that framework model and the restrictions that are relevant to 105 this document are described in this section. 107 +---------+ +------------------------------------+ +---------+ 108 | | | | | | 109 | | | +------+ +------+ : +------+ 110 +------+ : | | | | | | : | CE | 111 | CE | : | | | P | | PE | : |device| 112 |device| : +------+ VPN tunnel |router| |router| : | of | 113 | of |=:====================================================:=|VPN A| 114 |VPN A| : | | +------+ +------+ : +------+ 115 +------+ : | PE | | | : | 116 +------+ : |router| | | : | 117 | CE | : | | VPN tunnel +------+ : +------+ 118 |device|=:====================================================:=| CE | 119 | of | : +------+ | PE | : |device| 120 |VPN B| : | | |router| : | of | 121 +------+ : | | +------------+ +------------+ | | : |VPN B| 122 | : | | | Customer | | Network | +------+ : +------+ 123 |Customer | | | management | | management | | | : | 124 |interface| | | function | | function | | |Customer | 125 | | | +------------+ +------------+ | |interface| 126 | | | | | | 127 +---------+ +------------------------------------+ +---------+ 128 | Access | |<---------- SP network(s) --------->| | Access | 129 | network | | | | network | 131 Figure 1: Reference model for provider provisioned CE-based VPNs 133 2.1 Entities in the reference model and Terminology 135 o Customer Edge (CE) device 137 In the context of this solution, a CE device is a router located 138 at the edge of a customer site, that has IP connectivity with a 139 SP's PE device (not necessarily Internet connectivity). A CE 140 device maintains one or more VPN tunnel endpoints. The VPN- 141 specific functions in the CE device are provisioned by the SP. 143 Note that other functions that are normally applied by the PE 144 router may need to be performed by the CE device in this context 145 (e.g. NAT functionality, QoS classification, etc.). These 146 functions may be managed by the SP or alternatively be managed by 147 the VPN customer, depending on the applicable service contract. 149 The CE device may also provide general (non VPN-oriented) Internet 150 connectivity for the customer network. Such connectivity may be 151 achieved via the SP's PE router that provides the VPN connectivity 152 or some other router (of the same or another SP). In such a 153 situation, the CE device must be able to distinguish between 154 traffic to be sent through a VPN and traffic to be sent outside 155 any VPN. Section 6 of this document discusses this in more 156 details. 158 CE devices in a CE-based VPN model differ from CE devices in a 159 PE-based VPN model in that they need to support VPN-specific 160 functions. With CE-based PPVPNs, the VPN awareness is pushed even 161 further towards the edges of the provider networks. 163 o Provider Edge (PE) router 165 In the context of Provider Provisioned CE-based VPNs, a PE router 166 is a router, located at the edge of the Service Provider's 167 network, that does not have any VPN-specific functionality. A PE 168 router is attached via an access connection to one or more CE 169 devices, and offers possibly limited or restricted IP 170 connectivity over the access connections to these CE devices. 172 o SP network 174 A SP network is a network administrated by a single service 175 provider. In the context of PP CE-based VPNs, the SP who owns the 176 SP network can also be the VPN provider (managing the CE devices). 177 This can lead to operational advantages (e.g. for offering QoS). 178 Alternatively, the SP owning the SP network may be an ISP offering 179 Internet connectivity, while an other entity may provision the VPN 180 service. This configuration allows for inter-SP and Internet-wide 181 VPN scenarios. 183 o Access connection 185 An access connection represents a layer 2 connectivity between a 186 CE device and a PE router. This includes dedicated physical 187 circuits, logical circuits (such as Frame Relay and ATM), IP 188 tunnels (e.g., using IPsec, L2TP) and shared medium access (such 189 as Ethernet-based access). In the context of provider provisioned 190 CE-based VPNs, the CE device and the PE router have layer 3 191 connectivity over the Access Connection. 193 o VPN tunnel 195 A VPN tunnel is a logical link between two entities which is 196 created by encapsulating packets within an encapsulating header 197 for purpose of transmission between those two entities for support 198 of VPNs. In the context of provider provisioned CE-based VPNs, a 199 VPN tunnel is an IP tunnel (e.g., using IPsec [IPSEC], L2TP 200 [L2TP], GRE [GRE], IP-in-IP [IPinIP]) between two CE devices over 201 the SP's network. In the context of this document, a VPN tunnel is 202 achieved using IPsec in tunnel mode or via an IP-in-IP tunnel 203 protected by IPsec in transport mode between two CE devices. 204 [GRE-CE] describes how to use GRE encapsulation for CE to CE 205 tunneling in a CE-based IPsec VPN scenario. 207 o Security Association (SA) 209 Throughout this document, the acronym SA will be used to denote an 210 IPsec Security Association. 212 2.2 IP connectivity between CE and PE devices 214 CE devices operating in a PP CE-based VPN will operate in two 215 independent IP routing spaces. 217 The first routing space is the VPN routing space. Hosts and routers 218 within the VPN will use IP addresses that belong to this VPN routing 219 space. The CE router will participate in this VPN routing space, and 220 will create VPN tunnels (virtual links) to be used as virtual 221 interfaces by this VPN routing space. 223 The second routing space is the SP's routing space. Every CE device 224 that belongs to a PP CE-based VPN is identified by an IP address that 225 is routable in the SP's network. This IP address may be a global IP 226 address or a private IP address. The CE device MUST be reachable from 227 the SP's core network via this IP address. 229 In order to easily differentiate between these two routing spaces, 230 this document uses the following convention: IP addresses belonging 231 to the VPN's routing realm will be followed by a 'v' between 232 brackets: address (v); IP addresses belonging to the service 233 provider's routable space will be followed by a 's' between brackets: 234 address (s). 236 These two routing spaces may use overlapping address spaces and thus 237 need to be kept separate in the CE devices. The way this is done is 238 largely implementation dependent. This may be by using two separate 239 sets of (virtual) routing and forwarding tables (figure 2). These 240 routing tables may then run independent routing protocols. 242 Only the CE's IP address (s) needs to be reachable in the provider's 243 core network. This means that this approach requires only one IP 244 address (s) per CE device to be injected in the core network. A CE 245 device should not inject other routes into the SP's network (one 246 exception is for Internet Access scenarios, that are discussed in 247 section 6). In many cases, this CE's IP address (s) may be an IP 248 address assigned by the SP who owns the core network. As such, 249 aggregate routes can be distributed by the PE devices into the core 250 network. 252 The CE device and the PE device may be routing protocol peers in the 253 SP's routing space. Alternatively, a default route (s) (towards the 254 PE) may be statically configured in the SP's routing space on the CE 255 device, and the CE device's IP address (s) statically configured on 256 the PE. The CE device should not inject SP's routes (s) towards the 257 other routers within its VPN site (except in the context of the 258 Internet Access scenarios described in section 6). 260 Note that, when the CE device is attached to only one PE device, via 261 only one (sub-)interface, the CE's implementation can be fairly 262 straightforward (see figure 3). With regards to the SP routing space, 263 the CE device then acts as a host, having only one outgoing 264 interface. The source IP address (s) (of the _outer_ IP header) of 265 all packets leaving the CE device MUST always be the CE's identifier, 266 and the IP next hop will always be the PE device to which it is 267 attached. On the CE, no routing decisions need to be performed in the 268 provider's routing space and only one forwarding action is possible. 270 The following figures give an overview of the routing spaces in the 271 CE device. Note that this description is merely an example and is not 272 meant to specify a particular implementation: every implementation 273 that results in the same behaviour described throughout this 274 specification is acceptable. 276 Section 5 describes the end-to-end processing of customer data- 277 packets in more details. 279 CE device 280 ---------------------------------------------------------- 281 | ____________ ======== |I| ______________ __|__ PE_1 282 | |routing and | ======== |P| |routing and | / | 283 | |forwarding | ======== |s| |forwaring in |< | 284 | |in VPN space| ======== |e| --- |provider space| |__|__ PE_2 285 | | IP(v) | ======== |c| | IP(s) | | 286 | ------------ = = = = | | -------------- | 287 | IP(v)-in-IP(s) | 288 |__________________________________________________________| 290 <- - - - - - - - - - - - -><- - - - - - - - - - - - - - - - - - - - > 291 VPN space SP space 292 figure (2): routing spaces in the CE device 293 (''VPN space'' = customer ''private'' space) 295 ---------------------------------------------- 296 | ____________ ========== to CE_2 |I| | 297 | |routing and | ========== to CE_3 |P| | 298 | |forwarding | ========== to CE_4 |s|----|--- PE 299 | |in VPN space| ========== to CE_5 |e| | 300 | | IP(v) | ========== to CE_6 |c| | 301 | ------------ = = = = = | | | 302 | IP(v)-in-IP(s) | 303 |______________________________________________| 305 <- - - - - - - - - - - - ><- - - - - - - - - - - - - - - -> 306 VPN space SP space 307 figure (3): the CE is connected to only one PE device 309 Note that there are no routing protocols operating in both routing 310 spaces simultaneously. Packets can only go from one routing space to 311 the other routing space via either (IP-in-IP) tunneling or after 312 firewall and possibly NAT processing (as described in section 6). 314 This approach enables the CE devices to reach each other via tunnels 315 over the SP's network, but does not prevent the interconnection of CE 316 devices via so-called "backdoor routes". CE devices belonging to the 317 same VPN MAY be interconnected via "backdoor routes". If "backdoor 318 routes" are present in a certain VPN, the VPN's routing protocol 319 metrics will dictate which routes will be used as the prefered routes 320 for certain destinations. 322 2.3 Assumed Service Provider's infrastructure 324 The service provider maintains a secured VPN database (e.g. on a 325 centralized server). One such VPN database may be used for the 326 provisioning of many VPNs. As the number of VPNs to be provisioned 327 grows, other servers may be deployed. As such, the scalability of no 328 single device is dependent on the total number of VPNs. 330 In order to provide a reliable service, the SP may choose to deploy 331 backup VPN database servers that it keeps synchronized with the 332 primary server. 334 The Service Provider's VPN management infrastructure needs to have a 335 secure provisioning channel to every attached CE device. This secure 336 provisioning channel will be used to exchange VPN-specific 337 configuration information between the SP's VPN database and the CE 338 devices. 340 Note that this document does not prescribe one particular protocol 341 for this provisioning channel. Some examples are: SOAP/XML/HTTP/TLS, 342 CLI/Telnet/SSH, an IPsec-protected remote configuration protocol, 343 etc. 345 As the SP will be responsible for provisioning the secure tunnels 346 between the CE devices, it needs to deploy a key management system. 348 3. Configuring the CE-based VPN 350 As was noted before, this specification does not describe the 351 protocol to use as a remote management protocol to provision CE 352 devices. It does however describe with which information CE devices 353 need to be pre-provisioned, and which parameters need to be 354 configurable via this management protocol by the Service Provider. 356 3.1 Initializing the VPN database 358 As a first step in the VPN configuration process, the Service 359 Provider configures its VPN database with a new VPN entry and with 360 the IP addresses (s) of the CE devices belonging to the VPN, and with 361 a description of the VPN's topology. 363 For every CE device, the following information must be configured and 364 maintained in the VPN database: 366 - the security information that is necessary for the secure remote 367 management protocol. This information should allow for mutual 368 authentication between CE and SP's VPN server, and for encryption 369 of the management data. The detials of this information will 370 depend on the particular protocol (stack) used for remote 371 management 373 - the security information that is necessary for the CE device to 374 establish and maintain Security Associations with its peer CE 375 devices belonging to the same VPN; section 3.3 defines which is 376 the minimal set of information a CE device should be able to 377 retrieve/receive fromt the SP's VPN management server. 379 3.2 Pre-configuration of the CE device 381 This document uses the term "pre-configuration" for the initial 382 provisioning of a CE device. This pre-configuration happens before a 383 CE is attached to a VPN (before the considered site actively belongs 384 to the VPN). This pre-configuration can be performed by the SP before 385 shipping the CE device to the customer's premises. Alternatively, the 386 SP can pre-provision the CE device manually at the customer's 387 premises. Another possibility is for the SP to tell the customer how 388 to pre-provision its CE device. Finally other scenarios such as 389 remote management with for example secured SNMP are also possible. 391 Every CE device participating in a VPN needs to be pre-provisioned 392 with the necessary configuration information that enables it to 393 establish a secure communication path with the SP's VPN server. 395 The CE device must be configured with the IP address (s) of the 396 Service Provider's VPN server or with a URL to the required CE's 397 VPN information on the Service Provider's VPN database. 399 The CE device must be configured with the security information 400 required by the SP's secure remote management protocol (stack). 402 And finally, the CE device must be ''pre-configured'' with the CE's 403 IP address (s) in the SP's space. 405 As mentioned before, the CE device is identified by an IP address (s) 406 that belongs to the Service Provider's routing space. This IP address 407 (s) may be an IP address assigned by the SP and manually configured 408 on the CE device, together with the other (pre-) configuration 409 information (this would require this IP address (s) to be configured 410 as a static route on the attached PE too). Alternatively, the CE may 411 dynamically obtain this IP address (s), using for example DHCP or 412 IPCP over the CE-PE link. Yet another possibility is that the CE 413 device has obtained a (global) IP address (s) from an ISP, and that 414 the VPN customer communicates this IP address (s) to the VPN Service 415 Provider. Note that the CE device needs to maintain this same IP 416 address (s) at least for the duration of its VPN membership. 418 Note that other information, such as timer-parameters etc. may be 419 configurable by the SP. These parameters can be provisioned by the SP 420 at pre-configuration time. 422 3.3 Fetching the VPN configuration information 424 The VPN service is initialized by the CE device by retrieving the VPN 425 configuration information from the SP's VPN database using the 426 appropriate secure remote configuration channel. 428 The CE device will retrieve from the SP's VPN server the information 429 that is necessary to establish IPsec-secured tunnels with the other 430 CE devices that belong to the same VPN (and to which it should 431 establish a virtual VPN link - dependend on the VPN topology). The SP 432 may choose to let the CE devices authenticate the IKE negotiations 433 between CE devices using (i) pre-shared keys or (ii) digital 434 signatures and certificates. The IPsec implementation on the CE 435 devices SHOULD support both modes of authentication. 437 (i) in case of pre-shared keys, the following information is to be 438 retrieved from the SP's VPN server: 440 - a list of tuplets 443 (SA information = the necessary information to negotiate a SA 444 with the peer CE: security protocol, Diffie-Hellman group, 445 IPsec transforms, etc. The (optional) presence of this 446 information will overwrite possible default values in the CE) 448 (tunnel information : traffic-driven tunnel or 'permanent' 449 tunnel; tunnel mode IPsec or transport mode IPsec over an IP- 450 in-IP encapsulation; dynamic routing trough the tunnel or not) 452 (ii) in case of digital signature authentication, the following 453 information is to be retrieved from the SP's VPN server: 455 - a pair 457 - a certificate for the public key 459 - a public key from the Certificate Authority 461 - a list of tuplets 464 The above information is maintained on the SP's VPN server, and sent 465 to the CE device when necessary. 467 3.4 Establishing the (secure) VPN tunnels/SAs 469 When one Site sends traffic to another Site belonging to the same 470 VPN, these IP packets will be secured via IPsec. This means that an 471 IPsec Security Association is needed between each pair of sites that 472 directly exchange private VPN data with each other. 474 The Internet Key Exchange protocol (IKE, [IKE]) or its successor 475 IKEv2 [IKEv2] will be used for the purpose of automatic setup of 476 security associations between VPN sites within the same VPN. The CE 477 devices will use the information that they have retrieved (or 478 received) from the SP's VPN server to negotiate SAs with their peers, 479 using IKE(v2). 481 The succesfull establishment of such a 'VPN' IPsec SA between two CEs 482 will result in the auto-configuration of a new VPN tunnel (or virtual 483 link) between the two considered CE devices. 485 As explained in section 5 of this memo, a 'VPN tunnel' is either an 486 IP-in-IP tunnel protected by an IPsec transport mode SA or 487 alternatively a tunnel mode IPsec SA. In both cases, the VPN tunnel 488 is established once the protecting SA is established. 490 These dynamically established SAs can be set-up and maintained 491 independently of the presence of actual inter-site user traffic, 492 resulting in 'permanent' IPsec tunnels. These tunnels are then always 493 available and not traffic-triggered. It is then required to 494 frequently re-negotiate the SA (via IKE(v2)) before the IPsec timers 495 of the connection time out. The set-up of a 'permanent' IPsec tunnel 496 will be triggered by the configuration of a new peer CE device within 497 the same VPN. An advantage of this method is that the IPsec tunnel is 498 always available, and that eventual traffic does not encounter an 499 extra delay due to the setup time of a new SA. The use of 'permanent' 500 IPsec tunnels is recommended for CE-based site-to-site VPNs. 502 A CE device that first joins a VPN must retrieve the initial VPN 503 configuration information from the SP's VPN server. Next, for 504 'permanent' IPsec tunnels, the considered CE SHOULD subsequently 505 establish "VPN tunnel SAs" (using IKE) with every peer CE device 506 listed in the VPN configuration information. 508 o if the IKE negotiation is accepted and authentication succeeds, 509 the SA is successfuly established. 511 o if the IKE negotiation is refused or the authentication fails, 512 the IKE negotiation must be stopped and the SA not be established; 513 the CE device SHOULD then wait for a time interval larger than a 514 certain minimum value (to be configured, depending on e.g. the 515 responsiveness of the auto-discovery mechanism) and then try 516 negotiating the SA with the considered peer again. After a new 517 failure, the CE device SHOULD retry after a certain period of time 518 (t1, to be configured). This process SHOULD continue with 519 exponential backoff of t1 until a certain limit (to be configured) 520 upon which an alarm MUST trigger human interaction. 522 Provider provisioned CE-based IPsec VPNs as described by this 523 document SHOULD use 'permanent' IPsec Security Associations when 524 dynamic routing through IPsec-secured tunnels is used. 526 Alternatively, the IPsec SA setup can be triggered by the effective 527 (data) traffic flow going from one site to another. In this case, the 528 arrival of data packets at the CE device, coming from within the VPN 529 site and going to another VPN site, will be noticed by the CE's IPsec 530 or routing database, and an IKE exchange will be initiated to set up 531 an IPsec secured connection between both parties. Once the secure 532 tunnel is set up, the data packets can flow from one site to the 533 other in a secure way. When no traffic flows for a certain duration 534 of time, the secure tunnel will be torn down again. An advantage of 535 this method is that an IPsec tunnel is only to be maintained when 536 there is effectively traffic flowing. A disadvantage is the extra 537 delay introduced for the traffic during IKE signaling and the 538 difficult interaction with the tunneled inter-site VPN routing 539 information distribution. 541 Provider provisioned CE-based IPsec VPNs as described by this 542 document MAY use traffic-driven IPsec SA establishment when static 543 intra VPN inter-site routing is used (no dynamic routing through the 544 IPsec tunnels), see section 4.3. Provider provisioned CE-based IPsec 545 VPNs as described by this document SHOULD NOT use traffic-driven 546 IPsec SA establishment when dynamic site-to-site routing through the 547 IPsec-secured tunnels is used. 549 The CE configuration determines whether traffic-driven SA 550 establishment is used or not, and whether dynamic routing through 551 IPsec tunnels is used or not. 553 The procedures described in this memo can be used together with 554 [IPSEC-DPD] that offers a mechanism to efficiently keep IPsec SAs 555 alive. 557 Note that IPsec tunnels are unidirectional in nature, but that within 558 the application of this specificiation, the set-up of one direction 559 MUST be accompanied by the set-up of the reverse direction IPsec 560 tunnel. 562 This document describes two possible ways to use IPsec in CE-based 563 VPN scenarios (see section 5): in 'transport mode' or in 'tunnel 564 mode'. The CE configuration, IKE exchange and resulting SA's must 565 specify which mode will be used. 567 Note that the number of peer CE devices with which a specific CE 568 device must have an IPsec connection to secure the data traffic, is 569 dependent on the specific 'role' of the site in the considered VPN. A 570 hub CE will for example have a larger number of tunnels to support 571 than a spoke device. 573 3.5 Updating VPN configuration information 575 An important requirement for the scalability of L3VPNs is the 576 availability of an 'auto-discovery' mechanism. Such an 'auto- 577 discovery' mechanism should for example make sure that the 578 addition/deletion of a VPN site to/from an existing VPN is possible 579 by only configuring the 'new' CE device (and the SP's VPN database): 580 the existing VPN sites should automatically 'discover' the new site 581 in a reliable and secure manner. 583 The precise autodiscovery mechanism and related protocol actions will 584 highly depend on the remote management protocol in use. As such this 585 document does not describe a specific autodiscovery mechanism, and 586 the principles of this document remain interoperable with any 587 autodiscovery mechanism. 589 The remote management protocol can operate in a 'push' model (when a 590 new CE device is added to the VPN, the VPN server pushes the new VPN 591 configuration information to all existing CE devices from that VPN), 592 in a 'pull' model (CE devices periodically download their VPN 593 configuration information from the SP's VPN server, or after 594 receiving tunnel establishment requests from unknown CE devices), or 595 in a combined mode (the SP's VPN server sends a 'notification' to the 596 CE devices that tells them to update their VPN configuration 597 information by downloading it from the VPN server). The different 598 modes and the applied protocol dynamics will have different 599 reliability characteristics. 601 3.6 Removing an existing VPN site 603 When the VPN customer wants to remove an existing site from a certain 604 VPN, this customer first informs the VPN SP. The SP will then update 605 the VPN database on the centralized server. 607 Different approaches can then be used. The SP can provision the 608 considered CE device to delete its VPN information and to tear-down 609 the IPsec SA's using IKE(v2). After completion of the IKE tear-down 610 proces, the peering CE devices must not attempt to re-establish the 611 deleted SA. At this stage, the VPN tunnels are actually removed, and 612 the routing protocols operating through the tunnels in the VPN's 613 routing space will notice the topology change and react 614 appropriately. The periodical retrieval of the VPN configuration 615 information from the VPN database by the other CE devices will then 616 make sure that the removed CE's information is no longer available. 617 The discussed provisioning action can happen in the same way as the 618 pre-provisioning action described in section 3.1, i.e. via manual 619 configuration, via remote management or via interaction with the 620 customer. 622 Alternatively, the SP will not provision the to-be-removed CE 623 individually but the removal of the information relevant to the 624 considered CE from the VPN database will ultimately automatically 625 result in the removal of the CE from the VPN: peer CEs will notice 626 the removal of the particular CE from their updated configuration 627 file and will tear-down the appropriate SA using IKE(v2); the 628 deletion of active SAs will effectively remove the VPN tunnels and 629 the routing protocols running through the VPN tunnels will discover 630 the topology changes and react accordingly. The to-be-removed CE will 631 not be able to retrieve VPN information from the VPN database and 632 will delete all its VPN information and try to tear-down the 633 remaining SAs. 635 4. Exchanging and maintaining VPN routes 637 One of the requirements for PP CE-based VPNs is that dynamic routing 638 is not only supported within individual VPN sites, but also between 639 the different VPN sites of a specific VPN. This means that when a 640 change in the routing information in a specific site occurs, the 641 other sites that belong to the same VPN must be notified of that 642 change. 644 This section deals with the exchange of routing information in the 645 customer VPN's routing space (v). As depicted in figure 4, this 646 exchange of routing information happens over the VPN tunnels and is 647 as such transparant for the SP's network. CE devices MUST NOT leak 648 VPN routes into the SP's network and MUST NOT leak routes from the 649 SP's routing space into the VPN sites, unless explicitly configured 650 to do so (as e.g. explained in section 6 of this document). 652 routing adjacency (VPN space) 653 ______________________________________________________ 654 CE_1 | | CE_2 655 -------|----------------- ---------------|------- 656 | _____V____ === |I| | | |I| === ____V_____ | 657 | |routing/ |=======|P|==|===== VPN tunnel ===|=|P|======|routing/ | | 658 | |forwarding| === |s| | | |s| === |forwarding| | 659 | |VPN space | === |e| |-- PE - core - PE --| |e| === |VPN space | | 660 | ---------- =====|c|==|= | |c| = = ---------- | 661 | IP-in-IP | || | IPinIP | 662 |_________________________| == to CE_3 ----------------------- 664 --- VPN space ---><--------- SP's routing space ------><-- VPN space -- 666 figure 4: tunnelled routing adjacency in the VPN routing space 668 This document assumes that the routing within a VPN site is 669 controlled by the VPN customer, and thus is outside of the scope of 670 this specification. 672 4.1 The CE device and VPN routing 674 On the customer network side, a CE router connects to internal 675 networks of an enterprise, where one or more subnets can reside. Many 676 times, the CE router may interact with another internal router. And 677 sometimes, "backdoor links" between routers of different sites of the 678 same VPN exist. 680 In the VPN routing space (v), the CE is involved in (i) the intra- 681 site routing, (ii) the VPN tunnel termination, and (iii) the inter- 682 site VPN routing. 684 The CE device could be an integrated device providing both routing 685 and IPsec tunnel termination. Sometimes, a dedicated VPN terminator 686 may be used. Implementations in which the VPN tunnel terminator 687 resides on a firewall are also very common. For the sake of 688 simplicity, we assume that the CE router is an integrated device that 689 participates in the intra-site routing (e.g. via an IGP) and at the 690 same time terminates VPN tunnels. 692 In the context of this document, the routing aspects within a VPN 693 site (intra-site routing information distribution) are controlled by 694 the VPN customer. 696 As was explained earlier, the SP's dynamic VPN discovery scheme and 697 tunnel establishment mechanism provides the CE device with secure 698 (virtual) links towards other CE devices in the same VPN. Whether the 699 intra-VPN inter-site routing aspects that make use of these virtual 700 links are managed by the customer or by the SP is dependent on the 701 service contract. In many situations, the SP will configure the 702 necessary routing protocol information at pre-configuration time (see 703 section 3.1), in close colaboration with the customer. 705 An important requirement for the routing protocol implementation that 706 is configured to exchange reachability information through the 707 inter-site tunnels, is that it must be able to autonomously deal with 708 dynamically created new inter-site links. 710 4.2 IPsec and routing 712 IPsec is a layer 3 security protocol, which operates purely at the IP 713 layer. The IETF IPsec Working Group currently specifies the revisions 714 of the IPsec standards ([IPSEC], [RFC2402], [RFC2406], [RFC2407], 715 [RFC2408], and [IKE]). The interaction between IPsec and layer 3 716 routing was often troublesome and has been described in [TOUCH], 717 [KNIGHT] and [DUFFY]. Depending on individual implementations, 718 difficulty may arise when an IPsec user wants to support robust 719 routing across IPsec-interconnected VPNs sites. 721 Details regarding the problems of the interaction between VPN routing 722 and VPN tunneling, and some proposed solutions to counter these 723 issues, can be found in [TOUCH], [DUFFY] and [KNIGHT]. 725 4.3 Exchanging VPN routes between VPN sites 727 In the proposed mechanism to exchange VPN reachability information 728 between VPN sites, routing protocol messages are tunneled through the 729 IPsec-secured tunnels between peering sites. The CE-to-CE IPsec- 730 secured tunnels between VPN sites are then being seen as point-to- 731 point links by the customer networks and are interpreted as such by 732 the routing protocol functions of the CE devices. This means that 733 when a change in the reachability occurs in one particular site, a 734 routing protocol (such as RIP, OSPF, etc.) will take care of the 735 distribution of the new reachability information within the site, but 736 also to all other sites, through the VPN tunnels that the considered 737 CE is possibly maintaining. 739 As the described architecture allows for the dynamic creation of 740 inter-site (IPsec-protected) VPN links, the routing protocol 741 implementation(s) operating on the CE device MUST be able to support 742 this. 744 Although very often it will be the SP's responsibility to configure 745 the CE's routing information at pre-configuration time, the service 746 aggreement MAY specify that routing on the CE device falls under the 747 customer's management. 749 When routing protocol messages are tunneled through the IPsec-secured 750 tunnels ('dynamic routing through IPsec-secured tunnels') as per this 751 section, IPsec transport mode secured IP-in-IP tunnels as per [TOUCH] 752 SHOULD be used (in contrast to IPsec tunnel mode tunnels). 754 Note that other approaches may use a combination of dynamic routing 755 and IPsec tunnel mode tunnels, though it is not clear how 756 interoperability will then be assured. 758 Another issue to consider is the fact that using a traffic-driven 759 tunnel establishment mechanism and at the same time using an approach 760 whereby a routing protocol (with a keep-alive mechanism) runs on top 761 of the VPN tunnel, does not seem currently applicable: the delay 762 introduced by the tunnel establishment phase could lead to a loss of 763 routing updates and the routing protocol's keep-alive mechanism could 764 interact with the tunnel establishment in an undesired way. 765 Therefore, when dynamic routing is used through IPsec-secured CE-to- 766 CE tunnels, traffic-driven SA establishment SHOULD NOT be used. 768 5. Tunneling IP traffic (user data) among VPN sites 770 This section describes the processes that an IP packet that is sent 771 from one VPN site to another will go through. This is dependent on 772 the way that IPsec is used. This document describes two possible ways 773 to use IPsec in CE-based VPN implementations: IPsec in tunnel mode, 774 and IPsec in transport mode. 776 An IP packet that is sent by an IP device in a certain site and 777 destined for an IP device in another site belonging to the same VPN, 778 will be forwarded as follows. 780 The device in the sending site sends an IP packet (possibly using a 781 private address space) on its LAN network. The next hop for this 782 destination IP address will (at some point in time) be the site's CE 783 device (according to the routing/forwarding in the VPN site). The 784 processing by the CE device now is dependent on the implemented mode 785 for IPsec. 787 The use of IPsec in tunnel mode has the advantage that the complete 788 range of SPD-checks remain usuable, but has the disadvantage that 789 dynamic routing through the tunnels is not supported. The use of 790 IPsec in transport mode secured IP-in-IP tunnels has the advantage 791 that dynamic routing through the tunnels is fully supported, but has 792 the disadvantage that the complete range of SPD-checks is not 793 supported. 795 Note that the following description is not meant to specify an 796 implementation strategy; any implementation procedure wich produces 797 the same results is acceptable. 799 o IPsec in transport mode (see also [TOUCH] for a detailed 800 specification) 802 When IPsec is used in transport mode in this context, the CE 803 device must first analyze the private IP packets arriving from 804 within the site and select the appropriate outgoing interface and 805 required encapsulation, based on the VPN routing/forwarding 806 information. For a destination located in an other site, the 807 outgoing interface will be a virtual interface (a VPN tunnel) and 808 the required encapsulation will be IP-in-IP, using the considered 809 CE's IP address (s) as the source address in the outer IP 810 encapsulation header and a peer CE's IP address (s) in the outer 811 IP encapsulation header's destination address field. The CE device 812 then processes this new IP packet to its IPsec driver. 814 The IPsec driver in the CE device must then do the following: 816 - analyze the IP packets that have been IP-in-IP encapsulated and 817 select the appropriate SA (based on the packet's outer header 818 destination address (s)). 820 - authenticate and/or encrypt the private IP packet according to 821 the (transport mode-specific) rules described in the SA and insert 822 an appropriate IPsec header (according to IPsec in transport 823 mode). 825 o IPsec in tunnel mode 827 When IPsec is used in tunnel mode in this context, the IPsec 828 driver in the CE device must do the following: 830 - analyze the private IP packets arriving from within the site and 831 select/setup an appropriate SA with the appropriate destination CE 832 device. 834 - authenticate and/or encrypt the private IP packet according to 835 the (tunnel mode-specific) rules described in the SA, AND 836 encapsulate the packet in an IPsec header AND encapsulate the 837 packet in a new 'outer' IP header. This 'outer' IP header has the 838 CE's non-private (i.e. routable in the SP's realm) IP address in 839 the source IP address field and the destination CE's non-private 840 (i.e. routable in the SP's realm) IP address in the destination IP 841 address field. 843 The CE device then sends the IPsec packet to the PE device, and the 844 IPsec packet will then be forwarded using 'normal' IP forwarding 845 across the SP's network, based on the outer header's IP destination 846 address (s), that is the destination CE's 'global' (i.e. routable in 847 the SP's realm) IP address. The packet will be forwarded to the 848 egress PE who will also only examine the outer IP header and send the 849 IP(sec) packet to the destined CE device. The egress CE device will 850 recognize itself as the destination node (the IP packet has the CE's 851 IP address (s) in the outer IP destination address field) and process 852 the IPsec packet to the IPsec driver that will then, based on the 853 appropriate Security Association (identified by the packet's SPI 854 field in the IPsec header), perform IPsec authentication and/or 855 decryption. Dependent on whether tunnel mode or transport mode IPsec 856 is used, the packet will be decapsulated by the IPsec driver itself 857 or sent to the IP-in-IP decapsulation function. The resulting 858 (private) IP packet (v) will then be further processed in the CE's 859 VPN IP forwarding table and send on the LAN network to the 860 appropriate next hop router or destination IP device. 862 Note that IPsec tunnels might unintentionally terminate or break. 863 When dynamic routing is not supported through the inter-site VPN 864 tunnels, this may have serious consequences if VPN membership and VPN 865 routing information are not changed accordingly within the VPN. 866 Indeed, the unnoticed termination of a VPN tunnel can result in the 867 creation of black holes. 869 This means that a mechanism must exist to monitor the state of the 870 VPN tunnels. When dynamic inter-site VPN routing is used, the routing 871 protocol that runs on top of the IPsec VPN tunnels will serve that 872 purpose. When dynamic inter-site routing is not used, the following 873 alternatives are possible: (i) the use of an IPsec-specific keep- 874 alive mechanism [IPSEC-DPD] and (ii) a SP-proprietary mechanism. 876 6. CE-based VPN and Internet 878 6.1 Allowing both VPN connectivity and Internet connectivity 880 In many VPNs, sites will need to both access the public Internet as 881 well as to access other sites within the same VPN. 883 In order to achieve this, some sites within the VPN will obtain 884 Internet Access by means of an "Internet Gateway" that is attached 885 via one of its interfaces to an ISP's PE device. Such an Internet 886 Gateway may for example be a firewall and may need to implement 887 network address translation functions. The ISP may be the same SP 888 that offers the VPN service, or it may be a different SP. The PE to 889 which the Internet Gateway is connected may be the same PE to which 890 the CE is connected or it may be an other PE. 892 The Internet Gateway may be a separate device, or alternatively the 893 Internet Gateway functions may be integrated into the CE device. When 894 the Internet Gateway functions are integrated into the CE device, the 895 CE-PE interface used by the Internet Gateway functions may be the 896 same or a different interface than the interface used by the VPN 897 tunnels. In further discussions, we'll assume that the Internet 898 Gateway is a separate device. 900 The service contract will define whether the Internet Gateway will be 901 managed by the SP or by the VPN customer. 903 Note that when Internet Access is offered within a VPN, the address 904 spaces used within the VPN must be non-overlapping. This means that 905 the VPN SHOULD either use global addresses that have been assigned to 906 the VPN customer, or private addressing in combination with NAT 907 [NAT]. 909 The sites that have Internet Access via an Internet Gateway will have 910 a default route (v) pointing to their Internet Gateway and may be 911 distributing a default route via their CE towards the other CEs of 912 the same VPN through the VPN tunnels. This provides Internet Access 913 for all the VPN sites. Note that other sites (that don't have their 914 own Internet Gateway) must not distribute default routes in this 915 scenario. A site that has distributed a default route to other sites 916 for Internet Access should have either a default route to its 917 Internet Gateway or Internet routes (leading to its Internet Gateway) 918 in its forwarding table (of the VPN routing space). 920 VPN site <---- : 921 : 922 ---------- to Internet : 923 _____| Internet |----------------:-- PE_2 924 | | Gateway | : 925 | ---------- : 926 --------|--------------------------- : 927 | default | : 928 | route to | : 929 | _____|______ | : 930 | | | ===== CE2 |I| | : 931 ----|--|routing and | ===== CE3 |P| | : 932 | |forwarding | ===== CE4 |s| -->|-----:-- PE_1 933 ----|--|in VPN space| ===== CE5 |e| | : 934 | ------------ = = = |c| | : 935 | IP-in-IP | : 936 |______CE device_____________________| : 937 <--- : 938 intra : 939 site : 940 : 941 figure 5: Internet Access from within a VPN 943 The Internet Gateway will process (e.g. firewall + NAT) all traffic 944 coming from within the VPN and, if accepted, send it to the PE with 945 which it interfaces. As such the Internet Gateway effectively is the 946 device that interfaces between the VPN routing space and the 947 SP's/Internet routing space. Note that traffic that leaves a VPN via 948 an Internet Gateway will not be IP-in-IP encapsulated and will not be 949 IPsec processed. The traffic coming from the gateway will then be 950 forwarded according to the PE's (default/Internet) forwarding table. 952 In order to allow for traffic in the reverse direction (from the 953 Internet to the VPN sites), the ISP connected to the Internet Gateway 954 must distribute, to the Internet, routes that lead to addresses that 955 are within the VPN. NAT-like techniques may also be used. As such 956 there will be routes that will lead from the Internet to the site's 957 Internet Gateway. The Internet Gateway will process traffic coming 958 from the Internet and, if accepted, send it into the VPN site where 959 intra-VPN routing and forwarding will lead the packets to their 960 destination. This distribution of routes that lead to addresses 961 within the VPN towards the Internet is independent of any intra-VPN 962 route distribution as described elsewhere within this specification. 963 Note also that normally the internal structure of the VPN will remain 964 invisible to the outside world. 966 When the Internet Gateway functions are implemented in the CE device 967 and the CE device is attached via only one (sub-)interface towards 968 only one PE device, inspection of the packets coming from the PE will 969 indicate whether the concerned traffic is intra-VPN traffic (when the 970 packet is an IPsec packet with the CE device's own IP address (s) in 971 the outer header's destination address field and the encapsulated 972 payload is an IP-in-IP encapsulated private IP packet (v), and a 973 matching SA is found), or control-plane traffic (IKE(v2) or VPN 974 remote management traffic: when the inspected packets conform to the 975 control plane's policies), or VPN <--> Internet traffic (then the 976 Internet Gateway function will decide whether the considered packets 977 will be accepted, (translated), and forwarded or not). 979 In the above discussed procedures, some sites will access the 980 Internet via a VPN tunnel that leads to another site of the same VPN, 981 because they don't have an own Internet Gateway, and will forward the 982 traffic according to the default route. Ultimately though, Internet 983 traffic will always go via an Internet Gateway before 984 entering/leaving a VPN. 986 Further note that the PE to which the Internet Gateway is attached 987 doesn't necessarily need to carry all the Internet routes; a default 988 route to an other Internet router suffices. 990 6.2 Prohibiting or restricting Internet connectivity from within a CE- 991 based VPN 993 In the approach described in this document, the CE device sends IP 994 packets (s) to the VPN-unaware PE device and receives IP packets from 995 that PE device. The PE device forwards these packets based on the IP 996 addresses (s) in the (outer) IP header. The packets received by the 997 PE are as such either packets that are routable within the SP's 998 private scope, or either in the public Internet's scope. This section 999 discusses the implications hereof with regards to security and access 1000 control. 1002 o traffic that the CE sends to the PE 1004 Following the procedures described in this document, three types 1005 of 'VPN' traffic can be sent by the CE device towards the PE 1006 device: 1008 (i) customer VPN traffic: intra-VPN traffic sent from one VPN site 1009 to an other VPN site; these packets will always have the sending 1010 CE's IP address (s) in the IP header's source IP address field, 1011 the IP address (s) of a peer CE device of the same VPN in the IP 1012 header's destination IP address field, and will always contain an 1013 IPsec header; 1015 (ii) secure remote management traffic: this comprises both the 1016 traffic to establish the secure management channel (e.g. IPsec or 1017 secure TLS) and the traffic to download the VPN configuration 1018 file; these packets will always have the CE's IP address (s) in 1019 the IP header's source IP address field; 1021 (iii) IKE(v2) traffic: the IP packets sent between CE devices in 1022 order to establish SAs; these packets will always have the CE's IP 1023 address (s) in the IP header's source IP address field. 1025 o traffic that the CE receives from the PE 1027 Following the procedures described in this document, the same 1028 three types of traffic can be received by the CE device from the 1029 PE device. As such, the CE device should perform the following 1030 actions: 1032 + for IP packets that have the CE's own IP address (s) in the 1033 outer IP header's destination address field and that have an IPsec 1034 header: process the packets through the CE router's IPsec deamon 1035 where conformance with an existing SA will be checked, and the 1036 packets further processed; 1038 + for IKE(v2) packets that have the CE's own IP address (s) in the 1039 outer IP header's destination address field: process according to 1040 the tunnel establishment procedures described in this 1041 specification; 1043 + for IP packets that have the CE's own IP address (s) in the 1044 outer IP header's destination address field and that correspond to 1045 secured management traffic: process according to the VPN secure 1046 remote management procedures, which will depend on the used 1047 management protocols; 1049 + for CE devices that have an integrated Internet Gateway role: 1050 process all other packets to the Internet Gateway module; 1052 + for CE devices that don't have an integrated Internet Gateway 1053 role: drop all other IP packets, unless explicitly allowed by 1054 complementary procedures that are out of scope of this memo. 1056 o SP's control over CE initiated traffic 1058 Note that with this specification's concepts, the PE device that 1059 receives traffic from a CE device has no means to verify whether 1060 the received traffic is intra-VPN traffic, or traffic that is sent 1061 to for example an other VPN or e.g. to the Internet. 1063 From a VPN data privacy point of view, this has no implications, 1064 as the security is enforced at the CE devices themselves: traffic 1065 that doesn't conform to the security associations or other policy 1066 rules will be dropped at the CE. 1068 One remaining issue is that customers might use CE devices (that 1069 have been granted VPN access) to access services they have not 1070 been granted access for, via the PE device. Although this would 1071 possibly compromise the security of the customer's own VPN, the SP 1072 may want to deploy measures to prevent this without bringing full 1073 VPN knowledge to the PE. One way of doing this would be by using 1074 specific IP address ranges for VPN purposes and to have specific 1075 access lists configured on the PE devices (this has inter-SP and 1076 Internet transparency issues though). Note that maintaining, at 1077 every PE, a list of would add a 1078 considerable management burden and is as such not advised. Another 1079 strategy for the SP would be not to care about the particularities 1080 of the traffic and treat it as it treats public Internet traffic 1081 (and as such to only control the total of the resources consumed 1082 by particular access connections). 1084 Taking into consideration that in many cases, VPNs will also need 1085 to be able to access the public Internet, and that the above 1086 problem does not seem to be an important thread for the SP nor the 1087 VPN customer, this issue is not considered as a major drawback for 1088 the deployment of the discussed VPN approach. 1090 7. Quality of Service 1092 TBD. 1094 8. Security Considerations 1096 The security aspects of what is presented in this document are 1097 implicitly discussed in most of the sections. This draft is for a 1098 large part focussing on security aspects. 1100 Note that the security of the mechanisms presented here is highly 1101 dependent on the following factors: 1103 - the security of the 'management channel', used by the management 1104 protocol to configure the VPN CE devices. 1106 - the security of the site and of the CE-device itself 1108 - the security aspects of the credentials: the IPsec credential 1109 must be generated, provisioned, updated, and stored securely 1111 - for a VPN with a complex topology, every tunnel must use the 1112 same grade of security strength, otherwise, a single weak link 1113 degrades the whole VPN 1115 9. Acknowledgements 1117 The authors would like to thank the following persons for their 1118 valuable contributions to this document: Lars Eggert, Brian Gleeson, 1119 Archana Khetan, Sankar Ramamoorthi, Eric Rosen, Michael Choung Shieh, 1120 Joe Touch, Eric Vyncke, S. Felix Wu, Yu-Shun Wang, Cliff Wang, Alex 1121 Zinin. 1123 10. References 1125 [DUFFY] Duffy, M., "Framework for IPsec Protected Virtual Links for 1126 PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00.txt, October 2002, Work in 1127 Progress 1129 [FRAMEWORK] Callon, R. et al., "A Framework for Provider Provisioned 1130 Virtual Private Networks", draft-ietf-ppvpn-framework-0x.txt, Work in 1131 progress 1133 [GRE] Farinacci, D. et al., "Generic Route Encapsulation", March 1134 2000, RFC 2784 1136 [GRE-CE] Khetan, A., et al., "Use of GRE for routing support in IPsec 1137 VPNs", draft-khetan-sp-greipsec, Work in progress 1139 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", 1140 November 1998, RFC 2409 1142 [IPinIP] Perkins, C., "IP encapsulation within IP", October 1996, RFC 1143 2003 1145 [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the 1146 Internet Protocol", November 1998, RFC 2401 1148 [IPSEC-DPD] Huang, G., Beaulieu, S., Rochefort, D., "A Traffic-Based 1149 Method of Detecting Dead IKE Peers", draft-ietf-ipsec-dpd-0x.txt, 1150 Work in progress 1152 [KNIGHT] Knight, P., Gleeson, B., "A Method to Signal and Provide 1153 Dynamic Routing in IPsec VPNs", draft-knight-ppvpn-ipsec-dynroute, 1154 Work in progress 1156 [LEE-DHCP] Lee, C.Y., "Customer Equipment Auto-configuration", March 1157 2002, work in progress 1159 [L2TP] Lau, J., et al., "Layer Two Tunneling Protocol (Version 3)", 1160 draft-ietf-l2tpext-l2tp-base-0x.txt, Work in progress 1162 [NAT] Srisuresh, P., Egevang, K., "Traditional IP Network Address 1163 Translator (Traditional NAT)", January 2001, RFC 3022 1165 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", 1166 November 1998, RFC 2402 1168 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 1169 (ESP)", November 1998, RFC 2406 1171 [RFC2407] Piper, D., "The Internet IP Security Domain of 1172 Interpretation for ISAKMP" November 1998, RFC 2407 1174 [RFC2408] Maughan, D., et al., "Internet Security Association and Key 1175 Management Protocol (ISAKMP)", November 1998, RFC 2408 1177 [TOUCH] Touch, J. and Eggert, L., "Use of IPSEC transport mode for 1178 Virtual Networks", draft-touch-ipsec-vpn-0x.txt, Work in progress 1180 11. Authors' Addresses 1182 Jeremy De Clercq 1183 Alcatel 1184 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 1185 E-mail: jeremy.de_clercq@alcatel.be 1187 Olivier Paridaens 1188 Alcatel 1189 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 1190 E-mail: olivier.paridaens@alcatel.be 1192 Cliff Wang 1193 E-mail: cliff.wang@us.army.mil