Jim Guichard Robert Hanzl Dan Tappan Scott Wainner Cisco Systems, Inc Vic Locicero INFONET Services Corporation IETF Internet Draft Expires: November, 2003 Document: draft-guichard-ce-ce-ipsec-00.txt May, 2003 CE-CE IPSec within an RFC-2547 Network 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 document describes a reference architecture that may be used to tightly integrate CE-CE [IPSec] encryption with the any-to-any connectivity model of [RFC2547]. Using this mechanism, a Service Provider is able to provide an IP VPN service with data encryption between customer edge routers, but without the need of direct routing protocol exchange, or IP-based tunnels such as provided by [GRE]. 1 Conventions used in this document Guichard, et. al 1 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 1.1 Terminology Several terms used within this document are defined as follows: "Security Gateway" - A router that is a member of a [RFC2547] VPN and serves as a termination point for [IKE] and [IPSec] Security Associations "Security Gateway Identity" - An IPv4 address representing the identity of a router serving as an security gateway for the establishment of [IKE] and [IPSec] Security Associations "Trusted Subnet" - A range of IP addresses represented as a network and mask that a security gateway protects "Security Policy" - A set of policies and attributes used to protect information as described in [IKE] 2 Introduction [RFC2547] provides an attractive service architecture that is able to build an any-to-any data path between VPN sites. However, this model does not provide any inherent data encryption services; therefore, customers that wish to encrypt their traffic must do so before it enters the [RFC2547] network. This is typically achieved by enabling [IPSec] encryption and running [IPSec] tunnels between CE routers that belong to the "encrypted" VPN. The deployment of [IPSec] tunnel meshes is analogous to the "overlay" model used in Frame-relay or ATM networks. One of the key success drivers for [RFC2547] is its ability to avoid such topologies, and provide any-to-any connectivity while eliminating pre-configuration of a mesh of CE-to-CE circuits. It is desirable to align the CE-to-CE protection methodologies with the any-to-any connection model provided by [RFC2547] so that the customer experience is seen as the "best of both worlds". This enhanced model supports CE-to-CE data protection while eliminating the requirement for pre-established IP- based tunnels or routing adjacencies between [IPSec] security gateways. Some Service Providers have provided some integration of [RFC2547] and [IPSec] by terminating [IPSec] tunnels into a Virtual Routing & Forwarding Instance (VRF). This solution, although network-based, does not extend [IPSec] between security gateways in different Guichard et. al 2 customer sites, and is used more for extending the reach of the Service Provider so that remote customer locations are able to access the VPN. This document provides a mechanism that is able to maintain the any- to-any connectivity nature of [RFC2547], but also enables the dynamic establishment of the CE-CE [IPSec] topology. The [IPSec] security associations established can be thought of as "Security & Forwarding Associations" in the sense that they are used to exchange encrypted data packets between the CE routers; however there is no requirement that they be used to exchange routing information. Thus, the routing scalability property of [RFC2547] is preserved. 3 Service Provider Infrastructure Reference Model A Service Provider may deploy an [RFC2547] service using a number of backbone tunneling techniques such as those described in [RFC2547], [MPLS-in-IP], or [PE-PE-IPsec]. [RFC2547] uses a hierarchical routing model that provides scalable distribution of route forwarding attributes. CE-CE [IPsec] encryption, as described within this document, relies upon the IP address partitioning and route forwarding state created by the [RFC2547] infrastructure and it can be deployed independently of the backbone tunneling technique chosen. The CE-CE [IPSec] topology requires a point-to-point relationship between CE's for data protection; however, the routing plane associated with the CE-CE topology leverages the [RFC2547] hierarchical routing model. 4 Coupling of CE Security Policy and PE Routing Planes Each CE router ascertains through configuration, or other means outside the scope of this document, whether it is used as a [IPsec] security gateway. Once this information is discovered, the CE router MUST advertise it's "Security Gateway Identity" used for [IKE] and [IPSec] peer end-point termination to the PE router using [BGP-4]. The identity must be associated with each 'trusted subnet' represented as a prefix that the CE router protects. The identity will typically be an IPv4 address where the [IKE] and [IPSec] authentication and encryption services will be established. The PE router MUST then use [MP-BGP] to advertise the trusted subnet prefixes and the associated identity information to other PE routers. A PE router that receives this information via [MP-BGP] MUST be able to (a) identify which VPN the prefix and security gateway identity end-point is associated with, and (b) advertise that information to any security gateway CE routers that belong to the VPN. Identification of which VPN the update belongs to is determined by Guichard et. al 3 the "route-target" extended-community attribute as described in [RFC2547]. 5 Distribution of [IPSec] Security Gateway End-points A CE router MAY send encrypted and non-encrypted traffic toward the PE router for delivery to other members of its VPN. A CE router that belongs to an "encrypted" VPN needs to be able to build a Security Association (SA) with any remote CE router that also belongs to the same VPN, and is a member of the encryption service. When traffic that needs to be encrypted is sent from a CE router that belongs to an "encrypted" VPN, the CE router MUST be able to establish a Security Association (SA) with the remote CE router through which the destination of the incoming packet is reachable. To achieve this aim, the CE router needs to discover the remote peer's trusted subnet prefix and the associated security gateway identity of the peer, and then build the [IKE] and [IPSec] security association. Discovery of the end-point addresses is achieved through direct [BGP- 4] exchange with the PE router. If [BGP-4] is not established with the customer site, then a different discovery protocol is necessary and is outside the scope of this draft. Many [RFC2547] deployments use [BGP-4] on the PE-CE links. Typically these sessions only carry standard [BGP-4] attributes. In order to use the mechanisms described within this document, the CE router MUST support the capabilities as specified in [EXTCOM]. When a CE router advertises routes from an "encrypted" VPN into the backbone it MUST attach a new BGP extended-community attribute, hereby referred to as the "Security Gateway Identity" attribute, to all trusted subnet prefixes for which encryption is desired. A PE router that receives such an update MUST export those trusted subnet prefixes along with the "Security Gateway Identify" attribute. A PE router that receives the update MUST advertise the trusted subnet prefixes and security gateway identities to any relevant CE routers that are (a) members of the "encrypted" VPN, and (b) are running [BGP-4] with the PE router. 6 BGP "Security Gateway Identity" Extended-community Attribute The Extended Community Attribute is a transitive optional BGP attribute, with type code 16, as specified in [EXTCOM]. The solution described within this document proposes to use the Opaque Extended Community, as specified in section 6.4 of [EXTCOM]. The format of this community is as follows: Guichard et. al 4 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 or 0x43 | Sub-Type (TBD)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the high-order octet of this extended type is either 0x03 or 0x43. The low-order octet of this extended type carries the sub-type with value (TBD) and indicates that this is a "Security Gateway Identity". The value field consists of: Reserved - 2 octets Reserved for future use and should be set to 0x0000 IP Address - 4 octets Security Gateway IP address 7 CE-router IPSec requirements A CE router that wishes to belong to an "encrypted" VPN, and use the mechanisms described within this document, MUST conform to the procedures described in [IPsec]. This means that the CE router MUST provide a Security Policy Database (SPD), as described in section 4.4.1 of [IPSec], which is used to determine the disposition of all IP traffic inbound or outbound from the router. Each entry within the database specifies whether traffic matching the policy should bypass IPsec processing, be discarded, or be subject to IPSec processing. A CE router MUST provide the ability to specify "Selectors", as described in section 4.4.2 of [IPSec]. These are a set of IP and upper layer protocol field values that are used by the Security Policy Database (SPD) to map traffic to a Security Association (SA). The Security Policy Database and Selector attributes MUST be populated with the "Security Gateway Identity" and the associated "trusted subnet" prefixes. The population of the SPD from [BGP-4] may be an automated process with the appropriate [BGP-4] controls provided by the CE. Each CE router MUST enable the creation of security associations in the Security Association Database (SAD), as described in section 4.4.3 of [IPSec], that contains parameters derived by traffic Guichard et. al 5 matching the [BGP-4] injected Selectors in the SPD. This database is used to determine what [IPSec] services are offered to IP packets. 7.1 CE-CE Security Association Setup using IKE A CE router MUST support an automated Security Association/Key management protocol for the purpose of establishing and maintaining Security Associations between two [IPSec] peer end-points. One example of such a protocol is [IKE]. There are several options available to the CE routers with respect to IPsec tunnel setup and encryption of traffic: CE-CE authentication and/or encryption of selective packets based on traffic flow initiated establishment of security associations CE-CE authentication and/or encryption of selective packets based on pre-established [IPSec] security associations Each of these options is described in the following sections. Regardless of which option is used, on receipt of traffic that is matched to an SPD policy that requires [IPSec] processing, a CE router MUST check whether a Security Association (SA) already exists with the [IPSec] Security Gateway address. If an SA already exists, then the CE router can encrypt the traffic and forward it toward the PE router. If no SA exists, the CE router MUST use [IKE] or similar protocol to establish the SA with the security gateway identity. 7.1.1 CE-CE encryption of selective packets based on traffic flow CE-CE encryption may be driven by traffic flow and a CE router MAY choose to selectively encrypt packets based on a 'Selector' match. On receipt of a packet that is matched by the CE router's SPD for encryption, the CE router MUST be able to establish an SA with the remote CE router through which the destination is reachable. As the CE router is running [BGP-4] with the PE router, it can dynamically build the 'Selector' criteria based on receipt of routing updates that carry the "Security Gateway Identity" attribute. Using this information, the CE router is able to identify which routes are associated with a remote site, and also which of these routes need encryption. For the routes that need encryption, the CE is able to determine the "Security Gateway Identity" associated with those routes. The CE MAY dynamically establish [IPSec] SA's between the CE and PE routers. These [IPSec] tunnels may be used to protect the [BGP-4] exchange of 'Trusted Subnets' and 'Security Gateway Identities' Guichard et. al 6 between the PE and CE. Alternatively, the CE and PE routers MAY use [BGP-MD5] on the [BGP-4] session to authenticate the prefixes and the associated "Security Gateway Identity". 7.1.2 CE-CE Encryption with pre-established IPSec Security Associations A CE router MAY choose to pre-establish [IPSec] tunnels between CE routers. [IPSec] SA's may be established automatically upon population of the SPD that occurs upon receipt of a 'Trusted Subnet' prefix with a valid "Security Gateway Identity". The CE router MUST encrypt all traffic destined to a route via the established [IPSec] security association. The CE MAY have pre-established [IPSec] SA's between the CE and PE routers. These [IPSec] tunnels may be used to protect the [BGP-4] exchange of 'Trusted Subnets' and 'Security Gateway Identities' between the PE and CE. Alternatively, the CE and PE routers MAY use [BGP-MD5] on the [BGP-4] Session to authenticate the prefixes and the associated "Security Gateway Identity". 8 References [RFC2547], Rosen, E. et al., "BGP/MPLS VPNs", draft-ietf-ppvpn- rfc2547bis-03, October, 2002. [GRE], Li, T. et al, "Generic Routing Encapsulation (GRE)", RFC 1701, October, 1994. [IPSec], Kent and Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [MPLS-in-IP], Rosen E. et al., "Encapsulating MPLS in IP or GRE", draft-ietf-mpls-in-ip-or-gre-00, January, 2003. [PE-PE-IPsec], Rosen E. et al., "Use of PE-PE IPsec in RFC2547 VPNs", draft-ietf-ppvpn-ipsec-2547-03, February, 2003. [MP-BGP], Rekhter, Y. et al., "Multiprotocol Extensions for BGP-4", RFC 2858, June, 2000. [BGP-4], Rekhter, Y. et al., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March, 1995. [EXTCOM], Tappan, D. et al., "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-05, May, 2002. [IKE], Harkins, D. et al., "The Internet Key Exchange (IKE)", RFC 2409, November, 1998. Guichard et. al 7 [BGP-MD5], Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. 9 Authors' Address Jim Guichard Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 Email : jguichar@cisco.com Robert Hanzl Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 Email : rhanzl@cisco.com Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 Email : tappan@cisco.com Scott Wainner Cisco Systems, Inc. 13600 Dulles Technology Drive Herndon Virginia, 20171 Email : swainner@cisco.com Vic Locicero INFONET Services Corporation 2160 E. Grand Ave. El Segudo, CA 90245 Email : vic_locicero@infonet.com Guichard et. al 8