idnits 2.17.1 draft-ietf-l3vpn-ce-based-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1205. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 2005) is 6705 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) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jeremy De Clercq 3 INTERNET DRAFT Olivier Paridaens 4 Alcatel 5 Andrew Krywaniuk 6 Cliff Wang 8 December 2005 9 Expires June, 2006 11 An Architecture for 12 Provider Provisioned CE-based Virtual Private Networks 13 using IPsec 15 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Distribution of this memo is unlimited. 41 Abstract 43 This informational document describes procedures for a Service 44 Provider to offer Virtual Private Network Services to its customers 45 by provisioning the CE devices on behalf of the customer. The IPsec 46 technology is used to protect the customer traffic. 48 Table of Contents 49 1. Introduction ................................................ 2 50 2. Reference Model ............................................. 3 51 2.1 Entities in the Reference Model ............................. 3 52 2.2 IP Connectivity between CE and PE devices ................... 5 53 2.3 Assumed Service Provider's Infrastructure ................... 7 54 3. Configuring the CE-based VPN ................................ 8 55 3.1 Initializing the SP's VPN database .......................... 8 56 3.2 Pre-configuration of the CE device .......................... 9 57 3.3 Fetching the VPN configuration information .................. 10 58 3.4 Establishing the (secure) VPN tunnels ....................... 11 59 3.5 Updating the VPN configuration information .................. 13 60 3.6 Removing an existing VPN site ............................... 13 61 4. Exchanging and maintaining VPN routes ....................... 14 62 4.1 The CE device and VPN routing ............................... 15 63 4.2 IPsec and routing ........................................... 16 64 4.3 Exchanging VPN routes between VPN sites ..................... 16 65 5. Tunneling IP traffic (user data) among VPN sites ............ 17 66 6. CE-based VPN and Internet ................................... 19 67 6.1 Allowing both VPN connectivity and Internet connectivity .... 19 68 6.2 Prohibiting or restricting Internet connectivity from within 69 a CE-based VPN .............................................. 21 70 7. Security Considerations ..................................... 23 71 8. IANA Considerations ......................................... 24 72 9. Acknowledgements ............................................ 24 73 10. References .................................................. 24 74 11. Authors' Addresses .......................................... 25 76 1. Introduction 78 The L3VPN framework document [FRAMEWORK] identifies three basic 79 provider provisioned VPN types : Provider Provisioned Network Based 80 (also termed PE-based) Layer 3 VPNs, Provider Provisioned Layer 2 81 VPNs and Provider Provisioned CE-based VPNs. 83 This document describes a method enabling a Service Provider to offer 84 IP VPN services to its customers by provisioning the CE devices on 85 behalf of the customer (Provider Provisioned CE-based VPNs). This 86 document describes which parameters need to be provisioned, but not 87 which protocol to use for the provisioning. As such, this document is 88 of informational nature and does not specify a protocol specification 89 from which one can achieve interoperability. 91 For a CE-based VPN to be set up under the SP's control, the VPN 92 customer informs the Service Provider of which sites (identified by a 93 set of CE devices) should become part of the considered VPN and what 94 the requested topology of the VPN should look like. The SP then 95 configures and updates its VPN database, and then provisions and 96 manages the Customer's VPN. 98 The model proposed in this document uses the IPsec protocol suite for 99 the purpose of securely tunneling the customer VPN traffic and the 100 inter-site reachability information distribution. 102 2. Reference Model 104 The reference model upon which the mechanisms and procedures 105 described in this document are based, is taken from the CE-based VPN 106 reference model described in [FRAMEWORK]. The most important aspects 107 of that framework model and the restrictions that are relevant to 108 this document are described in this section. 110 +---------+ +------------------------------------+ +---------+ 111 | | | | | | 112 | | | +------+ +------+ : +------+ 113 +------+ : | | | | | | : | CE | 114 | CE | : | | | P | | PE | : |device| 115 |device| : +------+ VPN tunnel |router| |device| : | of | 116 | of |=:====================================================:=|VPN A| 117 |VPN A| : | | +------+ +------+ : +------+ 118 +------+ : | PE | | | : | 119 +------+ : |device| | | : | 120 | CE | : | | VPN tunnel +------+ : +------+ 121 |device|=:====================================================:=| CE | 122 | of | : +------+ | PE | : |device| 123 |VPN B| : | | |device| : | of | 124 +------+ : | | +------------+ +------------+ | | : |VPN B| 125 | : | | | Customer | | Network | +------+ : +------+ 126 |Customer | | | management | | management | | | : | 127 |interface| | | function | | function | | |Customer | 128 | | | +------------+ +------------+ | |interface| 129 | | | | | | 130 +---------+ +------------------------------------+ +---------+ 131 | Access | |<---------- SP network(s) --------->| | Access | 132 | network | | | | network | 134 Figure 1: Reference model for provider provisioned CE-based VPNs 136 2.1 Entities in the reference model and Terminology 138 o Customer Edge (CE) device 140 In the context of this solution, a CE device is a router located 141 at the edge of a customer site, that has IP connectivity with a 142 SP's PE device (not necessarily Internet connectivity). A CE 143 device maintains one or more VPN tunnel endpoints. The VPN- 144 specific functions in the CE device are provisioned by the SP. 146 Note that other functions that are normally applied by the PE 147 router may need to be performed by the CE device in this context 148 (e.g. NAT functionality, QoS classification, etc.). These 149 functions may be managed by the SP or alternatively be managed by 150 the VPN customer, depending on the applicable service contract. 152 The CE device may also provide general (non VPN-oriented) Internet 153 connectivity for the customer network. Such connectivity may be 154 achieved via the SP's PE router that provides the VPN connectivity 155 or some other router (of the same or another SP). In such a 156 situation, the CE device must be able to distinguish between 157 traffic to be sent through a VPN and traffic to be sent outside 158 any VPN. Section 6 of this document discusses this in more 159 details. 161 CE devices in a CE-based VPN model differ from CE devices in a 162 PE-based VPN model in that they need to support VPN-specific 163 functions. With CE-based PPVPNs, the VPN awareness is pushed even 164 further towards the edges of the provider networks. 166 o Provider Edge (PE) router 168 In the context of Provider Provisioned CE-based VPNs, a PE router 169 is a router, located at the edge of the Service Provider's 170 network, that does not have any VPN-specific functionality. A PE 171 router is attached via an access connection to one or more CE 172 devices, and offers possibly limited or restricted IP 173 connectivity, or possibly full Internet connectivity, over the 174 access connections to these CE devices. 176 o SP network 178 A SP network is a network administrated by a single service 179 provider. In the context of PP CE-based VPNs, the SP who owns the 180 SP network can also be the VPN provider (managing the CE devices). 181 This can lead to operational advantages (e.g. for offering QoS). 182 Alternatively, the SP owning the SP network may be an ISP offering 183 Internet connectivity, while another entity may provision the VPN 184 service. This configuration allows for inter-SP and Internet-wide 185 VPN scenarios. 187 o Access connection 189 An access connection represents a layer 2 connectivity between a 190 CE device and a PE router. This includes dedicated physical 191 circuits, logical circuits (such as Frame Relay and ATM), IP 192 tunnels (e.g., using IPsec, L2TP) and shared medium access (such 193 as Ethernet-based access). In the context of provider provisioned 194 CE-based VPNs, the CE device and the PE router have layer 3 195 connectivity over the Access Connection. 197 o VPN tunnel 199 A VPN tunnel is a logical link between two entities which is 200 created by encapsulating packets within an encapsulating header 201 for purpose of transmission between those two entities for support 202 of VPNs. In the context of provider provisioned CE-based VPNs, a 203 VPN tunnel is an IP tunnel (e.g., using IPsec [IPSEC], L2TP 204 [L2TP], GRE [GRE], IP-in-IP [IPinIP]) between two CE devices over 205 the SP's network. In the context of this document, a VPN tunnel is 206 achieved using IPsec in tunnel mode or via an IP-in-IP tunnel 207 protected by IPsec in transport mode between two CE devices. 209 o Security Association (SA) 211 Throughout this document, the acronym SA will be used to denote an 212 IPsec Security Association. 214 2.2 IP connectivity between CE and PE devices 216 CE devices operating in a PP CE-based VPN will operate in two 217 independent IP routing spaces. 219 The first routing space is the VPN routing space. Hosts and routers 220 within the VPN will use IP addresses that belong to this VPN routing 221 space. The CE router will participate in this VPN routing space, and 222 will create VPN tunnels (virtual links) to be used as virtual 223 interfaces by this VPN routing space. 225 The second routing space is the SP's routing space. Every CE device 226 that belongs to a PP CE-based VPN is identified by an IP address that 227 is routable in the SP's network. This IP address may be a global IP 228 address or a private IP address. The CE device is reachable from the 229 SP's core network via this IP address. 231 In order to easily differentiate between these two routing spaces, 232 this document uses the following convention: IP addresses belonging 233 to the VPN's routing realm will be followed by a 'v' between 234 brackets: address (v); IP addresses belonging to the service 235 provider's routable space will be followed by a 's' between brackets: 236 address (s). 238 These two routing spaces may use overlapping address spaces and thus 239 need to be kept separate in the CE devices. The way this is done is 240 largely implementation dependent. This may be by using two separate 241 sets of (virtual) routing and forwarding tables (figure 2). These 242 routing tables may then run independent routing protocols. 244 Only the CE's IP address (s) needs to be reachable in the provider's 245 core network. This means that this approach requires only one IP 246 address (s) per CE device to be injected in the core network. A CE 247 device should not inject other routes into the SP's network (one 248 exception is for Internet Access scenarios, which are discussed in 249 section 6). In many cases, this CE's IP address (s) may be an IP 250 address assigned by the SP who owns the core network. As such, 251 aggregate routes can be distributed by the PE devices into the core 252 network. 254 The CE device and the PE device may be routing protocol peers in the 255 SP's routing space. Alternatively, a default route (s) (towards the 256 PE) may be statically configured in the SP's routing space on the CE 257 device, and the CE device's IP address (s) statically configured on 258 the PE. The CE device should not inject SP's routes (s) towards the 259 other routers within its VPN site (except in the context of the 260 Internet Access scenarios described in section 6). 262 Note that, when the CE device is attached to only one PE device, via 263 only one (sub-)interface, the CE's implementation can be fairly 264 straightforward (see figure 3). With regards to the SP routing space, 265 the CE device then acts as a host, having only one outgoing 266 interface. The source IP address (s) (of the _outer_ IP header) of 267 all packets leaving the CE device will always be the CE's identifier, 268 and the IP next hop will always be the PE device to which it is 269 attached. On the CE, no routing decisions need to be performed in the 270 provider's routing space and only one forwarding action is possible. 272 The following figures give an overview of the routing spaces in the 273 CE device. Note that this description is merely an example and is not 274 meant to specify a particular implementation. 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| |forwarding 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 can 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 preferred 320 routes 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 the management access to the CE devices may be in-band 341 (i.e. using the same access connections as the VPN data traffic) or 342 alternatively the management access may be out-of-band, for example 343 using a dial-up connection. 345 Note that this document does not prescribe one particular protocol 346 for this provisioning channel. Some examples are: SOAP/XML/HTTP/TLS, 347 CLI/Telnet/SSH, an IPsec-protected remote configuration protocol, 348 etc. 350 As the SP will be responsible for provisioning the secure tunnels 351 between the CE devices, it needs to deploy a key management system. 353 3. Configuring the CE-based VPN 355 As was noted before, this document does not describe the protocol to 356 use as a remote management protocol to provision CE devices. It does 357 however describe with which information CE devices need to be pre- 358 provisioned, and which parameters need to be configurable via this 359 management protocol by the Service Provider. 361 3.1 Initializing the VPN database 363 As a first step in the VPN configuration process, the Service 364 Provider configures its VPN database with a new VPN entry and with 365 the IP addresses (s) or identifiers of the CE devices belonging to 366 the VPN, and with a description of the VPN's topology. 368 For every CE device, the following information is configured and 369 maintained in the VPN database: 371 - the security information that is necessary for the secure remote 372 management protocol. This information should allow for mutual 373 authentication between CE and SP's VPN server, and for encryption 374 of the management data. The details of this information will 375 depend on the particular protocol (stack) used for remote 376 management 378 - the security information that is necessary for the CE device to 379 establish and maintain Security Associations with its peer CE 380 devices belonging to the same VPN; section 3.3 defines which is 381 the minimal set of information a CE device should be able to 382 retrieve/receive from the SP's VPN management server. 384 3.2 Pre-configuration of the CE device 386 This document uses the term "pre-configuration" for the initial 387 provisioning of a CE device. This pre-configuration happens before a 388 CE is attached to a VPN (before the considered site actively belongs 389 to the VPN). This pre-configuration can be performed by the SP before 390 shipping the CE device to the customer's premises. Alternatively, 391 some of the information can be auto-configured via for example DHCP 392 or the SP can pre-provision the CE device manually at the customer's 393 premises. Another possibility is for the SP to tell the customer how 394 to pre-provision its CE device. Finally other scenarios such as 395 remote management with for example secured SNMP are also possible. 397 Every CE device participating in a VPN needs to be pre-provisioned 398 with the necessary configuration information that enables it to 399 establish a secure communication path with the SP's VPN server. 401 The CE device must be configured with the IP address (s) of the 402 Service Provider's VPN server or with a URL to the required CE's 403 VPN information on the Service Provider's VPN database. 405 The CE device must be configured with the security information 406 required by the SP's secure remote management protocol (stack). 408 And finally, the CE device must be provided with the CE's IP address 409 (s) in the SP's space. 411 As mentioned before, the CE device is identified by an IP address (s) 412 that belongs to the Service Provider's routing space. This IP address 413 (s) may be an IP address assigned by the SP and manually configured 414 on the CE device, together with the other (pre-) configuration 415 information (this would require this IP address (s) to be configured 416 as a static route on the attached PE too). Alternatively, the CE may 417 dynamically obtain this IP address (s), using for example DHCP or 418 IPCP over the CE-PE link. Yet another possibility is that the CE 419 device has obtained a (global) IP address (s) from an ISP, and that 420 the VPN customer communicates this IP address (s) to the VPN Service 421 Provider. Note that the CE device needs to maintain this same IP 422 address (s) at least for the duration of its VPN membership. 424 Note that other information, such as timer-parameters etc. may be 425 configurable by the SP. These parameters can be provisioned by the SP 426 at pre-configuration time. 428 3.3 Fetching the VPN configuration information 430 The VPN service is initialized by the CE device by retrieving the VPN 431 configuration information from the SP's VPN database using the 432 appropriate secure remote configuration channel. 434 The CE device will retrieve from the SP's VPN server the information 435 that is necessary to establish IPsec-secured tunnels with the other 436 CE devices that belong to the same VPN (and to which it should 437 establish a virtual VPN link - depending on the VPN topology). The SP 438 may choose to let the CE devices authenticate the IKE negotiations 439 between CE devices using (i) pre-shared keys or (ii) digital 440 signatures and certificates. The IPsec implementation on the CE 441 devices should support both modes of authentication. 443 (i) in case of pre-shared keys, the following information is to be 444 retrieved from the SP's VPN server: 446 - a list of tuplets 449 (SA information = the necessary information to negotiate a SA 450 with the peer CE: security protocol, Diffie-Hellman group, 451 IPsec transforms, etc. The (optional) presence of this 452 information will overwrite possible default values in the CE) 454 (tunnel information : traffic-driven tunnel or 'permanent' 455 tunnel; tunnel mode IPsec or transport mode IPsec over an IP- 456 in-IP encapsulation; dynamic routing trough the tunnel or not) 458 (ii) in case of digital signature authentication, the following 459 information is to be retrieved from the SP's VPN server: 461 - a pair 463 - a certificate for the public key 465 - a public key from the Certificate Authority 467 - a list of tuplets 470 The above information is maintained on the SP's VPN server, and sent 471 to the CE device when necessary. 473 3.4 Establishing the (secure) VPN tunnels/SAs 475 When one Site sends traffic to another Site belonging to the same 476 VPN, these IP packets will be secured via IPsec. This means that an 477 IPsec Security Association is needed between each pair of sites that 478 directly exchange private VPN data with each other. 480 The Internet Key Exchange protocol (IKE, [IKE]) or its successor 481 IKEv2 [IKEv2] will be used for the purpose of automatic setup of 482 security associations between VPN sites within the same VPN. The CE 483 devices will use the information that they have retrieved (or 484 received) from the SP's VPN server to negotiate SAs with their peers, 485 using IKE(v2). 487 The successful establishment of such a 'VPN' IPsec SA between two CEs 488 will result in the auto-configuration of a new VPN tunnel (or virtual 489 link) between the two considered CE devices. 491 As explained in section 5 of this memo, a 'VPN tunnel' is either an 492 IP-in-IP tunnel protected by an IPsec transport mode SA or 493 alternatively a tunnel mode IPsec SA. In both cases, the VPN tunnel 494 is established once the protecting SA is established. 496 These dynamically established SAs can be set-up and maintained 497 independently of the presence of actual inter-site user traffic, 498 resulting in 'permanent' IPsec tunnels. These tunnels are then always 499 available and not traffic-triggered. It is then required to 500 frequently re-negotiate the SA (via IKE(v2)) before the IPsec timers 501 of the connection time out. The set-up of a 'permanent' IPsec tunnel 502 will be triggered by the configuration of a new peer CE device within 503 the same VPN. An advantage of this method is that the IPsec tunnel is 504 always available, and that eventual traffic does not encounter an 505 extra delay due to the setup time of a new SA. The use of 'permanent' 506 IPsec tunnels is recommended for CE-based site-to-site VPNs. 508 A CE device that first joins a VPN must retrieve the initial VPN 509 configuration information from the SP's VPN server. Next, for 510 'permanent' IPsec tunnels, the considered CE subsequently establishes 511 "VPN tunnel SAs" (using IKE) with every peer CE device listed in the 512 VPN configuration information. 514 o if the IKE negotiation is accepted and authentication succeeds, 515 the SA is successfully established. 517 o if the IKE negotiation is refused or the authentication fails, 518 the IKE negotiation will be stopped and the SA not be established; 519 the CE device will then wait for a time interval larger than a 520 certain minimum value (to be configured, depending on e.g. the 521 responsiveness of the auto-discovery mechanism) and then try 522 negotiating the SA with the considered peer again. After a new 523 failure, the CE device will retry after a certain period of time 524 (t1, to be configured). This process continues with exponential 525 backoff of t1 until a certain limit (to be configured) upon which 526 an alarm will trigger human interaction. 528 Provider provisioned CE-based IPsec VPNs as described by this 529 document use 'permanent' IPsec Security Associations when dynamic 530 routing through IPsec-secured tunnels is used. 532 Alternatively, the IPsec SA setup can be triggered by the effective 533 (data) traffic flow going from one site to another. In this case, the 534 arrival of data packets at the CE device, coming from within the VPN 535 site and going to another VPN site, will be noticed by the CE's IPsec 536 or routing database, and an IKE exchange will be initiated to set up 537 an IPsec secured connection between both parties. Once the secure 538 tunnel is set up, the data packets can flow from one site to the 539 other in a secure way. When no traffic flows for a certain duration 540 of time, the secure tunnel will be torn down again. An advantage of 541 this method is that an IPsec tunnel is only to be maintained when 542 there is effectively traffic flowing. A disadvantage is the extra 543 delay introduced for the traffic during IKE signaling and the 544 potentially large amount of data traffic that might need to be 545 buffered or dropped during tunnel establishment for high-speed 546 connections. Another disadvantage is the difficult interaction with 547 the tunneled inter-site VPN routing information distribution. 549 Provider provisioned CE-based IPsec VPNs as described by this 550 document could use traffic-driven IPsec SA establishment when static 551 intra VPN inter-site routing is used (no dynamic routing through the 552 IPsec tunnels), see section 4.3. Provider provisioned CE-based IPsec 553 VPNs as described by this document don't use traffic-driven IPsec SA 554 establishment when dynamic site-to-site routing through the IPsec- 555 secured tunnels is used. 557 The CE configuration determines whether traffic-driven SA 558 establishment is used or not, and whether dynamic routing through 559 IPsec tunnels is used or not. 561 The procedures described in this memo can be used together with 562 [IPSEC-DPD] that offers a mechanism to efficiently keep IPsec SAs 563 alive. 565 Note that IPsec tunnels are unidirectional in nature, but that within 566 the application of this document, the set-up of one direction is 567 accompanied by the set-up of the reverse direction IPsec tunnel. 569 This document describes two possible ways to use IPsec in CE-based 570 VPN scenarios (see section 5): in 'transport mode' or in 'tunnel 571 mode'. The CE configuration, IKE exchange and resulting SA's specify 572 which mode will be used. 574 Note that the number of peer CE devices with which a specific CE 575 device must have an IPsec connection to secure the data traffic, is 576 dependent on the specific 'role' of the site in the considered VPN. A 577 hub CE will for example have a larger number of tunnels to support 578 than a spoke device. 580 3.5 Updating VPN configuration information 582 An important requirement for the scalability of L3VPNs is the 583 availability of an 'auto-discovery' mechanism. Such an 'auto- 584 discovery' mechanism should for example make sure that the 585 addition/deletion of a VPN site to/from an existing VPN is possible 586 by only configuring the 'new' CE device (and the SP's VPN database): 587 the existing VPN sites should automatically 'discover' the new site 588 in a reliable and secure manner. 590 The precise auto-discovery mechanism and related protocol actions 591 will highly depend on the remote management protocol in use. As such 592 this document does not describe a specific auto-discovery mechanism, 593 and the principles of this document remain applicable with any auto- 594 discovery mechanism. 596 The remote management protocol can operate in a 'push' model (when a 597 new CE device is added to the VPN, the VPN server pushes the new VPN 598 configuration information to all existing CE devices from that VPN), 599 in a 'pull' model (CE devices periodically download their VPN 600 configuration information from the SP's VPN server, or when receiving 601 tunnel establishment requests from unknown CE devices), or in a 602 combined mode (the SP's VPN server sends a 'notification' to the CE 603 devices that tells them to update their VPN configuration information 604 by downloading it from the VPN server). The different modes and the 605 applied protocol dynamics will have different reliability 606 characteristics. 608 3.6 Removing an existing VPN site 610 When the VPN customer wants to remove an existing site from a certain 611 VPN, this customer first informs the VPN SP. The SP will then update 612 the VPN database on the centralized server. 614 Different approaches can then be used. The SP can provision the 615 considered CE device to delete its VPN information and to tear-down 616 the IPsec SA's using IKE(v2). After completion of the IKE tear-down 617 process, the peering CE devices should not attempt to re-establish 618 the deleted SA. At this stage, the VPN tunnels are actually removed, 619 and the routing protocols operating through the tunnels in the VPN's 620 routing space will notice the topology change and react 621 appropriately. The periodical retrieval of the VPN configuration 622 information from the VPN database by the other CE devices will then 623 make sure that the removed CE's information is no longer available. 624 The discussed provisioning action can happen in the same way as the 625 pre-provisioning action described in section 3.1, i.e. via manual 626 configuration, via remote management or via interaction with the 627 customer. 629 Alternatively, the SP will not provision the to-be-removed CE 630 individually but the removal of the information relevant to the 631 considered CE from the VPN database will ultimately automatically 632 result in the removal of the CE from the VPN: peer CEs will notice 633 the removal of the particular CE from their updated configuration 634 file and will tear-down the appropriate SA using IKE(v2); the 635 deletion of active SAs will effectively remove the VPN tunnels and 636 the routing protocols running through the VPN tunnels will discover 637 the topology changes and react accordingly. The to-be-removed CE will 638 not be able to retrieve VPN information from the VPN database and 639 will delete all its VPN information and try to tear-down the 640 remaining SAs. 642 4. Exchanging and maintaining VPN routes 644 One of the requirements for PP CE-based VPNs is that dynamic routing 645 is not only supported within individual VPN sites, but also between 646 the different VPN sites of a specific VPN. This means that when a 647 change in the routing information in a specific site occurs, the 648 other sites that belong to the same VPN must be notified of that 649 change. 651 This section deals with the exchange of routing information in the 652 customer VPN's routing space (v). As depicted in figure 4, this 653 exchange of routing information happens over the VPN tunnels and is 654 as such transparent for the SP's network. CE devices don't leak VPN 655 routes into the SP's network and don't leak routes from the SP's 656 routing space into the VPN sites, unless explicitly configured to do 657 so (as e.g. explained in section 6 of this document). 659 routing adjacency (VPN space) 660 ______________________________________________________ 661 CE_1 | | CE_2 662 -------|----------------- ---------------|------- 663 | _____V____ === |I| | | |I| === ____V_____ | 664 | |routing/ |=======|P|==|===== VPN tunnel ===|=|P|======|routing/ | | 665 | |forwarding| === |s| | | |s| === |forwarding| | 666 | |VPN space | === |e| |-- PE - core - PE --| |e| === |VPN space | | 667 | ---------- =====|c|==|= | |c| = = ---------- | 668 | IP-in-IP | || | IPinIP | 669 |_________________________| == to CE_3 ----------------------- 671 --- VPN space ---><--------- SP's routing space ------><-- VPN space -- 673 figure 4: tunneled routing adjacency in the VPN routing space 675 This document assumes that the routing within a VPN site is 676 controlled by the VPN customer. 678 4.1 The CE device and VPN routing 680 On the customer network side, a CE router connects to internal 681 networks of an enterprise, where one or more subnets can reside. Many 682 times, the CE router may interact with another internal router. And 683 sometimes, "backdoor links" between routers of different sites of the 684 same VPN exist. 686 In the VPN routing space (v), the CE is involved in (i) the intra- 687 site routing, (ii) the VPN tunnel termination, and (iii) the inter- 688 site VPN routing. 690 The CE device could be an integrated device providing both routing 691 and IPsec tunnel termination. Sometimes, a dedicated VPN terminator 692 may be used. Implementations in which the VPN tunnel terminator 693 resides on a firewall are also very common. For the sake of 694 simplicity, we assume that the CE router is an integrated device that 695 participates in the intra-site routing (e.g. via an IGP) and at the 696 same time terminates VPN tunnels. 698 In the context of this document, the routing aspects within a VPN 699 site (intra-site routing information distribution) are controlled by 700 the VPN customer. 702 As was explained earlier, the SP's dynamic VPN discovery scheme and 703 tunnel establishment mechanism provides the CE device with secure 704 (virtual) links towards other CE devices in the same VPN. Whether the 705 intra-VPN inter-site routing aspects that make use of these virtual 706 links are managed by the customer or by the SP is dependent on the 707 service contract. In many situations, the SP will configure the 708 necessary routing protocol information at pre-configuration time (see 709 section 3.1), in close collaboration with the customer. 711 An important requirement for the routing protocol implementation that 712 is configured to exchange reachability information through the 713 inter-site tunnels, is that it must be able to autonomously deal with 714 dynamically created new inter-site links. 716 4.2 IPsec and routing 718 IPsec is a layer 3 security protocol, which operates purely at the IP 719 layer and which is defined by a number of IETF standards ([IPSEC], 720 [RFC2402], [RFC2406], [RFC2407], [RFC2408], [IKE], [IKEv2], etc.). 721 The interaction between IPsec and layer 3 routing is not always 722 straightforward and has been described in [TOUCH]. Depending on 723 individual implementations, difficulty may arise when an IPsec user 724 wants to support robust routing across IPsec-interconnected VPNs 725 sites. 727 4.3 Exchanging VPN routes between VPN sites 729 In the proposed mechanism to exchange VPN reachability information 730 between VPN sites, routing protocol messages are tunneled through the 731 IPsec-secured tunnels between peering sites. The CE-to-CE IPsec- 732 secured tunnels between VPN sites are then being seen as point-to- 733 point links by the customer networks and are interpreted as such by 734 the routing protocol functions of the CE devices. This means that 735 when a change in the reachability occurs in one particular site, a 736 routing protocol (such as RIP, OSPF, etc.) will take care of the 737 distribution of the new reachability information within the site, but 738 also to all other sites, through the VPN tunnels that the considered 739 CE is possibly maintaining. 741 As the described architecture allows for the dynamic creation of 742 inter-site (IPsec-protected) VPN links, the routing protocol 743 implementation(s) operating on the CE device must be able to support 744 this. 746 Although very often it will be the SP's responsibility to configure 747 the CE's routing information at pre-configuration time, the service 748 agreement may specify that routing on the CE device falls under the 749 customer's management. 751 The IPsec tunnels through which routing messages are exchanged may be 752 implemented using IPsec tunnel mode or using IPsec transport mode 753 (see section 5). Note that the same tunnels are used for exchanging 754 intra-VPN inter-site routing messages as for exchanging VPN user data 755 traffic. 757 There are significant issues when a traffic-driven tunnel 758 establishment mechanism is used at the same time as an approach 759 whereby a routing protocol (with a keep-alive mechanism) runs on top 760 of the VPN tunnel. In this case the delay introduced by the tunnel 761 establishment phase could lead to a loss of routing updates and the 762 routing protocol's keep-alive mechanism could interact with the 763 tunnel establishment in an undesired way. For example the frequency 764 with which dynamic routing protocols typically exchange Hello 765 messages makes it undesirable to re-establish tunnels for each Hello 766 packet. Therefore, when dynamic routing is used through IPsec-secured 767 CE-to-CE tunnels, traffic-driven SA establishment should not be used. 769 5. Tunneling IP traffic (user data) among VPN sites 771 This section describes the processes that an IP packet that is sent 772 from one VPN site to another will go through. This is depending on 773 the way that IPsec is used. This document describes two possible ways 774 to use IPsec in CE-based VPN implementations: IPsec in tunnel mode, 775 and IPsec in transport mode. 777 An IP packet that is sent by an IP device in a certain site and 778 destined for an IP device in another site belonging to the same VPN, 779 will be forwarded as follows. 781 The device in the sending site sends an IP packet (possibly using a 782 private address space) on its LAN network. The next hop for this 783 destination IP address will (at some point in time) be the site's CE 784 device (according to the routing/forwarding in the VPN site). The 785 processing by the CE device now is dependent on the implemented mode 786 for IPsec. 788 Note that the following description is not meant to specify an 789 implementation strategy; any implementation procedure which produces 790 the same results is acceptable. 792 o IPsec in transport mode (see also [TOUCH] for a detailed 793 specification) 795 When IPsec is used in transport mode in this context, the CE 796 device first analyzes the private IP packets arriving from within 797 the site and select the appropriate outgoing interface and 798 required encapsulation, based on the VPN routing/forwarding 799 information. For a destination located in another site, the 800 outgoing interface will be a virtual interface (a VPN tunnel) and 801 the required encapsulation will be IP-in-IP, using the considered 802 CE's IP address (s) as the source address in the outer IP 803 encapsulation header and a peer CE's IP address (s) in the outer 804 IP encapsulation header's destination address field. The CE device 805 then processes this new IP packet to its IPsec driver. 807 The IPsec driver in the CE device then does the following: 809 - analyze the IP packets that have been IP-in-IP encapsulated and 810 select the appropriate SA (based on the packet's outer header 811 destination address (s)). 813 - authenticate and/or encrypt the private IP packet according to 814 the (transport mode-specific) rules described in the SA and insert 815 an appropriate IPsec header (according to IPsec in transport 816 mode). 818 o IPsec in tunnel mode 820 When IPsec is used in tunnel mode in this context, the IPsec 821 driver in the CE device does the following: 823 - analyze the private IP packets arriving from within the site and 824 select/setup an appropriate SA with the appropriate destination CE 825 device. 827 - authenticate and/or encrypt the private IP packet according to 828 the (tunnel mode-specific) rules described in the SA, AND 829 encapsulate the packet in an IPsec header AND encapsulate the 830 packet in a new 'outer' IP header. This 'outer' IP header has the 831 CE's non-private (i.e. routable in the SP's realm) IP address in 832 the source IP address field and the destination CE's non-private 833 (i.e. routable in the SP's realm) IP address in the destination IP 834 address field. 836 The CE device then sends the IPsec packet to the PE device, and the 837 IPsec packet will then be forwarded using 'normal' IP forwarding 838 across the SP's network, based on the outer header's IP destination 839 address (s), that is the destination CE's 'global' (i.e. routable in 840 the SP's realm) IP address. The packet will be forwarded to the 841 egress PE who will also only examine the outer IP header and send the 842 IP(sec) packet to the destined CE device. The egress CE device will 843 recognize itself as the destination node (the IP packet has the CE's 844 IP address (s) in the outer IP destination address field) and process 845 the IPsec packet to the IPsec driver that will then, based on the 846 appropriate Security Association (identified by the packet's SPI 847 field in the IPsec header), perform IPsec authentication and/or 848 decryption. Dependent on whether tunnel mode or transport mode IPsec 849 is used, the packet will be decapsulated by the IPsec driver itself 850 or sent to the IP-in-IP decapsulation function. The resulting 851 (private) IP packet (v) will then be further processed in the CE's 852 VPN IP forwarding table and send on the LAN network to the 853 appropriate next hop router or destination IP device. 855 Note that IPsec tunnels might unintentionally terminate or break. For 856 example, the CE device on one end point of an IPsec tunnel might 857 fail, or one end point might become unreachable from the other end 858 due to a failure of IP routing in the intermediate infrastructure. 859 When dynamic routing is not supported through the inter-site VPN 860 tunnels, this may have serious consequences if VPN membership and VPN 861 routing information are not changed accordingly within the VPN. 862 Indeed, where static routing is used the unnoticed termination of a 863 VPN tunnel can result in the creation of black holes. 865 This means that a mechanism must exist to monitor the state of the 866 VPN tunnels. When dynamic inter-site VPN routing is used, the routing 867 protocol that runs on top of the IPsec VPN tunnels will serve that 868 purpose. When dynamic inter-site routing is not used, alternatives 869 are possible such as the use of an IPsec-specific keep-alive 870 mechanism [IPSEC-DPD] or a SP-proprietary mechanism. 872 6. CE-based VPN and Internet 874 6.1 Allowing both VPN connectivity and Internet connectivity 876 In many VPNs, sites will need to both access the public Internet as 877 well as to access other sites within the same VPN. 879 In order to achieve this, some sites within the VPN will obtain 880 Internet Access by means of an "Internet Gateway" that is attached 881 via one of its interfaces to an ISP's PE device. Such an Internet 882 Gateway may for example be a firewall and may or may not need to 883 implement network address translation functions. The ISP may be the 884 same SP that offers the VPN service, or it may be a different SP. The 885 PE to which the Internet Gateway is connected may be the same PE to 886 which the CE is connected or it may be another PE. 888 The Internet Gateway may be a separate device, or alternatively the 889 Internet Gateway functions may be integrated into the CE device. When 890 the Internet Gateway functions are integrated into the CE device, the 891 CE-PE interface used by the Internet Gateway functions may be the 892 same or a different interface than the interface used by the VPN 893 tunnels. In further discussions, we'll assume that the Internet 894 Gateway is a separate device. 896 The service contract will define whether the Internet Gateway will be 897 managed by the SP or by the VPN customer. 899 Note that when Internet Access is offered within a VPN, the address 900 spaces used within the VPN must be non-overlapping. This means that 901 the VPN either uses global addresses that have been assigned to the 902 VPN customer, or private addressing in combination with NAT [NAT]. 904 The sites that have Internet Access via an Internet Gateway will have 905 a default route (v) pointing to their Internet Gateway and may be 906 distributing a default route via their CE towards the other CEs of 907 the same VPN through the VPN tunnels. This provides Internet Access 908 for all the VPN sites. Note that other sites (that don't have their 909 own Internet Gateway) must not distribute default routes in this 910 scenario. A site that has distributed a default route to other sites 911 for Internet Access should have either a default route to its 912 Internet Gateway or Internet routes (leading to its Internet Gateway) 913 in its forwarding table (of the VPN routing space). 915 VPN site <---- : 916 : 917 ---------- to Internet : 918 _____| Internet |----------------:-- PE_2 919 | | Gateway | : 920 | ---------- : 921 --------|--------------------------- : 922 | default | : 923 | route to | : 924 | _____|______ | : 925 | | | ===== CE2 |I| | : 926 ----|--|routing and | ===== CE3 |P| | : 927 | |forwarding | ===== CE4 |s| -->|-----:-- PE_1 928 ----|--|in VPN space| ===== CE5 |e| | : 929 | ------------ = = = |c| | : 930 | IP-in-IP | : 931 |______CE device_____________________| : 932 <--- : 933 intra : 934 site : 935 : 936 figure 5: Internet Access from within a VPN 938 The Internet Gateway will process (e.g. firewall) all traffic coming 939 from within the VPN and, if accepted, send it to the PE with which it 940 interfaces. As such the Internet Gateway effectively is the device 941 that interfaces between the VPN routing space and the SP's/Internet 942 routing space. Note that traffic that leaves a VPN via an Internet 943 Gateway will not be IP-in-IP encapsulated and will not be IPsec 944 processed. The traffic coming from the gateway will then be forwarded 945 according to the PE's (default/Internet) forwarding table. 947 In order to allow for traffic in the reverse direction (from the 948 Internet to the VPN sites), the ISP connected to the Internet Gateway 949 must distribute, to the Internet, routes that lead to addresses that 950 are within the VPN. NAT-like techniques are also sometimes used. As 951 such there will be routes that will lead from the Internet to the 952 site's Internet Gateway. The Internet Gateway will process traffic 953 coming from the Internet and, if accepted (based on local policies), 954 send it into the VPN site where intra-VPN routing and forwarding will 955 lead the packets to their destination. This distribution of routes 956 that lead to addresses within the VPN towards the Internet is 957 independent of any intra-VPN route distribution as described 958 elsewhere within this specification. Note also that normally the 959 internal structure of the VPN will remain invisible to the outside 960 world. 962 When the Internet Gateway functions are implemented in the CE device 963 and the CE device is attached via only one (sub-)interface towards 964 only one PE device, inspection of the packets coming from the PE will 965 indicate whether the concerned traffic is intra-VPN traffic (when the 966 packet is an IPsec packet with the CE device's own IP address (s) in 967 the outer header's destination address field and the encapsulated 968 payload is an IP-in-IP encapsulated private IP packet (v), and a 969 matching SA is found), or control-plane traffic (IKE(v2) or VPN 970 remote management traffic: when the inspected packets conform to the 971 control plane's policies), or VPN <--> Internet traffic (then the 972 Internet Gateway function will decide whether the considered packets 973 will be accepted, (translated), and forwarded or not). 975 In the above discussed procedures, some sites will access the 976 Internet via a VPN tunnel that leads to another site of the same VPN, 977 because they don't have an own Internet Gateway, and will forward the 978 traffic according to the default route. Ultimately though, Internet 979 traffic will always go via an Internet Gateway before 980 entering/leaving a VPN. 982 Further note that the PE to which the Internet Gateway is attached 983 doesn't necessarily need to carry all the Internet routes; a default 984 route to another Internet router suffices. 986 6.2 Prohibiting or restricting Internet connectivity from within a CE- 987 based VPN 989 In the approach described in this document, the CE device sends IP 990 packets (s) to the VPN-unaware PE device and receives IP packets from 991 that PE device. The PE device forwards these packets based on the IP 992 addresses (s) in the (outer) IP header. The packets received by the 993 PE are as such either packets that are routable within the SP's 994 private scope, or either in the public Internet's scope. This section 995 discusses the implications hereof with regards to security and access 996 control. 998 o traffic that the CE sends to the PE 1000 Following the procedures described in this document, three types 1001 of 'VPN' traffic can be sent by the CE device towards the PE 1002 device: 1004 (i) customer VPN traffic: intra-VPN traffic sent from one VPN site 1005 to another VPN site; these packets will always have the sending 1006 CE's IP address (s) in the IP header's source IP address field, 1007 the IP address (s) of a peer CE device of the same VPN in the IP 1008 header's destination IP address field, and will always contain an 1009 IPsec header; 1011 (ii) secure remote management traffic: this comprises both the 1012 traffic to establish the secure management channel (e.g. IPsec or 1013 secure TLS) and the traffic to download the VPN configuration 1014 file; these packets will always have the CE's IP address (s) in 1015 the IP header's source IP address field; 1017 (iii) IKE(v2) traffic: the IP packets sent between CE devices in 1018 order to establish SAs; these packets will always have the CE's IP 1019 address (s) in the IP header's source IP address field. 1021 o traffic that the CE receives from the PE 1023 Following the procedures described in this document, the same 1024 three types of traffic can be received by the CE device from the 1025 PE device. As such, the CE device should perform the following 1026 actions: 1028 + for IP packets that have the CE's own IP address (s) in the 1029 outer IP header's destination address field and that have an IPsec 1030 header: process the packets through the CE router's IPsec daemon 1031 where conformance with an existing SA will be checked, and the 1032 packets further processed; 1034 + for IKE(v2) packets that have the CE's own IP address (s) in the 1035 outer IP header's destination address field: process according to 1036 the tunnel establishment procedures described in this 1037 specification; 1039 + for IP packets that have the CE's own IP address (s) in the 1040 outer IP header's destination address field and that correspond to 1041 secured management traffic: process according to the VPN secure 1042 remote management procedures, which will depend on the used 1043 management protocols; 1045 + for CE devices that have an integrated Internet Gateway role: 1046 process all other packets to the Internet Gateway module; 1048 + for CE devices that don't have an integrated Internet Gateway 1049 role: drop all other IP packets, unless explicitly allowed by 1050 complementary procedures that are out of scope of this memo. 1052 o SP's control over CE initiated traffic 1054 Note that with this specification's concepts, the PE device that 1055 receives traffic from a CE device has no means to verify whether 1056 the received traffic is intra-VPN traffic, or traffic that is sent 1057 to for example another VPN or e.g. to the Internet. 1059 From a VPN data privacy point of view, this has no implications, 1060 as the security is enforced at the CE devices themselves: traffic 1061 that doesn't conform to the security associations or other policy 1062 rules will be dropped at the CE. 1064 One remaining issue is that customers might use CE devices (that 1065 have been granted VPN access) to access services they have not 1066 been granted access for, via the PE device. Although this would 1067 possibly compromise the security of the customer's own VPN, the SP 1068 may want to deploy measures to prevent this without bringing full 1069 VPN knowledge to the PE. One way of doing this would be by using 1070 specific IP address ranges for VPN purposes and to have specific 1071 access lists configured on the PE devices (this has inter-SP and 1072 Internet transparency issues though). Note that maintaining, at 1073 every PE, a list of would add a 1074 considerable management burden and is as such not advised. Another 1075 strategy for the SP would be not to care about the particularities 1076 of the traffic and treat it at the PE level as it treats public 1077 Internet traffic (and as such to only control the total of the 1078 resources consumed by particular access connections). 1080 Taking into consideration that in many cases, VPNs will also need 1081 to be able to access the public Internet, and that the above 1082 problem does not seem to be an important threat for the SP nor the 1083 VPN customer, this issue is not considered as a major drawback for 1084 the deployment of the discussed VPN approach. 1086 7. Security Considerations 1088 The security aspects of what is presented in this document are 1089 implicitly discussed in most of the sections. This draft is for a 1090 large part focusing on security aspects. 1092 Note that the security of the mechanisms presented here is highly 1093 dependent on the following factors: 1095 - the security of the 'management channel', used by the management 1096 protocol to configure the VPN CE devices. 1098 - the security of the site and of the CE-device itself 1100 - the security aspects of the credentials: the IPsec credential 1101 must be generated, provisioned, updated, and stored securely 1103 - for a VPN with a complex topology, every tunnel must use the 1104 same grade of security strength, otherwise, a single weak link 1105 degrades the whole VPN 1107 A more detailed analysis of the security aspects of CE-based 1108 PPVPNs is described in [RFC4111]. 1110 8. IANA Considerations 1112 This document has no actions for IANA. 1114 9. Acknowledgements 1116 The authors would like to thank the following persons for their 1117 valuable contributions to this document: Lars Eggert, Brian Gleeson, 1118 Archana Khetan, Sankar Ramamoorthi, Eric Rosen, Michael Choung Shieh, 1119 Joe Touch, Eric Vyncke, S. Felix Wu, Yu-Shun Wang, Cliff Wang, Alex 1120 Zinin. 1122 10. Informative References 1124 [FRAMEWORK] Callon, R. et al., "A Framework for Provider Provisioned 1125 Virtual Private Networks", RFC 4110, July 2005 1127 [GRE] Farinacci, D. et al., "Generic Route Encapsulation", March 1128 2000, RFC 2784 1130 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", 1131 November 1998, RFC 2409 1133 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol, draft- 1134 ietf-ipsec-ikev2, work in progress 1136 [IPinIP] Perkins, C., "IP encapsulation within IP", October 1996, RFC 1137 2003 1139 [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the 1140 Internet Protocol", November 1998, RFC 2401 1142 [IPSEC-DPD] Huang, G., Beaulieu, S., Rochefort, D., "A Traffic-Based 1143 Method of Detecting Dead IKE Peers", February 2004, RFC 3706 1145 [L2TP] Lau, J., et al., "Layer Two Tunneling Protocol (Version 3)", 1146 March 2005, RFC 3931 1148 [NAT] Srisuresh, P., Egevang, K., "Traditional IP Network Address 1149 Translator (Traditional NAT)", January 2001, RFC 3022 1151 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", 1152 November 1998, RFC 2402 1154 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 1155 (ESP)", November 1998, RFC 2406 1157 [RFC2407] Piper, D., "The Internet IP Security Domain of 1158 Interpretation for ISAKMP" November 1998, RFC 2407 1160 [RFC2408] Maughan, D., et al., "Internet Security Association and Key 1161 Management Protocol (ISAKMP)", November 1998, RFC 2408 1163 [TOUCH] Touch, J. and Eggert, L., "Use of IPSEC transport mode for 1164 Dynamic Routing", September 2004, RFC 3884 1166 [RFC4111] Fang, L., "Security Framework for Provider-Provisioned 1167 Virtual Private Networks (PPVPNs)", July 2005, RFC 4111 1169 11. Authors' Addresses 1171 Jeremy De Clercq 1172 Alcatel 1173 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 1174 E-mail: jeremy.de_clercq@alcatel.be 1176 Olivier Paridaens 1177 Alcatel 1178 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 1179 E-mail: olivier.paridaens@alcatel.be 1181 Cliff Wang 1182 E-mail: cliff.wang@us.army.mil 1184 Intellectual Property Statement 1185 The IETF takes no position regarding the validity or scope of any 1186 Intellectual Property Rights or other rights that might be claimed to 1187 pertain to the implementation or use of the technology described in 1188 this document or the extent to which any license under such rights 1189 might or might not be available; nor does it represent that it has 1190 made any independent effort to identify any such rights. Information 1191 on the procedures with respect to rights in RFC documents can be 1192 found in BCP 78 and BCP 79. 1194 Copies of IPR disclosures made to the IETF Secretariat and any 1195 assurances of licenses to be made available, or the result of an 1196 attempt made to obtain a general license or permission for the use of 1197 such proprietary rights by implementers or users of this 1198 specification can be obtained from the IETF on-line IPR repository at 1199 http://www.ietf.org/ipr. 1201 The IETF invites any interested party to bring to its attention any 1202 copyrights, patents or patent applications, or other proprietary 1203 rights that may cover technology that may be required to implement 1204 this standard. Please address the information to the IETF at 1205 ietf-ipr@ietf.org. 1207 Full Copyright Statement 1209 Copyright (C) The Internet Society (2005). 1211 This document is subject to the rights, licenses and 1212 restrictions contained in BCP 78, and except as set forth therein, 1213 the authors retain all their rights. 1215 Disclaimer of Validity 1217 This document and the information contained herein are provided on an 1218 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1219 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1220 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1221 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1222 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1223 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.