Network Working Group Jeremy De Clercq INTERNET DRAFT Cheng-Yin Lee Alcatel Paul Knight Nortel Networks February 2003 Expires August, 2003 Provider Provisioned CE-based Virtual Private Network solution using IPsec and HTTP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document describes the procedures for a Service Provider to offer Virtual Private Network Services to its customers by provisioning the CE devices on behalf of the customer. The IPsec technology is used to protect the customer traffic, and the HTTP protocol is used to autodiscover the CEs' VPN configuration information. De Clercq et al. Expires August 2003 [Page 1] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 Table of Contents 0. Sub-IP Area Section ......................................... 2 1. Introduction ................................................ 3 2. Reference Model ............................................. 4 2.1 Entities in the Reference Model ............................. 5 2.2 IP Connectivity between CE and PE devices ................... 7 2.3 Assumed Service Provider's Infrastructure ................... 8 3. Configuring the CE-based VPN ................................ 9 3.1 Pre-configuration of the CE device .......................... 9 3.1.1 Initializing the secure provisioning channel ................ 10 3.1.2 The CE's IP address in the SP's space ....................... 11 3.1.3 Other information ........................................... 11 3.2 Establishing the secure provisioning channel ................ 11 3.3 Fetching the VPN configuration information .................. 12 3.4 Establishing the (secure) VPN tunnels ....................... 13 3.5 Updating the VPN configuration information .................. 15 3.6 Removing an existing VPN site ............................... 19 4. Exchanging and maintaining VPN routes ....................... 19 4.1 The CE device and VPN routing ............................... 20 4.2 IPsec and routing ........................................... 21 4.3 Exchanging VPN routes between VPN sites ..................... 21 5. Tunneling IP traffic (user data) among VPN sites ............ 22 6. CE-based VPN and Internet ................................... 24 6.1 Allowing both VPN connectivity and Internet connectivity .... 24 6.2 Prohibiting or restricting Internet connectivity from within a CE-based VPN .............................................. 27 7. Extranet functionality with PP CE-based VPNs ................ 29 8. Quality of Service .......................................... 29 9. Security Considerations ..................................... 29 10. Acknowledgements ............................................ 30 11. References .................................................. 30 12. Authors' Addresses .......................................... 31 0. SubIP-Area Section SUMMARY The PPVPN framework document [FRAMEWORK] identifies three basic provider provisioned VPN types : Provider Provisioned Network Based (or PE-based) Layer 3 VPNs, Provider Provisioned Layer 2 VPNs and Provider Provisioned CE-based VPNs. This document describes a method enabling a Service Provider to offer VPN services to its customers by provisioning the CE devices on behalf of the customer (Provider Provisioned CE-based VPNs). De Clercq et al. Expires August 2003 [Page 2] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 For a CE-based VPN to be set up under the SP's control, the VPN customer informs the Service Provider of which sites (identified by a set of CE devices) should become part of the considered VPN and what the requested topology of the VPN should look like. The SP then configures and maintains a VPN database and manages the Customer's VPN. The model proposed in this document uses the IPsec protocol suite for the purpose of securing the customer VPN traffic. When the model proposed is used, the addition of one VPN site only requires a minimum amount of configuration. This is obtained via an auto-discovery scheme using XML/HTTP. RELATED DOCUMENTS See References section (especially [TOUCH], [CE-VPN]). WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK PPVPN box. WHY IS IT TARGETED AT THIS WG This document describes a mechanism for Provider Provisioned CE-based VPNs, which is clearly identified as an item within the scope of the PPVPN WG, as stated from the following WG charter extract: "This working group is responsible for defining and specifying a limited number of sets of solutions for supporting provider-provisioned virtual private networks (PPVPNs). The work effort will include the development of a framework document, a service requirements document and several individual technical approach documents that group technologies together to specify specific VPN service offerings. The framework will define the common components and pieces that are needed to build and deploy a PPVPN. Deployment scenarios will include provider-managed VPN components located on customer premises.". JUSTIFICATION This document is justified by the fact that it defines a solution for PP CE-based VPNs, which are identified as a specific type of PPVPNs both in the WG charter and the general framework I-D. As described in the general framework I-D, PP CE-based VPNs have specific characteristics compared to Network-Based VPNs especially with regards to management and security. 1. Introduction De Clercq et al. Expires August 2003 [Page 3] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 The PPVPN framework document [FRAMEWORK] identifies three basic provider provisioned VPN types : Provider Provisioned Network Based (also termed PE-based) Layer 3 VPNs, Provider Provisioned Layer 2 VPNs and Provider Provisioned CE-based VPNs. This document describes a method enabling a Service Provider to offer VPN services to its customers by provisioning the CE devices on behalf of the customer (Provider Provisioned CE-based VPNs). For a CE-based VPN to be set up under the SP's control, the VPN customer informs the Service Provider of which sites (identified by a set of CE devices) should become part of the considered VPN and what the requested topology of the VPN should look like. The SP then configures and updates its VPN database, and then provisions and manages the Customer's VPN. The model proposed in this document uses the IPsec protocol suite for the purpose of securely tunneling the customer VPN traffic. This specification proposes the use of HTTP to retrieve the XML- formatted VPN configuration information from the SP's VPN server. 2. Reference Model The reference model upon which the mechanisms and procedures described in this document are based, is taken from the CE-based VPN reference model described in [FRAMEWORK]. The most important aspects of that framework model and the restrictions that are relevant to this document are described in this section. De Clercq et al. Expires August 2003 [Page 4] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 +---------+ +------------------------------------+ +---------+ | | | | | | | | | +------+ +------+ : +------+ +------+ : | | | | | | : | CE | | CE | : | | | P | | PE | : |device| |device| : +------+ VPN tunnel |router| |router| : | of | | of |=:====================================================:=|VPN A| |VPN A| : | | +------+ +------+ : +------+ +------+ : | PE | | | : | +------+ : |router| | | : | | CE | : | | VPN tunnel +------+ : +------+ |device|=:====================================================:=| CE | | of | : +------+ | PE | : |device| |VPN B| : | | |router| : | of | +------+ : | | +------------+ +------------+ | | : |VPN B| | : | | | Customer | | Network | +------+ : +------+ |Customer | | | management | | management | | | : | |interface| | | function | | function | | |Customer | | | | +------------+ +------------+ | |interface| | | | | | | +---------+ +------------------------------------+ +---------+ | Access | |<---------- SP network(s) --------->| | Access | | network | | | | network | Figure 1: Reference model for provider provisioned CE-based VPNs 2.1 Entities in the reference model and Terminology o Customer Edge (CE) device In the context of this solution, a CE device is a router located at the edge of a customer site, that has IP connectivity with a SP's PE device (not necessarily Internet connectivity). A CE device maintains one or more VPN tunnel endpoints. The VPN- specific functions in the CE device are provisioned by the SP. Note that other functions that are normally applied by the PE router may need to be performed by the CE device in this context (e.g. NAT functionality, QoS classification, etc.). These functions may be managed by the SP or alternatively be managed by the VPN customer, depending on the applicable service contract. The CE device may also provide general (non VPN-oriented) Internet connectivity for the customer network. Such connectivity may be achieved via the SP's PE router that provides the VPN connectivity or some other router (of the same or another SP). In such a situation, the CE device must be able to distinguish between traffic to be sent through a VPN and traffic to be sent outside De Clercq et al. Expires August 2003 [Page 5] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 any VPN. Section 6 of this document discusses this in more details. CE devices in a CE-based PPVPN model differ from CE devices in a PE-based PPVPN model in that they need to support VPN-specific functions. With CE-based PPVPNs, the VPN awareness is pushed even further towards the edges of the provider networks. o Provider Edge (PE) router In the context of Provider Provisioned CE-based VPNs, a PE router is a router, located at the edge of the Service Provider's network, that does not have any VPN-specific functionality. A PE router is attached via an access connection to one or more CE devices, and offers possibly limited or restricted IP connectivity over the access connections to these CE devices. o SP network A SP network is a network administrated by a single service provider. In the context of PP CE-based VPNs, the SP who owns the SP network can also be the VPN provider (managing the CE devices). This can lead to operational advantages. Alternatively, the SP owning the SP network may be an ISP offering Internet connectivity, while an other entity may provision the VPN service. This configuration allows for inter-SP VPN scenarios. o Access connection An access connection represents a layer 2 connectivity between a CE device and a PE router. This includes dedicated physical circuits, logical circuits (such as Frame Relay and ATM), IP tunnels (e.g., using IPsec, L2TP) and shared medium access (such as Ethernet-based access). In the context of provider provisioned CE-based VPNs, the CE device and the PE router have layer 3 connectivity over the Access Connection. o VPN tunnel A VPN tunnel is a logical link between two entities which is created by encapsulating packets within an encapsulating header for purpose of transmission between those two entities for support of VPNs. In the context of provider provisioned CE-based VPNs, a VPN tunnel is an IP tunnel (e.g., using IPsec, L2TP, GRE, IP-in- IP) between two CE devices over the SP's network. In the context of this document, a VPN tunnel is achieved using IPsec in tunnel mode or via an IP-in-IP tunnel protected by IPsec in transport mode between two CE devices. [GRE-CE] describes how to use GRE De Clercq et al. Expires August 2003 [Page 6] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 encapsulation for CE to CE tunneling in a CE-based IPsec VPN scenario. o Security Association (SA) Throughout this document, the acronym SA will be used to denote an IPsec Security Association. 2.2 IP connectivity between CE and PE devices CE devices operating in a PP CE-based VPN will operate in two independent IP routing spaces. The first routing space is the VPN routing space. Hosts and routers within the VPN will use IP addresses that belong to this VPN routing space. The CE router will participate in this VPN routing space, and will create VPN tunnels (virtual links) to be used by this VPN routing space. The second routing space is the SP's routing space. Every CE device that belongs to a PP CE-based VPN is identified by an IP address that is routable in the SP's network. This IP address may be a global IP address or a private IP address. The CE device MUST be reachable from the SP's core network via this IP address. In order to easily differentiate between these two routing spaces, this document uses the following convention: IP addresses belonging to the VPN's routing realm will be followed by a 'v' between brackets: address (v); IP addresses belonging to the service provider's routable space will be followed by a 's' between brackets: address (s). These two routing spaces may use overlapping address spaces and thus need to be kept separate in the CE devices. The way this is done is largely implementation dependent. This may be by using two separate sets of (virtual) routing and forwarding tables (figure 2). These routing tables may then run independent routing protocols. Only the CE's IP address (s) needs to be reachable in the provider's core network. This means that this approach requires only one IP address (s) per CE device to be injected in the core network. A CE device should not inject other routes into the SP's network. In many cases, this CE's IP address (s) may be an IP address assigned by the SP who owns the core network. As such, aggregate routes can be distributed by the PE devices into the core network. The CE device and the PE device may be routing protocol peers in the SP's routing space. Alternatively, a default route (s) (towards the De Clercq et al. Expires August 2003 [Page 7] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 PE) may be statically configured in the SP's routing space on the CE device, and the CE device's IP address statically configured on the PE. The CE device should not inject SP's routes (s) towards the other routers within its VPN site. Note that, when the CE device is attached to only one PE device, via only one (sub-)interface, the CE's implementation can be fairly straightforward (see figure 3). With regards to the SP routing space, the CE device then acts as a host, having only one outgoing interface. The source IP address (s) (of the _outer_ IP header) of all packets leaving the CE device MUST always be the CE's identifier, and the IP next hop will always be the PE device to which it is attached. On the CE, no routing decisions need to be performed in the provider's routing space and only one forwarding action is possible. The following figures give an overview of the routing spaces in the CE device. Note that this description is merely an example and is not meant to specify a particular implementation: every implementation that results in the same behaviour described throughout this specification is acceptable. Section 5 describes the end-to-end processing of customer data- packets in more details. CE device ---------------------------------------------------------- | ____________ ======== |I| ______________ __|__ PE_1 | |routing and | ======== |P| |routing and | / | | |forwarding | ======== |s| |forwaring in |< | | |in VPN space| ======== |e| --- |provider space| |__|__ PE_2 | | IP(v) | ======== |c| | IP(s) | | | ------------ = = = = | | -------------- | | IP(v)-in-IP(s) | |__________________________________________________________| <- - - - - - - - - - - - -><- - - - - - - - - - - - - - - - - - - - > VPN space SP space figure (2): routing spaces in the CE device De Clercq et al. Expires August 2003 [Page 8] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 ---------------------------------------------- | ____________ ========== to CE_2 |I| | | |routing and | ========== to CE_3 |P| | | |forwarding | ========== to CE_4 |s|----|--- PE | |in VPN space| ========== to CE_5 |e| | | | IP(v) | ========== to CE_6 |c| | | ------------ = = = = = | | | | IP(v)-in-IP(s) | |______________________________________________| <- - - - - - - - - - - - ><- - - - - - - - - - - - - - - -> VPN space SP space figure (3): the CE is connected to only one PE device Note that there are no routing protocols operating in both routing spaces simultaneously. Packets can only go from one routing space to the other routing space via either (IP-in-IP) tunneling or after firewall and possibly NAT processing (as described in section 6). This approach enables the CE devices to reach each other via tunnels over the SP's network, but does not prevent the interconnection of CE devices via so-called "backdoor routes". CE devices belonging to the same VPN MAY be interconnected via "backdoor routes". If "backdoor routes" are present in a certain VPN, the VPN's routing protocol metrics will dictate which routes will be used as the prefered routes for certain destinations. 2.3 Assumed Service Provider's infrastructure The service provider maintains a secured VPN database on a centralized server. One such VPN server may be used for the provisioning of many VPNs. As the number of VPNs to be provisioned grows, other servers may be deployed. As such, the scalability of no single device is dependent on the total number of VPNs. Such a VPN server needs to be able to maintain a large number of IPsec Security Associations and needs to implement the HTTP-server functions. In order to provide a reliable service, the SP may choose to deploy backup VPN database servers that it keeps synchronized with the primary server. As the SP will be responsible for provisioning the secure tunnels between the CE devices, it needs to deploy a key management system. 3. Configuring the CE-based VPN 3.1 Pre-configuration of the CE device De Clercq et al. Expires August 2003 [Page 9] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 This document uses the term "pre-configuration" for the initial provisioning of a CE device. This pre-configuration happens before a CE is attached to a VPN (before the considered site actively belongs to the VPN). This pre-configuration can be performed by the SP before shipping the CE device to the customer's premises. Alternatively, the SP can pre-provision the CE device manually at the customer's premises. Another possibility is for the SP to tell the customer how to pre-provision its CE device. Finally other scenarios such as remote management with for example SNMP are also possible. 3.1.1 Initializing the secure provisioning channel Every CE device participating in a VPN needs to be (pre-)provisioned with the necessary configuration information that enables it to establish a secure communication path with the SP's VPN server. This document proposes two alternative approaches for the establishment of a secure provisioning channel: (i) IPsec-secured or (ii) HTTPs- secured. The CE device must be configured with the IP address (s) of the Service Provider's VPN server and with the path to the CE's VPN information on the SP's VPN server or with the complete URL to the required CE's VPN information. (i) for an IPsec-secured provisioning channel, the CE device must be (pre-)provisioned with the necessary information to be able to establish a Security Association with the SP's VPN database using IKE (or IKEv2). First, the selectors need to be configured. These selectors define that the resulting transport mode SA will be used to protect HTTP traffic between two well-known nodes (that can be viewed as 'hosts' from an IPsec perspective): the CE, identified by its IP address (s); and the SP's VPN server, identified by its IP address (s) that is known by the CE. For both pre-shared key authentication and digital signature authentication, the following information needs to be pre- provisioned to enable the IKE phase one and phase two negotiation: the type of protection (AH, ESP, ...); IPsec transforms (prefered encryption and hash algorithms); the authentication method; information about a group over which to do a Diffie-Hellman exchange; (optionally) a pseudo-random function to hash certain values during the key exchange proces. In addition: o when pre-shared key authentication will be used, the CE device is provisioned with a pre-shared secret key. De Clercq et al. Expires August 2003 [Page 10] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 o when digital signature authentication will be used, the CE device is provisioned with a (private key, public key)-pair, a public key for the Certificate Authority and a certificate for its own public key. (ii) for an HTTPs-secured provisioning channel, the CE is provisioned with a Certificate Authority's public key and with a pre-shared key that enables the CE to authenticate itself to the SP's VPN database. In addition to this, the necessary algorithms and other variables required for an HTTPs-connection need to be forseen. 3.1.2 The CE's IP address in the SP's space As mentioned before, the CE device is identified by an IP address (s) that belongs to the Service Provider's routing space. This IP address (s) may be an IP address assigned by the SP and manually configured on the CE device, together with the other (pre-)configuration information (this would require this IP address (s) to be configured on the attached PE too). Alternatively, the CE may dynamically obtain this IP address (s), using for example DHCP or IPCP over the CE-PE link. Yet another possibility is that the CE device has obtained a (global) IP address (s) from an ISP, and that the VPN customer communicates this IP address (s) to the VPN Service Provider. Note that the CE device needs to maintain this same IP address (s) at least for the duration of its VPN membership. 3.1.3 Other Information As it will become clear in this specification, other information such as timer-parameters is configurable by the SP. These parameters can be provisioned by the SP at pre-configuration time. 3.2 Establishing the secure provisioning channel Note: all the procedures described in this section are in the SP's addressing scope. For an IPsec secured provisioning channel, the CE device will use IKE (phase 1 and 2) to establish a Security Association with the SP's VPN database. The SA association will specify a transport IPsec mode to protect the HTTP* data between the CE and the SP's database. Note that these negotiations are taking place in the SP's IP space. The CE provisioning will from now on take place over this SA, identified by its IP addresses, SPI and security protocol. For an HTTPs-secured provisioning channel, the CE device will establish a secured (encrypted) TCP session, authenticating the VPN De Clercq et al. Expires August 2003 [Page 11] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 server using the configured CA public key. Once the SP's VPN server is authenticated, the CE device will send it's pre-shared key to the VPN database, using the encrypted HTTPs session. After successful authentication of the CE device, the provisioning channel is considered securly established. [Note: the procedures for authenticating the CE device by the VPN server using the pre-shared key will be detailed in a next version of this document.] In the remainder of this specification, we will assume that the provisioning channel will be IPsec-secured. The mechanisms for an HTTPs-secured provisioning channel are analoguous. If either the establishment of the SA (or secure TCP session and/or the CE authentication) fails, the CE MUST NOT continue the described negotiations and provisioning actions. The CE MAY issue an alarm to trigger human interaction. 3.3 Fetching the VPN configuration information [Note: mechanisms using other protocols than the ones proposed by this document for the secure retrieval of configuration information may be deployed (for example using FTP/IPsec or /SSH, etc.). Every approach will require the definition of the necessary protocol fields carrying the herein described VPN configuration information though.] The VPN service is initialized on the CE device by retrieving the VPN configuration information from the SP's VPN database using HTTP* over the secured channel. The CE device will use (XML)/HTTP/secure_connection to retrieve from the SP's VPN server the information that is necessary to establish IPsec-secured tunnels with the other CE devices that belong to the same VPN (and to which it should establish a virtual VPN link - dependend on the VPN topology). The SP may choose to let the CE devices authenticate the IKE negotiations between them using (i) pre-shared keys or (ii) digital signatures and certificates. The IPsec implementation on the CE devices SHOULD support both modes of authentication. (i) in case of pre-shared keys, the following information is to be retrieved from the SP's VPN server using (XML)/HTTP: - a list of tuplets (SA information = the necessary information to negotiate a SA De Clercq et al. Expires August 2003 [Page 12] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 with the peer CE: security protocol, Diffie-Hellman group, IPsec transforms, etc.) (tunnel information : traffic-driven tunnel or 'permanent' tunnel; tunnel mode IPsec or transport mode IPsec over an IP- in-IP encapsulation; dynamic routing trough the tunnel or not) (ii) in case of digital signature authentication, the following information is to be retrieved from the SP's VPN server using HTTP: - a pair - a certificate for the public key - a public key from the Certificate Authority - a list of tuplets The above information is represented in an XML file on the SP's VPN server. To retrieve this information, the CE device sends an HTTP retrieve action of a format that may look like this: GET sp-vpn- server-url/vpn-name/ce-identifier.xml over the secured channel. The VPN server then responds by sending the requested file to the CE device over the secured provisioning channel. If the configuration information retrieval fails, the CE SHOULD retry the operation and this with exponential backoff. If the operation still fails after a number of attempts (this number is configurable by the SP), the CE SHOULD quit the operation and generate an alarm as to trigger human interaction. The XML representation is to be defined in a companion document. 3.4 Establishing the (secure) VPN tunnels/SAs When one Site sends traffic to another Site belonging to the same VPN, these IP packets will be secured via IPsec. This means that an IPsec Security Association is needed between each pair of sites that directly exchange private VPN data with each other. The Internet Key Exchange protocol (IKE, [IKE]) or its successor IKEv2 [IKEv2] will be used for the purpose of automatic setup of security associations between VPN sites within the same VPN. The CE devices will use the information retrieved from the SP's VPN server to negotiate SAs with their peers, using IKE(v2). De Clercq et al. Expires August 2003 [Page 13] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 The succesfull establishment of such a 'VPN' IPsec SA between two CEs will result in the auto-configuration of a new VPN tunnel (or virtual link) between the two considered CE devices. As explained in section 5 of this memo, a 'VPN tunnel' is either an IPsec transport mode SA protected IP-in-IP tunnel or alternatively a tunnel mode IPsec SA. In both cases, the VPN tunnel is established once the protecting SA is established. These dynamically established SAs can be set-up and maintained independently of the presence of actual inter-site user traffic, resulting in 'permanent' IPsec tunnels. These tunnels are then always available and not traffic-triggered. It is then required to frequently re-negotiate the SA (via IKE(v2)) before the IPsec timers of the connection time out. The set-up of a 'permanent' IPsec tunnel will be triggered by the configuration of a new peer CE device within the same VPN. An advantage of this method is that the IPsec tunnel is always available, and that eventual traffic does not encounter an extra delay due to the setup time of a new SA. The use of 'permanent' IPsec tunnels is recommended for CE-based site-to-site VPNs. A CE device that first joins a VPN must retrieve the initial VPN configuration information from the SP's VPN server. Next, for 'permanent' IPsec tunnels, the considered CE SHOULD subsequently establish "VPN tunnel SAs" (using IKE) with every peer CE device listed in the VPN configuration information. o if the IKE negotiation is accepted and authentication succeeds, the SA is successfuly established. o if the IKE negotiation is refused or the authentication fails, the IKE negotiation must be stopped and the SA not be established; the CE device SHOULD then wait for a time interval larger than 'T' (see section 3.4) and then try negotiating the SA with the considered peer again. After a new failure, the CE device SHOULD retry after a certain period of time (t1, to be configured). This process SHOULD continue with exponential backoff of t1 until a certain limit (to be configured) upon which an alarm MUST trigger human interaction. Provider provisioned CE-based IPsec VPNs as described by this document SHOULD use 'permanent' IPsec Security Associations when dynamic routing through IPsec-secured tunnels is used. Alternatively, the IPsec SA setup can be triggered by the effective (data) traffic flow going from one site to another. In this case, the arrival of data packets at the CE device, coming from within the VPN site and going to another VPN site, will be noticed by the CE's IPsec De Clercq et al. Expires August 2003 [Page 14] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 or routing database, and an IKE exchange will be initiated to set up an IPsec secured connection between both parties. Once the secure tunnel is set up, the data packets can flow from one site to the other in a secure way. When no traffic flows for a certain duration of time, the secure tunnel will be torn down again. An advantage of this method is that an IPsec tunnel is only to be maintained when there is effectively traffic flowing. A disadvantage is the extra delay introduced for the traffic during IKE signaling and the difficult interaction with the tunneled inter-site VPN routing information distribution. Provider provisioned CE-based IPsec VPNs as described by this document MAY use traffic-driven IPsec SA establishment when static intra VPN inter-site routing is used (no dynamic routing through the IPsec tunnels), see section 4.3. Provider provisioned CE-based IPsec VPNs as described by this document SHOULD NOT use traffic-driven IPsec SA establishment when dynamic site-to-site routing through the IPsec-secured tunnels is used. The CE configuration determines whether traffic-driven SA establishment is used or not, and whether dynamic routing through IPsec tunnels is used or not. The procedures described in this memo can be used together with [IPSEC-DPD] that offers a mechanism to efficiently keep IPsec SAs alive. Note that IPsec tunnels are unidirectional in nature, but that within the application of this specificiation, the set-up of one direction MUST be accompanied by the set-up of the reverse direction IPsec tunnel. This document describes two possible ways to use IPsec in CE-based VPN scenarios (see section 5): in 'transport mode' or in 'tunnel mode'. The CE configuration, IKE exchange and resulting SA's must specify which mode will be used. Note that the number of peer CE devices with which a specific CE device must have an IPsec connection to secure the data traffic, is dependent on the specific 'role' of the site in the considered VPN. A hub CE will for example have a larger number of tunnels to support than a spoke device. 3.5 Updating VPN configuration information If a dynamic configuration update mechanism is required (as per the contract between SP and VPN customer), the procedures should be as described in this section. De Clercq et al. Expires August 2003 [Page 15] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 Every CE device in the VPN SHOULD periodically retrieve the VPN configuration file from the SP's VPN server. The interval 'T' that is used for this operation is configurable by the SP. The interval 'T' SHOULD be (several magnitudes) larger than the time it takes to establish the SAs with all the peer CEs included in the VPN configuration file. If the retrieval of the VPN configuration information fails, the CE SHOULD retry the operation and this with exponential backoff (the exact timing parameters to be used upon failure are configurable by the SP). If the operation still fails after a number of attempts (this number is configurable by the SP), the CE SHOULD quit the operation and generate an alarm as to trigger human interaction. A. For 'permanent' inter-site IPsec SAs At every periodical retrieval, the considered CE device (CE_a) SHOULD compare its existing VPN configuration information with the new VPN configuration information. If the new VPN configuration information is identical to the existing (old) VPN configuration information, the VPN configuration has not changed from the considered CE's point of view and the CE should not initiate any specific actions. If the new VPN configuration information is different from the existing (old) VPN configuration information, then different possibilities exist with regards to the changes between the new and the old VPN configuration information (note that these differences are not mutually exclusive: any combinations may occur): o the new VPN configuration information contains one or more (new) CE device(s) that were not listed in the existing VPN configuration information; This means that (i) one or more sites that were not previously part of the considered VPN have been added to the VPN, or (ii) that new inter-site (virtual) links (VPN tunnels) have been added to an existing VPN (two CEs of a VPN that were not directly connected in the past now should be directly connected). Assume that CE_b is a CE device that was not previously listed in CE_a's VPN configuration information. In order not to overload a potential 'new' CE device (CE_b), the considered CE device (CE_a) SHOULD NOT immediately initiate the VPN tunnel establishment procedure towards CE_b (via SA establishment negotiations with IKE(v2)). If no VPN tunnel establishment request has been received from CE_b after a De Clercq et al. Expires August 2003 [Page 16] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 certain period of time t3, the considered CE (CE_a) SHOULD initiate the VPN tunnel establishment procedure with CE_b. t3 is a parameter that is configurable by the SP per CE device, and SHOULD be larger than 2 times 'T'. If this VPN tunnel establishment fails, the considered CE (CE_a) SHOULD wait for a time interval t4. If during this time interval, no VPN tunnel has been established after VPN tunnel establishment negotiations initiated by CE_b, CE_a SHOULD re-attempt to establish the VPN tunnel. This process SHOULD continue with exponential backoff of t4 until either the new SA is successfuly established or until a certain limit (to be configured by the SP) is reached upon which an alarm MUST trigger human interaction. o the list of CE devices in the new VPN configuration information and in the existing VPN configuration information are the same, but the information associated with one or more of the peering CE devices has altered; In this case, the considered CE device SHOULD initiate IKE(v2) negotiations with every peer CE devices who's associated new VPN information has altered in such a way that new SAs are required (e.g. when the security parameters have altered). If a new SA establishment fails (let's say with peering device CE_2), the considered CE device SHOULD quit the negotiation and SHOULD continue to use the existing SA and the existing VPN tunnel. If during a configurable time interval t5 larger than 'T', a new SA according to the new VPN configuration information has not been established after IKE(v2) negotiations initiated by CE_2, the considered CE device SHOULD retry and attempt to establish a new SA with CE_2 according to the new VPN configuration information. After a new failure, and if during a certain period of time (t2, to be configured by the SP) no successful new SA was established due to IKE(v2) negotiations initiated by CE_2, the considered CE device SHOULD re-initiate the SA negotiation with IKE(v2). This process SHOULD continue with exponential backoff of t2 until either the new SA is successfuly established or until a certain limit (to be configured by the SP) is reached upon which an alarm MUST trigger human interation. After succesful establishment of a new SA according to the new VPN configuration information, the old SA MUST be deleted and the properties of the altered VPN tunnel changed if necessary. o the existing VPN configuration information contains one ore more CE devices that are not listed any more in the new VPN configuration information; De Clercq et al. Expires August 2003 [Page 17] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 In this case, the considered CE device MUST tear-down the existing SAs (using IKE(v2)'s tear-down process) that it has with the peering CE devices that are no longer listed in the VPN configuration information, and remove the associated VPN tunnels. A CE device (CE_a) that receives an initial IKE message from a CE device (CE_b) with which it has no VPN SA established yet, MUST check whether that CE device's (CE_b) IP address (s) is part of its VPN configuration information. Subsequently: o if CE_b's IP address is part of CE_a's peer devices in the VPN configuration information, the CE device (CE_a) SHOULD accept the IKE message and proceed with the IKE negotiation for the creation of a new SA association and thus a new secured VPN tunnel (virtual link); o if CE_b's IP address is NOT part of CE_a's peer devices in the VPN configuration information, the CE device (CE_a) MUST NOT accept the IKE message and MUST NOT establish a new VPN tunnel; o after rejecting an IKE negotiation, the considered CE (CE_a) MAY retrieve an updated VPN configuration file from the SP's VPN server; alternatively, the CE MAY wait for the end of the periodical update interval before doing so. Especially the arrival of a large number of 'bad' IKE negotiation messages SHOULD NOT trigger the CE device to repetedly retrieve VPN configuration information. A CE device (CE_a) that receives a correct IKE tear-down request from a peering CE device (CE_b), MUST tear-down the considered SA and remove the associated VPN tunnel from its configuration. CE_a SHOULD not attempt to re-establish the SA by initiating IKE(v2) negotiations with CE_b prior to the next update of its VPN configuration information. Whenever the CE's active VPN configuration conforms to the newly retrieved VPN configuration Information, the CE SHOULD overwrite its old VPN configuration information with the new VPN configuration information. Changes to the CE's VPN configuration information that don't require inter-CE signaling interactions SHOULD be immediately instantiated. B. For traffic-driven inter-site IPsec SAs De Clercq et al. Expires August 2003 [Page 18] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 TBD. 3.6 Removing an existing VPN site When the VPN customer wants to remove an existing site from a certain VPN, this customer first informs the VPN SP. The SP will then update the VPN database on the centralized server. Different approaches can then be used. The SP can provision the considered CE device to delete its VPN information and to tear-down the IPsec SA's using IKE(v2). After completion of the IKE tear-down proces, the peering CE devices must not attempt to re-establish the deleted SA. At this stage, the VPN tunnels are actually removed, and the routing protocols operating through the tunnels in the VPN's routing space will notice the topology change and react appropriately. The periodical retrieval of the VPN configuration information from the VPN database by the other CE devices will then make sure that the removed CE's information is no longer available. The discussed provisioning action can happen in the same way as the pre-provisioning action described in section 3.1, i.e. via manual configuration, via remote management or via interaction with the customer. Alternatively, the SP will not provision the to-be-removed CE individually but the removal of the information relevant to the considered CE from the VPN database will ultimately automatically result in the removal of the CE from the VPN: peer CEs will notice the removal of the particular CE from their configuration file and will tear-down the appropriate SA using IKE(v2); the deletion of active SAs will effectively remove the VPN tunnels and the routing protocols running through the VPN tunnels will discover the topology changes and react accordingly. The to-be-removed CE will not be able to retrieve VPN information from the VPN database and will delete all its VPN information and try to tear-down the remaining SAs. 4. Exchanging and maintaining VPN routes One of the requirements for PP CE-based VPNs is that dynamic routing is not only supported within individual VPN sites, but also between the different VPN sites of a specific VPN. This means that when a change in the routing information in a specific site occurs, the other sites that belong to the same VPN must be notified of that change. This section deals with the exchange of routing information in the customer VPN's routing space (v). As depicted in figure 4, this exchange of routing information happens over the VPN tunnels and is as such transparant for the SP's network. CE devices MUST NOT leak De Clercq et al. Expires August 2003 [Page 19] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 VPN routes into the SP's network and MUST NOT leak routes from the SP's routing space into the VPN sites, unless explicitly configured to do so (as e.g. explained in section 6 of this document). routing adjacency (VPN space) ______________________________________________________ CE_1 | | CE_2 -------|----------------- ---------------|------- | _____V____ === |I| | | |I| === ____V_____ | | |routing/ |=======|P|==|===== VPN tunnel ===|=|P|======|routing/ | | | |forwarding| === |s| | | |s| === |forwarding| | | |VPN space | === |e| |-- PE - core - PE --| |e| === |VPN space | | | ---------- =====|c|==|= | |c| = = ---------- | | IP-in-IP | || | IPinIP | |_________________________| == to CE_3 ----------------------- --- VPN space ---><--------- SP's routing space ------><-- VPN space -- figure 4: tunnelled routing adjacency in the VPN routing space This document assumes that the routing within a VPN site is controlled by the VPN customer, and thus is outside of the scope of this specification. 4.1 The CE device and VPN routing On the customer network side, a CE router connects to internal networks of an enterprise, where one or more subnets can reside. Many times, the CE router may interact with another internal router. And sometimes, "backdoor links" between routers of different sites of the same VPN exist. In the VPN routing space (v), the CE is involved in (i) the intra- site routing, (ii) the VPN tunnel termination, and (iii) the inter- site VPN routing. The CE device could be an integrated device providing both routing and IPsec tunnel termination. Sometimes, a dedicated VPN terminator may be used. Implementations in which the VPN tunnel terminator resides on a firewall are also very common. For the sake of simplicity, we assume that the CE router is an integrated device that participates in the intra-site routing (e.g. via an IGP) and at the same time terminates VPN tunnels. In the context of this document, the routing aspects within a VPN site (intra-site routing information distribution) are controlled by the VPN customer. De Clercq et al. Expires August 2003 [Page 20] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 As was explained earlier, the SP's dynamic VPN discovery scheme and tunnel establishment mechanism provides the CE device with secure (virtual) links towards other CE devices in the same VPN. Whether the intra-VPN inter-site routing aspects that make use of these virtual links are managed by the customer or by the SP is dependent on the service contract. In many situations, the SP will configure the necessary routing protocol information at pre-configuration time (see section 3.1), in close colaboration with the customer. An important requirement for the routing protocol implementation that is configured to exchange reachability information through the inter-site tunnels, is that it must be able to autonomously deal with dynamically created new inter-site links. 4.2 IPsec and routing IPsec is a layer 3 security protocol, which operates purely at the IP layer. The IETF IPsec Working Group specifies the IPsec standards ([IPSEC], [RFC2402], [RFC2406], [RFC2407], [RFC2408], and [IKE]). The interaction between IPsec and layer 3 routing is often troublesome and has been described in [TOUCH], [KNIGHT] and [DUFFY]. Depending on individual implementations, difficulty may arise when an IPsec user wants to support robust routing across IPsec-interconnected VPNs sites. Details regarding the problems of the interaction between VPN routing and VPN tunneling, and some proposed solutions to counter these issues, can be found in [TOUCH], [DUFFY] and [KNIGHT]. 4.3 Exchanging VPN routes between VPN sites In the proposed mechanism to exchange VPN reachability information between VPN sites, routing protocol messages are tunneled through the IPsec-secured tunnels between peering sites. The CE-to-CE IPsec- secured tunnels between VPN sites are then being seen as point-to- point links by the customer networks and are interpreted as such by the routing protocol functions of the CE devices. This means that when a change in the reachability occurs in one particular site, a routing protocol (such as RIP, OSPF, etc.) will take care of the distribution of the new reachability information within the site, but also to all other sites, through the VPN tunnels that the considered CE is peering with. As the described architecture allows for the dynamic creation of inter-site (IPsec-protected) VPN links, the routing protocol implementation(s) operating on the CE device MUST be able to support this. De Clercq et al. Expires August 2003 [Page 21] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 Although very often it will be the SP's responsibility to configure the CE's routing information at pre-configuration time, the service aggreement MAY specify that routing on the CE device falls under the customer's management. When routing protocol messages are tunneled through the IPsec-secured tunnels ('dynamic routing through IPsec-secured tunnels') as per this section, IPsec transport mode secured IP-in-IP tunnels as per [TOUCH] SHOULD be used (in contrast to IPsec tunnel mode tunnels). Note that other approaches may use a combination of dynamic routing and IPsec tunnel mode tunnels, though it is not clear how interoperability will then be assured. Another issue to consider is the fact that using a traffic-driven tunnel establishment mechanism and at the same time using an approach whereby a routing protocol (with a keep-alive mechanism) runs on top of the VPN tunnel, does not seem currently applicable: the delay introduced by the tunnel establishment phase could lead to a loss of routing updates and the routing protocol's keep-alive mechanism could interact with the tunnel establishment in an undesired way. Therefore, when dynamic routing is used through IPsec-secured CE-to- CE tunnels, traffic-driven SA establishment SHOULD NOT be used. 5. Tunneling IP traffic (user data) among VPN sites This section describes the processes that an IP packet that is sent from one VPN site to another will go through. This is dependent on the way that IPsec is used. This document describes two possible ways to use IPsec in CE-based VPN implementations: IPsec in tunnel mode, and IPsec in transport mode. An IP packet that is sent by an IP device in a certain site and destined for an IP device in another site belonging to the same VPN, will be forwarded as follows. The device in the sending site sends an IP packet (possibly using a private address space) on its LAN network. The next hop for this destination IP address will (at some point in time) be the site's CE device (according to the routing/forwarding in the VPN site). The processing by the CE device now is dependent on the implemented mode for IPsec. The use of IPsec in tunnel mode has the advantage that the complete range of SPD-checks remain usuable, but has the disadvantage that dynamic routing through the tunnels is not supported. The use of IPsec in transport mode secured IP-in-IP tunnels has the advantage that dynamic routing through the tunnels is fully supported, but has De Clercq et al. Expires August 2003 [Page 22] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 the disadvantage that the complete range of SPD-checks is not supported. Note that the following description is not meant to specify an implementation strategy; any implementation procedure wich produces the same results is acceptable. o IPsec in transport mode (see also [TOUCH] for a detailed specification) When IPsec is used in transport mode in this context, the CE device must first analyze the private IP packets arriving from within the site and select the appropriate outgoing interface and required encapsulation, based on the VPN routing/forwarding information. For a destination located in an other site, the outgoing interface will be a virtual interface (a VPN tunnel) and the required encapsulation will be IP-in-IP, using the considered CE's IP address (s) as the source address in the outer IP encapsulation header and a peer CE's IP address (s) in the outer IP encapsulation header's destination address field. The CE device then processes this new IP packet to its IPsec driver. The IPsec driver in the CE device must then do the following: - analyze the IP packets that have been IP-in-IP encapsulated and select the appropriate SA (based on the packet's outer header destination address (s)). - authenticate and/or encrypt the private IP packet according to the (transport mode-specific) rules described in the SA and insert an appropriate IPsec header (according to IPsec in transport mode). o IPsec in tunnel mode When IPsec is used in tunnel mode in this context, the IPsec driver in the CE device must do the following: - analyze the private IP packets arriving from within the site and select/setup an appropriate SA with the appropriate destination CE device. - authenticate and/or encrypt the private IP packet according to the (tunnel mode-specific) rules described in the SA, AND encapsulate the packet in an IPsec header AND encapsulate the packet in a new 'outer' IP header. This 'outer' IP header has the CE's non-private (i.e. routable in the SP's realm) IP address in the source IP address field and the destination CE's non-private De Clercq et al. Expires August 2003 [Page 23] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 (i.e. routable in the SP's realm) IP address in the destination IP address field. The CE device then sends the IPsec packet to the PE device, and the IPsec packet will then be forwarded using 'normal' IP forwarding across the SP's network, based on the outer header's IP destination address (s), that is the destination CE's 'global' (i.e. routable in the SP's realm) IP address. The packetwill be forwarded to the egress PE who will also only examine the outer IP header and send the IP(sec) packet to the destined CE device. The egress CE device will recognize itself as the destination node (the IP packet has the CE's IP address (s) in the outer IP destination address field) and process the IPsec packet to the IPsec driver that will then, based on the appropriate Security Association (identified by the packet's SPI field in the IPsec header), perform IPsec authentication and/or decryption. Dependent on whether tunnel mode or transport mode IPsec is used, the packet will be decapsulated by the IPsec driver itself or sent to the IP-in-IP decapsulation function. The resulting (private) IP packet (v) will then be further processed in the CE's VPN IP forwarding table and send on the LAN network to the appropriate next hop router or destination IP device. Note that IPsec tunnels might unintentionally terminate or break. When dynamic routing is not supported through the inter-site VPN tunnels, this may have serious consequences if VPN membership and VPN routing information are not changed accordingly within the VPN. Indeed, the unnoticed termination of a VPN tunnel can result in the creation of black holes. This means that a mechanism must exist to monitor the state of the VPN tunnels. When dynamic inter-site VPN routing is used, the routing protocol that runs on top of the IPsec VPN tunnels will serve that purpose. When dynamic inter-site routing is not used, the following alternatives are possible: (i) the use of an IPsec-specific keep- alive mechanism [IPSEC-DPD] and (ii) a SP-proprietary mechanism. 6. CE-based VPN and Internet 6.1 Allowing both VPN connectivity and Internet connectivity In many VPNs, sites will need to both access the public Internet as well as to access other sites within the same VPN. In order to achieve this, some sites within the VPN will obtain Internet Access by means of an "Internet Gateway" that is attached via one of its interfaces to an ISP's PE device. Such an Internet Gateway may for example be a firewall and may need to implement De Clercq et al. Expires August 2003 [Page 24] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 network address translation functions. The ISP may be the same SP that offers the VPN service, or it may be a different SP. The PE to which the Internet Gateway is connected may be the same PE to which the CE is connected or it may be an other PE. The Internet Gateway may be a separate device, or alternatively the Internet Gateway functions may be integrated into the CE device. When the Internet Gateway functions are integrated into the CE device, the CE-PE interface used by the Internet Gateway functions may be the same or a different interface than the interface used by the VPN tunnels. In further discussions, we'll assume that the Internet Gateway is a separate device. The service contract will define whether the Internet Gateway will be managed by the SP or by the VPN customer. Note that when Internet Access is offered within a VPN, the address spaces used within the VPN must be non-overlapping. This means that the VPN SHOULD either use global addresses that have been assigned to the VPN customer, or private addressing in combination with NAT [NAT]. The sites that have Internet Access via an Internet Gateway will have a default route (v) pointing to their Internet Gateway and may be distributing a default route via their CE towards the other CEs of the same VPN through the VPN tunnels. This provides Internet Access for all the VPN sites. Note that other sites (that don't have their own Internet Gateway) must not distribute default routes in this scenario. A site that has distributed a default route to other sites for Internet Access should have either a default route to its Internet Gateway or Internet routes (leading to its Internet Gateway) in its forwarding table (of the VPN routing space). De Clercq et al. Expires August 2003 [Page 25] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 VPN site <---- : : ---------- to Internet : _____| Internet |----------------:-- PE_2 | | Gateway | : | ---------- : --------|--------------------------- : | default | : | route to | : | _____|______ | : | | | ===== CE2 |I| | : ----|--|routing and | ===== CE3 |P| | : | |forwarding | ===== CE4 |s| -->|-----:-- PE_1 ----|--|in VPN space| ===== CE5 |e| | : | ------------ = = = |c| | : | IP-in-IP | : |______CE device_____________________| : <--- : intra : site : : figure 5: Internet Access from within a VPN The Internet Gateway will process (e.g. firewall + NAT) all traffic coming from within the VPN and, if accepted, send it to the PE with which it interfaces. As such the Internet Gateway effectively is the device that interfaces between the VPN routing space and the SP's/Internet routing space. Note that traffic that leaves a VPN via an Internet Gateway will not be IP-in-IP encapsulated and will not be IPsec processed. The traffic coming from the gateway will then be forwarded according to the PE's (default/Internet) forwarding table. In order to allow for traffic in the reverse direction (from the Internet to the VPN sites), the ISP connected to the Internet Gateway must distribute, to the Internet, routes that lead to addresses that are within the VPN. NAT-like techniques may also be used. As such there will be routes that will lead from the Internet to the site's Internet Gateway. The Internet Gateway will process traffic coming from the Internet and, if accepted, send it into the VPN site where intra-VPN routing and forwarding will lead the packets to their destination. This distribution of routes that lead to addresses within the VPN towards the Internet is independent of any intra-VPN route distribution as described elsewhere within this specification. Note also that normally the internal structure of the VPN will remain invisible to the outside world. When the Internet Gateway functions are implemented in the CE device and the CE device is attached via only one (sub-)interface towards De Clercq et al. Expires August 2003 [Page 26] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 only one PE device, inspection of the packets coming from the PE will indicate whether the concerned traffic is intra-VPN traffic (when the packet is an IPsec packet with the CE device's own IP address (s) in the outer header's destination address field and the encapsulated payload is an IP-in-IP encapsulated private IP packet (v), and a matching SA is found), or control-plane traffic (IKE(v2) or secured HTTP: when the inspected packets conform to the control plane's policies), or VPN-Internet traffic (then the Internet Gateway function will decide whether the considered packets will be accepted, (translated), and forwarded or not). In the above discussed procedures, some sites will access the Internet via a VPN tunnel that leads to another site of the same VPN, because they don't have an own Internet Gateway, and will forward the traffic according to the default route. Ultimately though, Internet traffic will always go via an Internet Gateway before entering/leaving a VPN. Further note that the PE to which the Internet Gateway is attached doesn't necessarily need to carry all the Internet routes; a default route to an other Internet router suffices. 6.2 Prohibiting or restricting Internet connectivity from within a CE- based VPN In the approach described in this document, the CE device sends IP packets (s) to the VPN-unaware PE device and receives IP packets from that PE device. The PE device forwards these packets based on the IP addresses (s) in the (outer) IP header. The packets received by the PE are as such either packets that are routable within the SP's private scope, or either in the public Internet's scope. This section discusses the implications hereof with regards to security and access control. o traffic that the CE sends to the PE Following the procedures described in this document, three types of traffic can be sent by the CE device towards the PE device: (i) customer VPN traffic: intra-VPN traffic sent from one VPN site to an other VPN site; these packets will always have the sending CE's IP address (s) in the IP header's source IP address field, the IP address (s) of a peer CE device of the same VPN in the IP header's destination IP address field, and will always contain an IPsec header; (ii) secured HTTP management traffic: this comprises both the traffic to establish the secure management channel (IPsec or De Clercq et al. Expires August 2003 [Page 27] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 secure TLS) and the traffic to download the VPN configuration file; these packets will always have the CE's IP address (s) in the IP header's source IP address field; (iii) IKE(v2) traffic: the IP packets sent between CE devices in order to establish SAs; these packets will always have the CE's IP address (s) in the IP header's source IP address field. o traffic that the CE receives from the PE Following the procedures described in this document, the same three types of traffic can be received by the CE device from the PE device. As such, the CE device should perform the following actions: + for IP packets that have the CE's own IP address (s) in the outer IP header's destination address field and that have an IPsec header: process the packets through the CE router's IPsec deamon where conformance with an existing SA will be checked, and the packets further processed; + for IKE(v2) packets that have the CE's own IP address (s) in the outer IP header's destination address field: process according to the procedures described in this specification; + for IP packets that have the CE's own IP address (s) in the outer IP header's destination address field and that correspond to secured management traffic: process according to the procedures described in section 3 of this specification; + for CE devices that have an integrated Internet Gateway role: process all other packets to the Internet Gateway module; + for CE devices that don't have an integrated Internet Gateway role: drop all other IP packets, unless explicitly allowed by complementary procedures that are out of scope of this memo. o SP's control over CE initiated traffic Note that with this specification's concepts, the PE device that receives traffic from a CE device has no means to verify whether the received traffic is intra-VPN traffic, or traffic that is sent to for example an other VPN or e.g. to the Internet. From a VPN data privacy point of view, this has no implications, as the security is enforced at the CE devices themselves: traffic that doesn't conform to the security associations or other policy rules will be dropped at the CE. De Clercq et al. Expires August 2003 [Page 28] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 One remaining issue is that customers might use CE devices (that have been granted VPN access) to access services they have not been granted access for, via the PE device. Although this would possibly compromise the security of the customer's own VPN, the SP may want to deploy measures to prevent this without bringing full VPN knowledge to the PE. One way of doing this would be by using specific IP address ranges for VPN purposes and to have specific access lists configured on the PE devices (this has inter-SP and Internet transparency issues though). Note that maintaining, at every PE, a list of would add a considerable management burden and is as such not advised. Another strategy for the SP would be not to care about the particularities of the traffic and treat it as it treats public Internet traffic (and as such to only control the total of the resources consumed by particular access connections). Taking into consideration that in many cases, VPNs will also need to be able to access the public Internet, and that the above problem does not seem to be an important thread for the SP nor the VPN customer, this issue is not considered as a major drawback for the deployment of the discussed VPN approach. 7. Extranet functionality with provider provisioned CE-based VPNs TBD 8. Quality of Service TBD 9. Security Considerations The security aspects of what is presented in this document are implicitly discussed in most of the sections. This draft is for a large part focussing on security aspects. Note that the security of the mechanisms presented here is highly dependent on the following factors: - the security of the 'management channel', used by the management protocol to configure the VPN CE devices. - the security of the site and of the CE-device itself - the security aspects of the credentials: the IPsec credential must be generated, provisioned, updated, and stored securely - for a VPN with a complex topology, every tunnel must use the De Clercq et al. Expires August 2003 [Page 29] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 same grade of security strength, otherwise, a single weak link degrades the whole VPN 10. Acknowledgements The authors would like to thank the following persons for their valuable contributions to this document: Lars Eggert, Brian Gleeson, Archana Khetan, Sankar Ramamoorthi, Eric Rosen, Michael Choung Shieh, Joe Touch, Eric Vyncke, S. Felix Wu, Yu-Shun Wang, Cliff Wang, Alex Zinin. 11. References [DUFFY] Duffy, M., "Framework for IPsec Protected Virtual Links for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00.txt, October 2002, Work in Progress [FRAMEWORK] Callon, R. et al., "A Framework for Provider Provisioned Virtual Private Networks", draft-ietf-ppvpn-framework-0x.txt, Work in progress [GRE-CE] Khetan, A., et al., "Use of GRE for routing support in IPsec VPNs", draft-khetan-sp-greipsec, Work in progress [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", November 1998, RFC 2409 [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", November 1998, RFC 2401 [IPSEC-DPD] Huang, G., Beaulieu, S., Rochefort, D., "A Traffic-Based Method of Detecting Dead IKE Peers", draft-ietf-ipsec-dpd-0x.txt, Work in progress [KNIGHT] Knight, P., Gleeson, B., "A Method to Signal and Provide Dynamic Routing in IPsec VPNs", draft-knight-ppvpn-ipsec-dynroute, Work in progress [LEE-DHCP] Lee, C.Y., "Customer Equipment Auto-configuration", March 2002, work in progress [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", November 1998, RFC 2402 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", November 1998, RFC 2406 De Clercq et al. Expires August 2003 [Page 30] Internet Draft draft-declercq-ppvpn-ce-based-sol-00.txt February 2003 [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP" November 1998, RFC 2407 [RFC2408] Maughan, D., et al., "Internet Security Association and Key Management Protocol (ISAKMP)", November 1998, RFC 2408 [TOUCH] Touch, J. and Eggert, L., "Use of IPSEC transport mode for Virtual Networks", draft-touch-ipsec-vpn-0x.txt, Work in progress 12. Authors' Addresses Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: jeremy.de_clercq@alcatel.be Cheng-Yin Lee Alcatel E-mail: cheng-yin.lee@alcatel.com Paul Knight Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Email: paul.knight@nortelnetworks.com Phone: +1 (978) 288 6414 De Clercq et al. Expires August 2003 [Page 31]