idnits 2.17.1 draft-guichard-ce-ce-ipsec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 466 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2547], [GRE], [IPSec]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 51, but not defined == Missing Reference: 'IPsec' is mentioned on line 227, but not defined -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC2547' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. 'GRE') ** Obsolete normative reference: RFC 2401 (ref. 'IPSec') (Obsoleted by RFC 4301) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-in-ip-or-gre-00 -- No information found for draft-ietf-ppvpn-ipsec-2547 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PE-PE-IPsec' ** Obsolete normative reference: RFC 2858 (ref. 'MP-BGP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-05 ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2385 (ref. 'BGP-MD5') (Obsoleted by RFC 5925) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Jim Guichard 3 Robert Hanzl 4 Dan Tappan 5 Scott Wainner 6 Cisco Systems, Inc 8 Vic Locicero 9 INFONET Services Corporation 11 IETF Internet Draft 12 Expires: November, 2003 13 Document: draft-guichard-ce-ce-ipsec-00.txt May, 2003 15 CE-CE IPSec within an RFC-2547 Network 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are 21 Working documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes a reference architecture that may be used to 38 tightly integrate CE-CE [IPSec] encryption with the any-to-any 39 connectivity model of [RFC2547]. Using this mechanism, a Service 40 Provider is able to provide an IP VPN service with data encryption 41 between customer edge routers, but without the need of direct routing 42 protocol exchange, or IP-based tunnels such as provided by [GRE]. 44 1 Conventions used in this document 46 Guichard, et. al 1 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 50 this document are to be interpreted as described in [RFC-2119]. 52 1.1 Terminology 54 Several terms used within this document are defined as follows: 56 "Security Gateway" - A router that is a member of a [RFC2547] VPN and 57 serves as a termination point for [IKE] and [IPSec] Security 58 Associations 60 "Security Gateway Identity" - An IPv4 address representing the 61 identity of a router serving as an security gateway for the 62 establishment of [IKE] and [IPSec] Security Associations 64 "Trusted Subnet" - A range of IP addresses represented as a network 65 and mask that a security gateway protects 67 "Security Policy" - A set of policies and attributes used to protect 68 information as described in [IKE] 70 2 Introduction 72 [RFC2547] provides an attractive service architecture that is able to 73 build an any-to-any data path between VPN sites. However, this model 74 does not provide any inherent data encryption services; therefore, 75 customers that wish to encrypt their traffic must do so before it 76 enters the [RFC2547] network. This is typically achieved by enabling 77 [IPSec] encryption and running [IPSec] tunnels between CE routers 78 that belong to the "encrypted" VPN. 80 The deployment of [IPSec] tunnel meshes is analogous to the "overlay" 81 model used in Frame-relay or ATM networks. One of the key success 82 drivers for [RFC2547] is its ability to avoid such topologies, and 83 provide any-to-any connectivity while eliminating pre-configuration 84 of a mesh of CE-to-CE circuits. It is desirable to align the CE-to-CE 85 protection methodologies with the any-to-any connection model 86 provided by [RFC2547] so that the customer experience is seen as the 87 "best of both worlds". This enhanced model supports CE-to-CE data 88 protection while eliminating the requirement for pre-established IP- 89 based tunnels or routing adjacencies between [IPSec] security 90 gateways. 92 Some Service Providers have provided some integration of [RFC2547] 93 and [IPSec] by terminating [IPSec] tunnels into a Virtual Routing & 94 Forwarding Instance (VRF). This solution, although network-based, 95 does not extend [IPSec] between security gateways in different 97 Guichard et. al 2 99 customer sites, and is used more for extending the reach of the 100 Service Provider so that remote customer locations are able to access 101 the VPN. 103 This document provides a mechanism that is able to maintain the any- 104 to-any connectivity nature of [RFC2547], but also enables the dynamic 105 establishment of the CE-CE [IPSec] topology. The [IPSec] security 106 associations established can be thought of as "Security & Forwarding 107 Associations" in the sense that they are used to exchange encrypted 108 data packets between the CE routers; however there is no requirement 109 that they be used to exchange routing information. Thus, the routing 110 scalability property of [RFC2547] is preserved. 112 3 Service Provider Infrastructure Reference Model 114 A Service Provider may deploy an [RFC2547] service using a number of 115 backbone tunneling techniques such as those described in [RFC2547], 116 [MPLS-in-IP], or [PE-PE-IPsec]. [RFC2547] uses a hierarchical routing 117 model that provides scalable distribution of route forwarding 118 attributes. CE-CE [IPsec] encryption, as described within this 119 document, relies upon the IP address partitioning and route 120 forwarding state created by the [RFC2547] infrastructure and it can 121 be deployed independently of the backbone tunneling technique chosen. 122 The CE-CE [IPSec] topology requires a point-to-point relationship 123 between CE's for data protection; however, the routing plane 124 associated with the CE-CE topology leverages the [RFC2547] 125 hierarchical routing model. 127 4 Coupling of CE Security Policy and PE Routing Planes 129 Each CE router ascertains through configuration, or other means 130 outside the scope of this document, whether it is used as a [IPsec] 131 security gateway. Once this information is discovered, the CE router 132 MUST advertise it's "Security Gateway Identity" used for [IKE] and 133 [IPSec] peer end-point termination to the PE router using [BGP-4]. 134 The identity must be associated with each 'trusted subnet' 135 represented as a prefix that the CE router protects. The identity 136 will typically be an IPv4 address where the [IKE] and [IPSec] 137 authentication and encryption services will be established. The PE 138 router MUST then use [MP-BGP] to advertise the trusted subnet 139 prefixes and the associated identity information to other PE routers. 141 A PE router that receives this information via [MP-BGP] MUST be able 142 to (a) identify which VPN the prefix and security gateway identity 143 end-point is associated with, and (b) advertise that information to 144 any security gateway CE routers that belong to the VPN. 145 Identification of which VPN the update belongs to is determined by 147 Guichard et. al 3 149 the "route-target" extended-community attribute as described in 150 [RFC2547]. 152 5 Distribution of [IPSec] Security Gateway End-points 154 A CE router MAY send encrypted and non-encrypted traffic toward the 155 PE router for delivery to other members of its VPN. A CE router that 156 belongs to an "encrypted" VPN needs to be able to build a Security 157 Association (SA) with any remote CE router that also belongs to the 158 same VPN, and is a member of the encryption service. 160 When traffic that needs to be encrypted is sent from a CE router that 161 belongs to an "encrypted" VPN, the CE router MUST be able to 162 establish a Security Association (SA) with the remote CE router 163 through which the destination of the incoming packet is reachable. To 164 achieve this aim, the CE router needs to discover the remote peer's 165 trusted subnet prefix and the associated security gateway identity of 166 the peer, and then build the [IKE] and [IPSec] security association. 168 Discovery of the end-point addresses is achieved through direct [BGP- 169 4] exchange with the PE router. If [BGP-4] is not established with 170 the customer site, then a different discovery protocol is necessary 171 and is outside the scope of this draft. 173 Many [RFC2547] deployments use [BGP-4] on the PE-CE links. Typically 174 these sessions only carry standard [BGP-4] attributes. In order to 175 use the mechanisms described within this document, the CE router MUST 176 support the capabilities as specified in [EXTCOM]. 178 When a CE router advertises routes from an "encrypted" VPN into the 179 backbone it MUST attach a new BGP extended-community attribute, 180 hereby referred to as the "Security Gateway Identity" attribute, to 181 all trusted subnet prefixes for which encryption is desired. A PE 182 router that receives such an update MUST export those trusted subnet 183 prefixes along with the "Security Gateway Identify" attribute. 185 A PE router that receives the update MUST advertise the trusted 186 subnet prefixes and security gateway identities to any relevant CE 187 routers that are (a) members of the "encrypted" VPN, and (b) are 188 running [BGP-4] with the PE router. 190 6 BGP "Security Gateway Identity" Extended-community Attribute 192 The Extended Community Attribute is a transitive optional BGP 193 attribute, with type code 16, as specified in [EXTCOM]. The solution 194 described within this document proposes to use the Opaque Extended 195 Community, as specified in section 6.4 of [EXTCOM]. The format of 196 this community is as follows: 198 Guichard et. al 4 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | 0x03 or 0x43 | Sub-Type (TBD)| Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | IP Address | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 The value of the high-order octet of this extended type is either 209 0x03 or 0x43. The low-order octet of this extended type carries the 210 sub-type with value (TBD) and indicates that this is a "Security 211 Gateway Identity". 213 The value field consists of: 215 Reserved - 2 octets 217 Reserved for future use and should be set to 0x0000 219 IP Address - 4 octets 221 Security Gateway IP address 223 7 CE-router IPSec requirements 225 A CE router that wishes to belong to an "encrypted" VPN, and use the 226 mechanisms described within this document, MUST conform to the 227 procedures described in [IPsec]. This means that the CE router MUST 228 provide a Security Policy Database (SPD), as described in section 229 4.4.1 of [IPSec], which is used to determine the disposition of all 230 IP traffic inbound or outbound from the router. Each entry within the 231 database specifies whether traffic matching the policy should bypass 232 IPsec processing, be discarded, or be subject to IPSec processing. 234 A CE router MUST provide the ability to specify "Selectors", as 235 described in section 4.4.2 of [IPSec]. These are a set of IP and 236 upper layer protocol field values that are used by the Security 237 Policy Database (SPD) to map traffic to a Security Association (SA). 239 The Security Policy Database and Selector attributes MUST be 240 populated with the "Security Gateway Identity" and the associated 241 "trusted subnet" prefixes. The population of the SPD from [BGP-4] may 242 be an automated process with the appropriate [BGP-4] controls 243 provided by the CE. 245 Each CE router MUST enable the creation of security associations in 246 the Security Association Database (SAD), as described in section 247 4.4.3 of [IPSec], that contains parameters derived by traffic 249 Guichard et. al 5 251 matching the [BGP-4] injected Selectors in the SPD. This database is 252 used to determine what [IPSec] services are offered to IP packets. 254 7.1 CE-CE Security Association Setup using IKE 256 A CE router MUST support an automated Security Association/Key 257 management protocol for the purpose of establishing and maintaining 258 Security Associations between two [IPSec] peer end-points. One 259 example of such a protocol is [IKE]. 261 There are several options available to the CE routers with respect to 262 IPsec tunnel setup and encryption of traffic: 264 CE-CE authentication and/or encryption of selective packets 265 based on traffic flow initiated establishment of security 266 associations 268 CE-CE authentication and/or encryption of selective packets 269 based on pre-established [IPSec] security associations 271 Each of these options is described in the following sections. 272 Regardless of which option is used, on receipt of traffic that is 273 matched to an SPD policy that requires [IPSec] processing, a CE 274 router MUST check whether a Security Association (SA) already exists 275 with the [IPSec] Security Gateway address. If an SA already exists, 276 then the CE router can encrypt the traffic and forward it toward the 277 PE router. If no SA exists, the CE router MUST use [IKE] or similar 278 protocol to establish the SA with the security gateway identity. 280 7.1.1 CE-CE encryption of selective packets based on traffic flow 282 CE-CE encryption may be driven by traffic flow and a CE router MAY 283 choose to selectively encrypt packets based on a 'Selector' match. On 284 receipt of a packet that is matched by the CE router's SPD for 285 encryption, the CE router MUST be able to establish an SA with the 286 remote CE router through which the destination is reachable. 288 As the CE router is running [BGP-4] with the PE router, it can 289 dynamically build the 'Selector' criteria based on receipt of routing 290 updates that carry the "Security Gateway Identity" attribute. Using 291 this information, the CE router is able to identify which routes are 292 associated with a remote site, and also which of these routes need 293 encryption. For the routes that need encryption, the CE is able to 294 determine the "Security Gateway Identity" associated with those 295 routes. 297 The CE MAY dynamically establish [IPSec] SA's between the CE and PE 298 routers. These [IPSec] tunnels may be used to protect the [BGP-4] 299 exchange of 'Trusted Subnets' and 'Security Gateway Identities' 301 Guichard et. al 6 303 between the PE and CE. Alternatively, the CE and PE routers MAY use 304 [BGP-MD5] on the [BGP-4] session to authenticate the prefixes and the 305 associated "Security Gateway Identity". 307 7.1.2 CE-CE Encryption with pre-established IPSec Security 308 Associations 310 A CE router MAY choose to pre-establish [IPSec] tunnels between CE 311 routers. [IPSec] SA's may be established automatically upon 312 population of the SPD that occurs upon receipt of a 'Trusted Subnet' 313 prefix with a valid "Security Gateway Identity". The CE router MUST 314 encrypt all traffic destined to a route via the established [IPSec] 315 security association. 317 The CE MAY have pre-established [IPSec] SA's between the CE and PE 318 routers. These [IPSec] tunnels may be used to protect the [BGP-4] 319 exchange of 'Trusted Subnets' and 'Security Gateway Identities' 320 between the PE and CE. Alternatively, the CE and PE routers MAY use 321 [BGP-MD5] on the [BGP-4] Session to authenticate the prefixes and the 322 associated "Security Gateway Identity". 324 8 References 326 [RFC2547], Rosen, E. et al., "BGP/MPLS VPNs", draft-ietf-ppvpn- 327 rfc2547bis-03, October, 2002. 329 [GRE], Li, T. et al, "Generic Routing Encapsulation (GRE)", RFC 1701, 330 October, 1994. 332 [IPSec], Kent and Atkinson, "Security Architecture for the Internet 333 Protocol", RFC 2401, November 1998. 335 [MPLS-in-IP], Rosen E. et al., "Encapsulating MPLS in IP or GRE", 336 draft-ietf-mpls-in-ip-or-gre-00, January, 2003. 338 [PE-PE-IPsec], Rosen E. et al., "Use of PE-PE IPsec in RFC2547 VPNs", 339 draft-ietf-ppvpn-ipsec-2547-03, February, 2003. 341 [MP-BGP], Rekhter, Y. et al., "Multiprotocol Extensions for BGP-4", 342 RFC 2858, June, 2000. 344 [BGP-4], Rekhter, Y. et al., "A Border Gateway Protocol 4 (BGP-4)", 345 RFC 1771, March, 1995. 347 [EXTCOM], Tappan, D. et al., "BGP Extended Communities Attribute", 348 draft-ietf-idr-bgp-ext-communities-05, May, 2002. 350 [IKE], Harkins, D. et al., "The Internet Key Exchange (IKE)", RFC 351 2409, November, 1998. 353 Guichard et. al 7 355 [BGP-MD5], Heffernan, A., "Protection of BGP Sessions via the TCP MD5 356 Signature Option", RFC 2385, August 1998. 358 9 Authors' Address 360 Jim Guichard 361 Cisco Systems, Inc. 362 1414 Massachusetts Avenue 363 Boxborough, MA, 01719 364 Email : jguichar@cisco.com 366 Robert Hanzl 367 Cisco Systems, Inc. 368 1414 Massachusetts Avenue 369 Boxborough, MA, 01719 370 Email : rhanzl@cisco.com 372 Dan Tappan 373 Cisco Systems, Inc. 374 1414 Massachusetts Avenue 375 Boxborough, MA, 01719 376 Email : tappan@cisco.com 378 Scott Wainner 379 Cisco Systems, Inc. 380 13600 Dulles Technology Drive 381 Herndon 382 Virginia, 20171 383 Email : swainner@cisco.com 385 Vic Locicero 386 INFONET Services Corporation 387 2160 E. Grand Ave. 388 El Segudo, CA 90245 389 Email : vic_locicero@infonet.com 391 Guichard et. al 8