Internet Engineering Task Force B. Gleeson INTERNET DRAFT Nortel Networks Expires August 2001 Uses of IPsec with Provider Provisioned VPNs 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft gives a brief overview of some scenarios where IPsec [1] can be used as a tunneling mechanism in the context of provider provisioned virtual private networks (PPVPNs). It also suggests some areas where extensions to IPsec could be considered. Table of Contents 1.0 Introduction ................................................ 2 2.0 VPN Reference Model ......................................... 2 2.1 CE to PE IPsec tunnels ...................................... 3 2.2 PE to PE IPsec tunnels ...................................... 4 2.3 CE to CE IPsec tunnels ...................................... 5 3.0 Extensions to IPsec ......................................... 6 3.1 Routing over IPsec tunnels .................................. 6 3.2 Associating an IPsec tunnel with a VPN ...................... 8 Gleeson [Page 1] INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001 4.0 References .................................................. 9 5.0 Author Information .......................................... 10 6.0 Full Copyright Statement .................................... 10 1.0 Introduction This draft gives a brief overview of some scenarios where IPsec can be used as a tunneling mechanism in the context of provider provisioned virtual private networks (PPVPNs). It also suggests some areas where extensions to IPsec could be considered. In this draft IPsec tunnels are viewed as a tunneling mechanism that can be used in a variety of different types of VPNs, either by themselves or in combination with other tunneling mechanisms. Thus there is no single type of VPN that is called an "IPsec VPN", and this term is not used. 2.0 VPN Reference Diagram The following diagram shows the VPN reference model used in this draft. A more detailed description of this reference model, and more information on the use of PPVPNs and the mechanisms that can be used to implement PPVPNs can be found in [2]. Details on the service requirements for PPVPNs can be found in [3]. Gleeson [Page 2] INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001 +---+ +---+ | P |....| P | +---+ +---+ | | +----+ +----+ +----+ +---+ | CE |----| PE | | PE |--|CE | +----+ +----+ +----+ +---+ | | +---+ +---+ | P |....| P | +---+ +---+ <=========> CE to PE <======================> PE to PE <========================================> CE to CE PE - provider edge device P - VPN unaware provider core device CE - customer edge device (may be managed by provider) Figure 1 - VPN Reference Model The following scenarios are considered for use of IPsec tunnels: - between CE and PE - between PE and PE - between CE and CE Note that the options are not mutually exclusive, instead they may be combined as necessary. 2.1 CE to PE IPsec tunnels The primary use of CE to PE IPsec tunnels is where the customer site is connected to the provider backbone via an insecure access network (e.g. the Internet). Different deployment scenarios are possible, for example the CE device could be a router in a customer network, or could be a host computer performing voluntary tunneling with IPsec alone, or could be a host computer running IPsec to secure a PPP/L2TP session. All the standard IPsec features for authentication and Gleeson [Page 3] INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001 encryption can be used without modification in this scenario. Note that the initial IPsec specifications did not fully specify the use of Diffserv with IPsec tunnels, but this issue has subsequently been addressed in [8]. CE to PE IPsec tunnels can be used with network based layer-3 VPNs and (some types of) network based layer-2 VPNs. In either case the PE router terminates the IPsec tunnel, and for traffic received over the tunnel extracts a packet or frame to be forwarded. For a layer-3 VPN this will be an IP packet and will be forwarded according to a per- VPN IP forwarding table using IP address information in the packet. For a layer-2 transparent LAN VPN service, an ethernet frame (perhaps encapsulated in GRE / IP / IPsec) can be extracted and forwarded according to a per-VPN bridge forwarding table using MAC address information in the frame. Similarly traffic in the reverse direction is sent to the customer site across the IPsec tunnel as a result of a lookup on the per-VPN IP or bridge forwarding table (or when MPLS is used as the backbone technology the outgoing IPsec interface may be identified by means of an MPLS label, avoiding any forwarding table lookup). One area that may benefit from standardization is the case where a routing protocol is run over the IPsec tunnel, in order to support multi-homing of CE devices for the purpose of redundancy. This is discussed further in section 3.1 below. 2.2 PE to PE IPsec tunnels PE to PE IPsec tunnels may be used by a provider to provide strong security in deployment scenarios where untrusted equipment or links lie in the path between two PEs. For example if a service provider owns and administers the PE routers, but does not own and administer all of the P routers and the layer-2 and layer-1 infrastructure that interconnects the PE routers, the VPN service provider may wish to employ strong security for the PE to PE tunnels. The VPN service provider is then solely responsible for the security of the customer traffic, no matter if parts of the network infrastructure have been outsourced to other providers. Where a service provider views the PE to PE paths as inherently secure, either because the provider owns all the backbone infrastructure and the entire network is deemed secure, or where the pieces of the backbone outsourced to another provider are viewed as secure (perhaps SONET/SDH circuits, wavelengths or fibers, then there is no need to additionally secure the PE to PE traffic via IPsec. Independently of the issue of securing customer data traffic between two PEs, is the need for one PE to know that a PE with which it is Gleeson [Page 4] INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001 establishing tunnels is a valid PE. The set of valid peer PEs may be configured via a secure network management channel in which case there is no need to dynamically authenticate a remote PE. However in some cases it may be useful to be dynamically authenticate a remote PE using IKE [4]. For example if a dynamic VPN membership protocol is being used in a scenario where a VPN may span two or more service providers, the use of dynamic PE authentication removes the need for each provider to maintain lists of valid PEs in all the other provider domains. Another aspect of the use PE to PE IPsec tunnels is that with certain VPN approaches it is useful to be able to use IPsec solely as a signaling protocol for IP tunnels, and not to provide any security. For example if an IPsec tunnel is established that uses the null encryption algorithm and no authentication, then no security is being provided, but such a mechanism may still be useful as it allows the dynamic establishment of an IP tunnel with an authenticated peer, and allows that tunnel to be associated with a specific VPN. The IPsec specifications expressly prohibit the establishment of an IPsec tunnel that uses neither encryption or authentication, as in the classical use of IPsec this mode makes little sense, but in the context of VPNs this restriction is unnecessary. PE to PE IPsec tunnels can be used with any type of network based VPN. With a layer-3 VPN IP packets are forwarded between PEs over the IPsec tunnels, and with a layer-2 VPN frames can be encapsulated (e.g. using GRE) and then sent over the IPsec tunnels. An IPsec tunnel itself could be nested on top of an MPLS LSP. One area that may benefit from standardization is a mechanism to allow an IPsec tunnel to be associated with a particular VPN. This is discussed further below in section 3.2. 2.3 CE to CE IPsec tunnels CE to CE IPsec tunnels can always be used between IPsec capable CE devices, independently of the method used to interconnect the two CEs. For example the intervening network could be the Internet, a provider IP backbone, a layer-2 network based VPN or a layer-3 network based VPN. Standard IPsec can be used with no modifications to provide strong security across the intervening network. From an administrative point of view, the CE devices can be managed either by the customer or by the provider on behalf of the customer, but from a technical point of view the operation of the devices is the same in either case. Gleeson [Page 5] INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001 In order for a CE device to use IPsec tunnels, it is necessary for the CE to maintain a mapping between a set of IP destinations and a remote IPsec tunnel endpoint along with a set of security attributes (e.g. encryption algorithm to use) for the tunnel. If configuration is done at the device level this is a significant amount of configuration, as any time a new CE is added to the network the mapping tables need to be updated such that all the old CEs learn about the mappings needed for the IP destinations behind the new CE, and the new CE learns about the mappings needed for the IP destinations behind all the existing CEs. Where all the CEs are made by the same vendor, vendor-specific network management systems are commonly used to reduce the configuration burden, as such an NMS can take a network-wide view and configure each CE appropriately. Work is progressing in the IPSP WG of the IETF on standard ways of configuring IPsec on devices using a policy or management information base [5] and work is also being done in this area by the Distributed Management Task Force (DMTF) [9]. In some cases it is possible to simplify or automate the maintenance of the IPsec mapping tables by gathering information from any routing protocols running on the CE. For example for CE to CE IPsec tunnels running over a layer-2 VPN, the necessary mappings can be gleaned from route table information (i.e. IP destinations and their associated next-hops). 3.0 Extensions to IPsec This section looks at areas where extensions to IPsec may be useful within the context of PPVPNs. 3.1 Routing over IPsec tunnels Consider the case where a customer site is multi-homed to the provider network as follows: Gleeson [Page 6] INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001 +----+ +----+ +---+ --- | CE |----| PE |-----| P |.... | +----+ +----+ +---+ | | | +---+ | +----------+ | C |--| | | +---+ | +-------+ | | | | | +----+ +----+ +---+ --- | CE |----| PE |-----| P |.... +----+ +----+ +---+ Figure 2 - Routing over IPsec tunnels The customer host C is reachable via two CE devices, each of which is attached to two PEs. This provides for redundancy and allows for connectivity to host C despite any single point of failure of a PE, CE, or CE to PE link. A typical scenario would be to run routing across the PE to CE links. This allows the failure of any device or link to be dynamically detected, and for rerouting to occur onto a new path. This capability is needed independently of the type of PE to CE link, which could be an ATM or FR circuit, for example, or in the case considered here, an IPsec tunnel. In classical IPsec when an IPsec tunnel is created the set of IP packets that will subsequently traverse the tunnel are specified when the security association (SA) is created. This is done via the optional client identifier payloads in a Quick Mode message. However in general when routing is run over a link the set of IP packets that will subsequently traverse the link is not known at SA establishment time. Instead this is determined by the operation of the routing protocol itself. There is thus a need to be able to represent the semantics of 'wildcard' when establishing an SA. There is no standard way of specifying this. If the client identifiers are omitted this has the semantics of specifying that only packets that originate or terminate on the CE or PE will be carried over the tunnel, and that no transit traffic will be carried. Different proprietary solutions have been implemented to solve this issue. In classical IPsec, the process of deciding which packets get sent over an IPsec tunnel is modeled as applying an IPsec-specific packet filter to all packets that traverse a given IP interface. In contrast in the scenario described above the IPsec tunnel itself is modeled as an IP interface that is visible to routing, just like any other interface. The process of deciding which packets get sent over an IPsec tunnel is the result of standard IP forwarding, typically in Gleeson [Page 7] INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001 association with service independent packet classification (which may be application specific), and firewall and route filtering functionality. As the IPsec architecture specification [6] itself states, the model described in that document is a nominal model, not a specification of the internal structure of an implementation. Other models, such as the one described above are equally valid, but in the past this has caused confusion due to too literal an interpretation of the model described in [6]. 3.2 Associating an IPsec tunnel with a VPN Consider the case where a layer-3 VPN service is being provided and IPsec tunnels are being used between two PEs, as in the following diagram. 10.0.1.1 10.0.2.1 +----+ +----+ | CE1|====== ======| CE2| +----+ | | +----+ | SA for VPN A | +----+===============+----+ | PE1| | PE2| +----+\\\\\\\\\\\\\\\+----+ | SA for VPN B | +----+ | | +----+ | CE3|\\\\\\ \\\\\\| CE4| +----+ +----+ 10.0.1.1 10.0.2.1 CE1 and CE2 are in VPN A CE3 and CE4 are in VPN B Figure 3 - VPN specific SAs The PEs need to establish two IPsec tunnels, one for VPN A and one for VPN B. VPN A and VPN B use the same private address space of 10.0.0.0/8. In this case it is necessary to be able to associate an IPsec tunnel, and associated SAs, with a particular VPN. An identification of the VPN needs to be included as part of IKE signaling, such that an incoming SA establishment request can be matched with the appropriate VPN. Gleeson [Page 8] INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001 One method of doing this has been described in [7], which defined a new Domain of Interpretation (DOI) for VPNs. Another scheme is to define a new ISAKMP payload - a VPN identifier payload - and to include this as an additional payload in the first and second messages of a Quick Mode exchange. This allows the Quick Mode messages, and the SAs created as a result, to be associated with a particular VPN. 4.0 References [1] The set of RFCs 2401-2412, 2085, 2104 and 2451. [2] Callon, R. et al, "A Framework for Provider Provisioned Virtual Private Networks", , February 2001. [3] [4] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [5] Li, M. et al, "IPSec Policy Information Base", , November 2000. [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [7] Lordello, C. et al, "VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP", , August, 2000 [8] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000 [9] Lortz, V. et al, "IPsec Policy Model", http://www.dmtf.org/spec/Whitepapers/DSP0118.doc, November 2000 Gleeson [Page 9] INTERNET DRAFT Uses of IPsec with PPVPNs February, 2001 5.0 Author Information Bryan Gleeson Nortel Networks 2305 Mission College Blvd Santa Clara CA 95054 USA Tel: +1 (408) 565-2625 Email: bgleeson@nortelnetworks.com 6.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Gleeson [Page 10]