Network Working Group Jeremy De Clercq INTERNET DRAFT Olivier Paridaens Mahadevan Iyer Andrew Krywaniuk Alcatel July 2001 Expires January, 2002 A Framework for Provider Provisioned CE-based Virtual Private Networks using IPsec 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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directorieson 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 a framework for a Service Provider to offer Virtual Private Network Services to its customers by provisioning network elements that are located at the customer premises. The IPsec technology is used to protect the Customer traffic. 0. SubIP-Area Section SUMMARY De Clercq et al. Expires January 2002 [Page 1] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 The PPVPN framework document [FRAMEWORK] identifies three basic provider provisioned VPN types : Provider Provisioned Network 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 network elements that are located at the customer premises (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 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 adition of one VPN site only requires a minimum amount of configuration. This is obtained by using an automatic distribution scheme via a network management protocol. RELATED DOCUMENTS See References section. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK PPVPN box. WHY IS IT TARGETED AT THIS WG This document describes the framework for Provider Provisioned CPE- 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.". De Clercq et al. Expires January 2002 [Page 2] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 JUSTIFICATION This document is justified by the fact that it defines a framework for PP CPE-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 CPE-based VPNs have specific characteristics compared to Network-Based VPNs especially with regards to management and security. 1. Introduction The PPVPN framework document [FRAMEWORK] identifies three basic provider provisioned VPN types : Provider Provisioned Network 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 network elements that are located at the customer premises (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 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 adition of one VPN site only requires a minimum amount of configuration. This is obtained by using an automatic distribution scheme via a network management protocol. 2. Reference Model This section describes the reference model used. It is the purpose to allign this section with the terminology and the reference model for CE-based PP-VPNs that will be described in future versions of [FRAMEWORK]. De Clercq et al. Expires January 2002 [Page 3] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 +---------+ +------------------------------------+ +---------+ | | | | | | | | | +------+ +------+ : +------+ +------+ : | | | | | | : | 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 o Customer Edge (CE) device A CE device is a router located at the customer premises, that has IP connectivity with a SP's PE device. In the context of CE-based VPNs, a CE device maintains one or more VPN tunnel endpoints. In the context of Provider-provisioned CE-based VPNs, the VPN functions in the CE device can be managed by the SP's management system. 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.). 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 De Clercq et al. Expires January 2002 [Page 4] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 traffic to be sent through a VPN and traffic to be sent outside any VPN. 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 IP connectivity over the access connections to these CE devices. o SP networks A SP network is a network administrated by a single service provider. In the context of provider provisioned CE-based VPNs, the SP network consists of the Service Provider's IP (backbone) network and the Service Provider's management functions that manage both its own IP (backbone) network and the VPN customer's VPN functions on the CE devices. o Access connection An access connection represents an isolated layer 2 connectivity between a CE device and a PE router. This includes dedicated physical circuits, logical circuits (such as Frame Relay and ATM), plus IP tunnels (e.g., using IPsec, L2TP). 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 an IP tunnel (IP-in-IP/IPsec) between two CE devices. 2.2 Assumed Reachability It is assumed in this specification that the CE devices have at least one IP address that is known to the SP network and that is routable within the SP's network. This implies that every CE device knows how to reach the other CE devices attached to the common SP. This might De Clercq et al. Expires January 2002 [Page 5] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 be via a direct routing entry in the CE's routing table or alternatively (and probably) via a default route towards the PE device it is attached to. These CE IP addresses will be known in the SP network, if not globally, then at least in the PE devices engaged in the VPN services. This means that either a routing protocol will be running between the CE and the PE device, exchanging routes belonging to the service provider's routing realm; or alternatively, the CE will have a configured default route or static route towards the PE, and the PE will have assigned an IP address to the CE device upon set-up of the IP service offered to the CE device. 2.3 Assumed Service Provider's infrastructure It is assumed that the Service Provider has a secure control channel to every attached CE device. This secure control channel will be used to exchange VPN-specific configuration information between the SP's VPN database and the CE devices. The particular implementation of this control channel is currently outside of the scope of this document. Some examples are: (i) manual configuration by a trusted party, directly on the considered network element; (ii) via a management protocol running over an IPsec-secured connection between the SP's management center and the considered network element; (iii) via a management protocol that has its own implicit security mechanisms. 3. Configuring the CE-based VPN As a Service Provider that is offering VPN services over its backbone network will be responsible for the configuration and the management of a potential large amount of VPNs, it is required that the provisioning actions for the set up and the maintenance of a PP CE- based VPN would be minimal. The minimal configuration that is necessary is the configuration of the Service Provider's VPN database with the CE device to be part of a well-defined VPN. Further provisioning can be achieved via an auto-discovery mechanism as is described in the sections below. For the purpose of CE device configuration, the Service Provider will maintain a VPN database per VPN customer. The exchange of information between the SP's VPN database and the targetted CE-devices is achieved using an information exchange/configuration protocol such as LDAP, SNMP, COPS etc. We will call this protocol 'the management protocol' throughout the rest of this document. De Clercq et al. Expires January 2002 [Page 6] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 It is assumed for the scope of this document that the control channel used for the configuration information exchange by the chosen protocol is sufficiently secured. This document will identify some requirements that the considered protocol should satisfy for the purposes of applicability in the VPN autodiscovery phase. 3.1 (Minimal) configuration needed at the CE device - 'Control channel' information : the information needed to access (or to exchange information with) the SP's VPN database ('database reachability information', authentication information for the VPN database, encryption information for the configuration control channel etc.). Note that this is assumed to be present, and that setting up a secure control channel is outside of the scope of this document. - Peer CE devices : the IP addresses (in the SP's realm) of the peer CE devices that belong to the same VPN and to which a direct peering relationship is required. This information can be one IP address (e.g. in the case that the considered CE device is a 'spoke' in a 'hub&spoke' topology); this information can be the complete set of the IP addresses of all the other CE devices belonging to the same VPN (in the case of a 'fully meshed' topology); or this information can be a subset of the IP addresses of the CE devices belonging to the same VPN (for more complex topologies). - Security Information : the information needed to set up and maintain IPsec Security Associations with the Peer CE devices (a set of transforms for use with IPsec, etc.). This information relates to the protection of the actual user data packets. This means that the VPN database (identified by a VPN identifier) of the SP's management system contains a list of all the CE devices belonging to the specified VPN, a description of the topolgy (full mesh, hub&spoke, etc) and some security-related information related to every CE-to-CE tunnel. 3.2 Updating configuration information (neighbor discovery) One of the most important requirements relating to scalability for PP-VPNs is that the addition/deletion of a certain site to/from an existing VPN should be possible with a minimal configuration effort. Manual configuration of the information related to the new site into every existing CE in the particular VPN is not an option. Different methods to achieve the requested behaviour are possible. De Clercq et al. Expires January 2002 [Page 7] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 One such method is for the SP to configure the 'new site' in the SP's VPN database: The CE's IP address in the SP's realm, the VPN-ID of the VPN it belongs to, the 'role' of the new site in the existing topolgy (hub, spoke, etc.), and the necessary security information are configured in the concerned VPN database. This change in the database triggers the distribution (via a management protocol such as COPS, LDAP, SNMP, etc.) of the updated information over the secure control channel to the concerned CE devices only (the new CE device and all the CE devices it has to peer with). This method implies that the protocol used for the distribution of the configuration information to the CE devices should be usable in a "PUSH" mode from 'server' to 'client' (the management system - server - pushes the updated information to the concerned parties - clients- ). It is to be noted that some information distribution technologies such as LDAP are natively not PUSH oriented. If the VPN configuration is stored using such a technology, it is necessary to define a mechanism that enables the CE to be trigerred so as to fetch VPN configuration from its repository. Such a mechanism could be based on the use of SNMP messages sent to the CE device, with specific variables that trigger the fetch operation. 3.3 Setting up the VPN tunnels When one VPN site sends traffic to another VPN 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 exchange private VPN data. The Internet Key Exchange protocol (IKE, [IKE]) will be used for the purpose of automatic setup of security associations between VPN sites within the same VPN. 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 or routing database, and an IKE exchange will be initated 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 signalling. De Clercq et al. Expires January 2002 [Page 8] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 Alternatively, 'permanent' IPsec tunnels can be set up. These tunnels are always available and not traffic-triggered. It is then required to frequently re-negotiate the SA (via IKE) before the IPsec timers of the connection time out. The set-up of a 'permanent' IPsec tunnel can 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. A disadvantage is the necessary frequent re-keying of the SA's. Note that IPsec tunnels are unidirectional in nature, but that usually the set up of one direction is 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 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. In the case of traffic-driven tunnel setup, the 'role' of the considered site has an impact on the CE's routing/forwarding databases. In the case of 'permanent' IPsec tunnels, permanent IPsec tunnels will be set up only to a specific set of peer CE devices, conforming the VPN's topology. 4. Exchanging and maintaining VPN routes This document currently describes two alternative mechanisms for the purpose of exchanging VPN routes between VPN sites. 4.1 Tunneling routing information between CE devices through the IPsec tunnels. In the first mechanism to exchange VPN reachability information, normal routing protocol messages are tunneled through the IPsec tunnels between peering sites. The CE-to-CE IPsec tunnels between VPN sites are then being seen as point-to-point links by the customer networks and are inserted as such in 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, IS-IS, 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 the considered CE is peering with. Note that when IPsec in tunnel mode is deployed, the routing protocol De Clercq et al. Expires January 2002 [Page 9] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 messages need to be carried on IP for this method to be applicable. When IPsec transport mode is deployed (see section 5), the routing protocol messages will first be IP-in-IP encapsulated before IPsec handling. Another point to keep in mind is the fact that when the setup of the VPN tunnels via IKE is traffic-driven, the distribution of routing information over the tunnels will also trigger the setting up of an IPsec tunnel, even when no data traffic is flowing. Therefore a routing protocol that only distributes reachability information upon changes is required. Moreover, in the specific case of link state routing protocols, the hello mechanism will also trigger the setup of IPsec tunnels. 4.2 Exchanging VPN reachability information via SP's management An alternative method to exchange reachability between sites within a VPN is by SP's management system involvement. When the reachability in a certain site changes, the considered CE device will need to communicate the new reachability information through the secure control channel to the SP's VPN database. This could be achieved either by having the CE device to push the new information to the SP's VPN database or by having the CE device to send some message (eg SNMP trap) to the SP's management system, which in turn can pull the new reachability information from the CE device. Once the SP's VPN database has been updated, this will trigger the distribution of this updated information from the SP's VPN database to all the appropriate CE devices by the management system, using the management protocol over the secured control connections. Within the sites themselves, the CE device may then inject the updated reachability information into the local routing protocol function. Note that this method does not require the use of the same 'management protocol' for the configuration of the CE device and for the dynamic exchange of reachability information. A dedicated protocol may be used for that purpose. 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 De Clercq et al. Expires January 2002 [Page 10] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 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 (using a private address space) on its LAN network. The next hop for this destination IP address will 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. 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: - analyse 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 (i.e. routable in the SP's realm) IP address in the destination IP address field. o IPsec in transport mode (see also [TOUCH]) When IPsec is used in transport mode in this context, the CE device must first analyse the private IP packets arriving from within the site and select the appropriate destination CE, based on the routing/forwarding information. The CE device then encapsulates the private IP packet into a new IP packet (IP-in-IP encapsulation/tunneling), with the own non-private (i.e. routable in the SP's realm) IP address in the source address field of the new header and the destination CE's non-private (i.e. routable in the SP's realm) IP address in the destination address field of the new header. 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: - analyse the IP packets that have been IP-in-IP encapsulated and select the appropriate SA (based on the packets destination address). - authenticate and/or encrypt the private IP packet according to De Clercq et al. Expires January 2002 [Page 11] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 the (transport mode-specific) rules described in the SA and insert an IPsec header (according to IPsec in transport mode). The CE device then sends the IPsec packet to the PE device, and the IPsec packet will then be forwarded using 'normal' IP forwarding accross the SP's network, based on the outer header's IP destination address, that is the destination CE's 'global' (i.e. routable in the SP's realm) IP address. The egress PE device 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 in the outer IP destination address field). The destination CE's IPsec driver 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 will then be further processed in the CE's IP forwarding table and send on the LAN network to the appropriate destination IP device. 6. Deleting an existing VPN site When the VPN customer decides to delete an existing site from a certain VPN, the SP's VPN database must be changed accordingly: - either manually by the SP - or via a "PUSH" operation with the management protocol by the CE device to the VPN database. This will then trigger the distribution of the updated information from the SP's VPN database to the concerned CE devices. The CE device from the deleted site will then terminate the existing Security Associations with its peer CE's using IKE signaling. (Alternatively, the IKE sessions could be just timed out). Note that the CE devices of a certain VPN need to delete the routing entries corresponding with a deleted CE device (i.e. a deleted VPN site) from their corresponding routing/forwarding tables, and announce this change within their site. 7. Quality of Service TBD De Clercq et al. Expires January 2002 [Page 12] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 8. 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 mechanism presented here is highly dependent on the security of 'control channel', used by the management protocol to configure the VPN CE devices. 9. References [FRAMEWORK] Callon, R. et al., "A Framework for Provider Provisioned Virtual Private Networks", draft-ietf-ppvpn-framework-00.txt, Work in progress [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", November 1998, RFC 2409 [IPSEC] Kent and Atkinson, "Security Architecture for the Internet Protocol", November 1998, RFC 2401 [TOUCH] Touch, J. and Eggert, L., "Use of IPSEC transport mode for Virtual Networks", draft-touch-ipsec-vpn-01.txt, Work in progress 10. Authors' Addresses Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: jeremy.de_clercq@alcatel.be Olivier Paridaens Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: olivier.paridaens@alcatel.be Mahadevan Iyer Alcatel Inc 595 Yosemite Blvd, Milpitas, CA Phone: 408 586 7687 E-Mail: mahadevan.iyer@ind.alcatel.com Andrew Krywaniuk Alcatel Networks Corporation 600 March Road Kanata, ON Canada, K2K 2E6 De Clercq et al. Expires January 2002 [Page 13] Internet Draft draft-declercq-ppvpn-ce-based-00.txt July 2001 +1 (613) 784-4237 E-mail: andrew.krywaniuk@alcatel.com De Clercq et al. Expires January 2002 [Page 14]