idnits 2.17.1 draft-declercq-bgp-ipsec-vpn-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 369 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([RFC2547], [RFC2547bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 19 has weird spacing: '...d is in full ...' == Line 27 has weird spacing: '...-Drafts may ...' == Line 29 has weird spacing: '... Drafts as r...' == Line 38 has weird spacing: '...e check the...' == Line 39 has weird spacing: '...listing conta...' == (364 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (February 2001) is 8470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Duplicate reference: RFC2547, mentioned in 'RFC2547bis', was also mentioned in 'RFC2547'. ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1966 (ref. 'BGP-RR') (Obsoleted by RFC 4456) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-EXTCOMM' ** Obsolete normative reference: RFC 2283 (ref. 'BGP-MP') (Obsoleted by RFC 2858) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-RFSH' -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-ORF' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jeremy De Clercq 3 Internet Draft Yves T'Joens 4 Expiration Date: August 2001 Olivier Paridaens 5 Alcatel 7 Chandru Sargor 8 Vijay Srinivasan 9 CoSine Communications 11 February 2001 13 BGP/IPsec VPN 15 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. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months. Internet-Drafts may be updated, replaced, or obsoleted by 28 other documents at any time. It is not appropriate to use Internet- 29 Drafts as reference material or to cite them other than as a 30 ``working draft'' or ``work in progress.'' 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 To view the entire list of current Internet-Drafts, please check the 39 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 40 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 41 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific 42 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 44 Distribution of this memo is unlimited. 46 Abstract 48 This document describes a method by which a Service Provider may use 49 an IP backbone to provide VPNs for its customers. In this method 50 IPsec tunnels are deployed through the backbone, and the forwarding 51 of packets over the backbone relies on normal IP forwarding. BGP is 52 used for distributing (private) routes over the backbone. 54 This model is based on the model described in RFC 2547 [RFC2547], and 55 the internet-draft that obsoletes it [RFC2547bis]. The main 56 difference is that in this model IPsec is used as tunneling mechanism 57 instead of MPLS. 59 The purpose of extending on the procedures defined in [RFC2547], is 60 to offer an increased level of security by building upon the 61 authentication and encryption services of IPsec, particularly for 62 interdomain VPN operation, while it has the added benefit that no PE 63 to PE MPLS backbone is required. 65 Note however that the model does not exclude the use of MPLS in 66 segments of the backbone to improve on traffic engineering and/or QoS 67 aspects. 69 Table of Contents 71 1 Introduction .............................................. 4 72 1.1 Motivation ................................................ 4 73 1.2 Virtual Private Networks .................................. 4 74 1.3 Edge Devices .............................................. 5 75 1.4 Multiple Routing and Forwarding Instances in PEs .......... 5 76 1.5 VPNs with Overlapping Address Spaces ...................... 6 77 1.6 VPNs with Different Routes to the Same System ............. 6 78 1.7 SP Backbone Routers ....................................... 7 79 1.8 Security .................................................. 7 80 1.9 Using IPsec in the Backbone ............................... 7 81 2 Sites and CEs ............................................. 8 82 3 VPN Routing and Forwarding Instances ...................... 8 83 4 The VPN-SPI ............................................... 9 84 4.1 Introduction .............................................. 9 85 4.2 The VPN-SPI in the IKE negotiation ........................ 10 86 4.2.1 VPN-SPI format, V-flag = 1 ................................ 10 87 4.2.2 Non-VPN-SPI format, V-flag = 0 ............................ 12 88 4.2.3 Use of the VPN-SPI in the IKE negotiation ................. 13 89 4.3 The VPN-SPI in the IPsec processing ....................... 13 90 4.3.1 Format and Interpretation of the VPN-SPI 91 in the IPsec processing ................................... 14 92 4.3.2 Outbound IPsec processing ................................. 14 93 4.3.3 Inbound IPsec processing .................................. 15 94 4.4 Use of the VPN-SPI after the inbound IPsec processing ..... 15 95 4.5 Achievement ............................................... 15 96 5 VPN Route Distribution via BGP ............................ 16 97 5.1 The VPN-IPv4 Address Family ............................... 16 98 5.2 Controlling Route Distribution ............................ 16 99 5.2.1 The Route Target Attribute ................................ 17 100 5.2.2 Route Distribution among PEs by BGP ....................... 19 101 5.2.3 How VPN-IPv4 NLRI is Carried by BGP ....................... 20 102 5.2.4 Building VPNs using Route Targets ......................... 21 103 6 Forwarding across the Backbone ............................ 21 104 7 How PEs learn Routes from CEs ............................. 21 105 8 How CEs learn Routes from PEs ............................. 22 106 9 Inter-Provider Backbones .................................. 23 107 10 Use of an MPLS Backbone ................................... 23 108 11 Security .................................................. 24 109 12 Scalability ............................................... 24 110 13 References ................................................ 25 111 14 Acknowledgements .......................................... 25 112 15 Authors' Addresses ........................................ 25 114 Specification of Requirements 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 1.0 Introduction 121 Most of the definitions used in this introduction come from the model 122 presented in [RFC2547bis]. For the sake of completeness, we introduce 123 them in this document too. 125 1.1 Motivation 127 This document proposes a model to deploy VPNs that extends on the 128 model presented in [RFC2547bis]. The purpose of extending the VPN 129 procedures described in [RFC2547bis] is twofold: 131 a) The IPsec based VPN model does not require the presence of an 132 MPLS-aware backbone. Thereby allowing a wider deployment of 133 inter-provider backbone VPNs. Note that the usage of MPLS over 134 certain segments of the backbone is not excluded, and could be 135 used for traffic engineering and QoS purposes. 137 b) The IPsec based VPN model offers stronger security services 138 than the "layer-2" security offered by the model described in 139 [RFC2547bis]. Note that while "layer-2" security might be 140 sufficient for intra-domain VPN operation, it might be short in 141 providing security when building VPNs over multiple adjacent 142 backbones, some of which might not even be VPN aware. 144 This document proposes an IPsec based VPN model that is easy to 145 combine with [RFC2547bis] and that offers the additional advantages 146 stated before. 148 Note further that the procedures as described in this document do not 149 require any extensions to the IPsec framework, and as such can make 150 use of an existing implementation base. 152 1.2 Virtual Private Networks 154 Like in [RFC2547bis], we consider a set of "sites" which are attached 155 to a common network which we call the "backbone". On this topology we 156 apply some policy to create a number of subsets of that set of sites, 157 and we impose the following rule: two sites may have IP connectivity 158 over that backbone only if at least one of these subsets contains 159 them both. 161 The subsets that we have created are "Virtual Private Networks" 162 (VPNs). Two sites have IP connectivity over the common backbone only 163 if there is some VPN that contains them both. Two sites which have no 164 VPN in common, have no connectivity over that backbone. 166 We consider the case where the owner and operator of the "backbone" 167 is a Service Provider (SP), and where the owners of the "sites" are 168 the customers of that SP. In this document, we discuss mechanisms 169 that may be used to implement the policies to determine whether a set 170 of sites belong to a certain VPN. We don't focus on the question 171 whether it is the SP or the customer that implements these policies, 172 though this model allows for both approaches. 174 The model presented in this document allows for the deployment of a 175 wide range of policies (leading to different communication 176 topologies: full mesh, hub and spoke, ...). 178 1.3 Edge Devices 180 We suppose that at each site, there are one or more Customer Edge 181 (CE) devices, each of which is attached via some sort of data link to 182 one or more Provider Edge (PE) routers. Routers in the Provider's 183 network backbone which do not attach to CE devices are known as "P 184 routers". 186 The CE device may be a single host, it may be a switch if the 187 considered site is a single subnet, and in general, the CE device may 188 be expected to be a router. 190 We will say that a PE router is 'attached to a VPN' if it is attached 191 to a CE device that is in that VPN. 193 When the CE device is a router, it is a routing peer of the PE(s) it 194 is attached to (by means of any routing protocol), but it is NOT a 195 routing peer of the other CE routers in the other sites, even if they 196 are in a common VPN. Routers at different sites do not directly 197 exchange routing information with each other, they even don't have to 198 know of each other's existence at all. Like in the BGP/MPLS VPN model 199 [RFC2547bis], in this document, a VPN is not an "overlay" on top of 200 the SP's network, and a VPN customer does not have to manage a 201 "virtual backbone" in the SP's backbone. 203 1.4 Multiple Routing and Forwarding Instances in PEs 205 Every PE router maintains a number of separate forwarding tables. 206 Every site to which the PE is attached must be mapped on one of these 207 forwarding tables. In the scope of this document, we will use the 208 term VRF (VPN Routing and Forwarding Instance) to describe the 209 instances in the PE that do the forwarding and the routing in a 210 specific context and that contain a specific separate forwarding 211 table. 213 So this means that every site is mapped to a particular VRF. 215 When a packet is received by a PE router from a specific site, the 216 VRF associated with that site must be used to handle that packet. The 217 forwarding table in a VRF associated with a particular site must be 218 populated ONLY with routes that lead to sites that have at least a 219 VPN in common with the considered site. This prevents communication 220 between sites that are not in the same VPN. 222 The way this 'selective population' of routing tables is done, is 223 explained further in this document. 225 The relationship between sites and VRFs is a one-to-one or a multi- 226 to-one relationship. More than one site can be associated with the 227 same VRF only if they have access to the same set of routes (if they 228 have all their VPNs in common). 230 A PE router is "attached" to a site when it is the endpoint of an 231 interface or "sub-interface" (PVC, VLAN, etc.) whose other endpoint 232 is a CE device. It is the interface through which the PE received a 233 packet that identifies the VRF to send the packet to. 235 1.5 VPNs with Overlapping Address Spaces 237 An important requirement for VPNs is that different VPNs must be able 238 to use overlapping private address spaces. This model allows the 239 usage of overlapping address spaces, for VPNs that do not have sites 240 in common. 242 The fact that sites in different VPNs are mapped to different VRFs 243 (thus to different routing and forwarding contexts) in the PEs, makes 244 it possible for different VPNs to have overlapping address spaces. 246 The usage of the IPsec tunnel mode in the backbone network hides the 247 private addresses in that backbone, so that also there all possible 248 ambiguity disappears when using overlapping address spaces. 250 1.6 VPNs with Different Routes to the Same System 252 As it is stated in [RFC2547bis], the fact that routes are included 253 independently in the different VRFs makes it possible to introduce 254 (in different VRFs) different routes to the very same system, so that 255 the route to a certain system is dependent of the VRF that handles 256 the packet (i.e. dependent of the origin of the packet). This can be 257 used to create (more) complex communication topologies. 259 1.7 SP Backbone Routers 261 The SP's backbone consists of the PE routers, as well as other 262 routers which are not attached to CE devices ("P routers"). 264 The model presented in this document does not impose any VPN 265 knowledge on the P routers, nor does it request the use of e.g. MPLS 266 in the backbone network. The only requirement for the P routers is 267 that they are regular IP routers, and that they maintain /32 268 addresses for every PE participating in the BGP/IPsec VPN context. 270 The routing information about a particular VPN is only present in the 271 PE routers that attach to that VPN. 273 1.8 Security 275 The model to deploy VPNs described in this document, offers two kinds 276 of security measures. The first Security aspect is offered by the 277 IPsec Security Protocols. The IP traffic sent over the backbone(s) 278 is sent through IPsec tunnels, so that it can be encrypted and 279 authenticated. This allows for the deployment of VPNs over 280 untrusted, not participating backbones. This provides a PE to PE 281 end-to-end security service. 283 In addition, in the absence of misconfiguration or deliberate 284 interconnection of different VPNs, it is not possible for systems in 285 one VPN to gain access to systems in another VPN. 287 1.9 Using IPsec in the backbone 289 In the model presented in this document, the IP security protocol 290 [RFC2401] is used instead of MPLS to tunnel IP packets through the 291 backbone of the network. 293 Because there is no concept of "label-stacking" in IPsec, the 294 straightforward way of providing IPsec network-based VPNs would be to 295 deploy a full mesh of Security Associations between the VRFs among 296 the participating PEs. This would cause serious scalability problems 297 and is therefor not applicable for large networks. 299 The scalability problems arise because: 301 a) every VRF in a PE needs to maintain Security Associations with 302 every VRF from the peer PEs that are attached to the same VPN(s). 304 b) the creation of a new VRF in a certain PE requires the creation of 305 new Security Associations via IKE-exchanges with all the 306 participating PEs. 308 The model presented in this document provides a way to deploy IPsec 309 network-based VPNs in a scaleable manner. There is only a full mesh 310 of SAs between participating PEs, not between VRFs. The selection of 311 the correct VRF when a packet arrives at the end of the IPsec tunnel 312 (the goal of the second label in the [RFC2547]-model) is based on the 313 Security Parameter Index. This means that a method must be provided 314 to link a pool of SPIs with a single Security Association instead of 315 the usual one-to-one relationship between a SA and a SPI. 317 This model resolves this by introducing the concepts of an SPI-prefix 318 and an SPI-label. 320 2.0 Sites and CEs 322 This document uses the same definitions and imposes the same global 323 behaviour on the sites and the CEs as [RFC2547bis]. 325 From the perspective of a particular backbone network, a set of IP 326 systems constitutes a site if those systems have mutual IP 327 interconnectivity, and communication among them occurs without the 328 use of the backbone. 330 A CE device is always regarded as being in a single site (though a 331 site may consist of multiple "virtual sites", see later in this 332 section). A site may belong to multiple VPNs. 334 A PE router may attach to CE devices in any number of different 335 sites, whether those CE devices are in the same or in different VPNs. 336 A CE device may (for robustness for example) attach to multiple PEs, 337 of the same or of different SPs. 339 While we use the site as the basic unit of interconnection, the 340 architecture of [RFC2547bis] allows for a finer degree of granularity 341 in the control of interconnectivity. These techniques are also 342 applicable in this model. The customer itself may divide its site 343 into different "virtual sites", each belonging to a different set of 344 VPNs. The PE then needs to contain a separate VRF for each virtual 345 site. The way this can be done is explained in [RFC2547bis]. 347 3.0 VPN Routing and Forwarding Instances 349 Each PE router maintains one or more "per-site-forwarding tables". As 350 stated before, these are known as VRFs, or "VPN Routing and 351 Forwarding" instances. Every site to which the PE router is attached 352 is associated with one of these tables. A particular packet's 353 (private) IP destination address is looked up in a particular VRF 354 only if that packet has arrived directly from a site which is 355 associated with that table. 357 In a PE router, the following rules apply: 359 - sub-interfaces may be mapped to VRFs 361 - the mapping between sub-interfaces (sites) to VRFs is many-to-one 362 or one-to-one 364 - the VRF in which a packet's destination address is looked up is 365 determined by the sub-interface over which it is received 367 - two sub-interfaces (sites) may not be mapped to the same VRF unless 368 the same set of routes is meant to be available to packets received 369 over either sub-interface (both sub-interfaces "are in the same set 370 of VPNs"). 372 The way by means of which VRFs are populated is explained further in 373 this document. 375 If a site is in multiple VPNs, the VRF associated with that site 376 contains the routes from the full set of VPNs of which the site is a 377 member. 379 [RFC2547bis] gives two basic methods for providing Internet access 380 over an interface that is associated with a VRF: the VRF may contain 381 a default route which leads to a firewall; or, if no entry in the VRF 382 matches the destination address, the packet's destination address may 383 be matched against the PE's Internet forwarding table. 385 When a PE receives a packet from a directly attached site, it always 386 looks up the packet's destination address in the VRF which is 387 associated with that site. However, when a PE receives a packet which 388 is destined to go to a particular directly attached site, it does not 389 necessarily need to look up the packet's destination address in the 390 appropriate VRF (although in some cases it will need to). The packet 391 may already be carrying enough information (in the form of a VPN-SPI, 392 see section 4.4) to determine the packet's outgoing sub-interface. 394 4.0 The VPN-SPI 396 4.1 Introduction 398 The Security Architecture for the Internet Protocol [RFC2401] defines 399 a Security Association (SA) as a unidirectional "connection" that 400 affords security services to the traffic carried by it. It is a 401 relationship between two entities, represented by a set of 402 information that can be considered a contract between the entities. A 403 Security Association is identified by a triple consisting of a 404 Security Parameter Index (SPI), an IP Destination Address, and a 405 security protocol (AH or ESP). The SPI is used to differentiate 406 between different Security Associations to the same IP Destination 407 Address, using the same security protocol. The SPI is a pseudo- 408 random 32-bit number for which no formal format has been defined. 410 4.2 The VPN-SPI used in the IKE Negotiation 412 This document presently defines two SPI-formats and interpretations 413 to be used in the IKE negotiation phase: a VPN-SPI format (V-flag = 414 1), and a non-VPN-SPI format (V-flag = 0). The way to interpret the 415 SPI in IKE is dependent on the value of the first SPI bit: the V- 416 flag. 418 4.2.1 VPN-SPI format, V-flag = 1 420 It is assumed in this document that the peer PE that receives the 421 packets through an IPsec tunnel identified by a certain SPI, has 422 chosen this SPI associated with the considered tunnel during the 423 IKE-negotiation. 425 Provider Edge Routers that use IKE to establish IPsec tunnels between 426 them to be used in the BGP/IPsec VPN context, MUST interpret the 427 negotiated SPIs according to the format defined in this document. 429 This model assumes that for the inbound ("inbound" is used to denote 430 the process of handling packets coming out of the IPsec tunnel) IPsec 431 SA selection, the following identifiers are used: the Destination IP 432 address of the outer IP header, the Security Protocol (AH or ESP) in 433 the security header of the IPsec packet, the SPI, and eventually the 434 Source IP address of the outer IP header. Although the use of the 435 Source IP Address in the outer IP header during the inbound SA 436 selection process is not standardized, it is recommended to do so 437 when using this model. 439 In the model described by this document, every PE should define at 440 least one "SPI-prefix" per participating peer PE. If the source IP 441 address in the outer IP header of an incoming IPsec packet can not be 442 used to select the appropriate SA (next to the destination IP 443 address, the security protocol and the SPI), then these SPI-prefixes 444 must be different for every peer PE. But if the source IP address in 445 the outer IP header of an incoming IPsec packet can be used to select 446 the appropriate SA, then platform-wide SPI-prefixes can be assigned 447 (this means the same SPI-prefix for every peer PE). 449 A reason to assign more than one SPI-prefix to a certain PE, could be 450 that two PEs could maintain multiple SAs, because some VPN traffic 451 needs stronger protection than other VPN traffic. 453 This means that every PE must do the following things (independently 454 of the other PEs): 456 - if the Source IP address of the outer IP header can not be used by 457 the inbound IPsec process in the PE for the SA selection process: 458 associate at least one SPI-prefix with every peer PE. These SPI- 459 prefixes must be unique within the context of a PE (each one 460 identifies a peer PE). 462 - if the Source IP address of the outer IP header can be used by the 463 inbound IPsec process in the PE: associate at least one SPI-prefix 464 with every peer PE. These SPI-prefixes must not be unique. 466 In the regular IKE specifications, the SPI is defined as a pseudo- 467 randomly generated number. This document imposes a formal format on 468 the SPI used in the IKE negotiation under the conditions applicable 469 in this section of the document. This allows the negotiating peers 470 to interpret the SPIs as belonging to a BGP/IPsec VPN-environment, 471 and to negotiate about SPI-pools instead of about single SPIs, so 472 that multiple SPIs can be associated with a single Security 473 Association. 475 The formal format for the VPN-SPI used in IKE-negotiations is the 476 following: 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 |V| prefix | null | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 V-flag: 486 This flag is used to differentiate IKE-negotiations about IPsec 487 tunnels to be interpreted in the BGP/IPsec VPN context (V = 1) or 488 in another context (V = 0). In the VPN-SPI context, this flag MUST 489 be set to 1. 491 prefix: 493 This 12-bit field contains the SPI prefix. 495 null: 497 These 19 bits must be set to 0. 499 The length of the VPN-SPI prefix is 12 bits because this allows to 500 use a 20-bit MPLS label as the VPN-SPI label. The use of a smaller 501 prefix-length could open the door for possible denial-of-service 502 attacks. 504 4.2.2 non-VPN-SPI format, V-flag = 0 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 |V| pseudo-random value | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 The SPI format used in the IKE negotiation in the non-VPN-SPI context 513 does differ from the normal SPI format (a pseudo-random 32-bit 514 number) on only one point: the first bit MUST be set to 0. 516 V-flag: 518 this flag is used to differentiate negotiations about IPsec 519 tunnels to be interpreted in the BGP/IPsec VPN context (V = 1) 520 from other contexts (V = 0). In the non-VPN-SPI context, this flag 521 MUST be set to 0. 523 pseudo-random value: 525 this 31-bit field contains a pseudo-random number. 527 4.2.3 Use of the VPN-SPI during the IKE negotiation 529 During a normal IKE negotiation, two SAs are being set-up. The SPIs 530 identifying these SAs are chosen by the receiving party. 532 Every PE participating in the BGP/IPsec VPN scenario MUST define a 533 VPN-SPI prefix per peer PE. 535 The receiving PE (i.e. the PE that will receive the IPsec packets) 536 must now form 32-bit VPN-SPIs as described in section 4.2.1 for the 537 BGP/IPsec VPN SA negotiation via IKE with every peer PE. To create 538 these VPN-SPIs, the PE sets the V-bit to 1 and inserts the correct 539 SPI-prefix in the correct field. A particular VPN-SPI must be used in 540 all the IKE-exchanges with the appropriate peer PE in the BGP/IPsec 541 VPN context. 543 As a result of these IKE exchanges, every PE has at least 1 inbound 544 SA with every other PE for the BGP/IPsec VPN context. These SAs are 545 identified by: 547 - the destination IP address 549 - the security protocol (AH or ESP) 551 - the V-bit of the VPN-SPI 553 - the unique (i.e. different for every peer PE) SPI-prefix when the 554 Source IP Addresses are not used 556 - the SPI-prefix and the Source IP address when the Source address 557 may be used 559 4.3 The VPN-SPI in the IPsec processing 561 4.3.1 Format and interpretation of the VPN-SPI in the IPsec processing 563 The SPI that will finally been inserted in the security headers of 564 the IPsec packets has the following format: 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | prefix | label | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 prefix: 574 This 12-bit field identifies the SA to associate an IPsec packet 575 with. 577 label: 579 The length of the label field is the length of an ordinary MPLS 580 label : 20 bits. This part of the VPN-SPI is not used to find the 581 correct SA during inbound processing, but it is used to identify 582 the correct outgoing interface or VRF after the IPsec processing 583 in the egress PE (see later in this document). 585 Note that every PE must take care not to assign SPI's for other IPsec 586 contexts (than the BGP/IPsec VPN context) that might be identical to 587 the combination of any distributed VPN-SPI prefix with any VPN-SPI 588 label. 590 4.3.2 Outbound IPsec processing 592 As described in [RFC2547bis], an IP packet coming from a customer 593 site will be handled in a dedicated VPN Routing and Forwarding 594 instance in the considered PE. The choice of the VRF is based on the 595 packet's incoming sub-interface. In that VRF, a routing lookup will 596 be done, based on the (private) destination address in the packet's 597 IP header. As a result of that lookup, the information associated 598 with a particular packet is: the next hop (PE) and the outgoing sub- 599 interface to send the packet to, and a specific (SPI-)label to 600 associate with that packet (assigned to that route by the next hop PE 601 = BGP next hop). The mechanism by means of which the routes in the 602 VRFs are associated with the correct SPI-labels is explained 603 elsewhere in this document (section 5.0). If the outgoing sub- 604 interface is associated with a VRF, then the next hop is a CE device 605 attached to the same PE. The packet is then directly sent to that 606 outgoing interface (although a new lookup in a VRF is also possible). 608 If the next hop PE is another PE, then the outgoing interface is an 609 interface to the backbone, and the packet must be IPsec processed. 610 Within a PE, the VRF that handles the considered packet, together 611 with the 'next hop PE' found after the lookup (the 'selectors'), and 612 eventually the SPI-label, uniquely identify a SA (= a certain 613 security association for the BGP/IPsec VPN context between this PE 614 and the next hop-PE). 616 The packet will now be processed according to that SA and the packet 617 will be sent over the IPsec tunnel to the next hop PE, using the 618 appropriate VPN-SPI (constructed using the SPI-label found after the 619 lookup in the VRF and using the SPI-prefix associated with the 620 considered SA) in the SPI-field of the security header of the IPsec 621 packet. 623 4.3.3 Inbound IPsec processing 625 When a PE receives an IPsec packet from the core network that has 626 it's own IP address in the destination IP address field of the outer 627 IP header, the correct SA must be identified. This SA is identified 628 by means of: the Destination IP address (it's own IP address) in the 629 outer IP header, the security protocol (AH or ESP), the SPI (in fact 630 only the prefix-part of the SPI can be enough to identify a BGP/IPsec 631 VPN SA), and eventually the Source IP address of the outer IP header. 633 Once the correct SA is identified, the packet will be handled 634 according to the IPsec inbound processing rules: decryption, 635 authentication, etc. The result of this is a regular IP packet with 636 -eventually- a private IP address in the IP header. 638 4.4 Use of the VPN-SPI after the inbound IPsec processing 640 Now, instead of routing this IP packet according to the global IP 641 Routing table of the PE (which is not possible because of the use of 642 private addresses), the label-part of the VPN-SPI (that the 643 considered PE distributed with the VPN addresses via BGP) found in 644 the security header of the IPsec packet is used to direct the packet 645 immediately to the correct customer-side interface or to the correct 646 VRF for further processing in the right private address context. The 647 label-part of the VPN-SPI has the same role as the first label in the 648 BGP/MPLS VPN model [RFC2547bis]. 650 4.5 Achievement 652 The introduction of the VPN-SPI does not affect the real IPsec 653 processing. The SPI still identifies a SA. Also the IKE-mechanism is 654 not changed radically: it is still two peers negotiating SAs, and 655 assigning SPIs to them. The only difference is that some structure in 656 these SPIs must be recognized. By introducing this structure to the 657 SPI, and imposing the use of this structure on the participating PEs, 658 two goals have been achieved: 660 - IKE is able to negotiate about SPI-pools, so that multiple SPIs can 661 point to the same SA. 663 - the SPI (more precisely, a part of the SPI) can be used as a label 664 to identify the correct VPN context to process certain packets in (a 665 VRF), or the correct outgoing interface to send the packet to. 667 5.0 VPN Route Distribution via BGP 669 The distribution over the backbone of the (private) routes to the 670 different sites participating in the BGP/IPsec VPN model, uses the 671 same conceptual model as the BGP/MPLS VPN model [RFC2547bis]: PE 672 routers use BGP to distribute VPN routes to each other. 674 We allow each VPN to have its own address space, which means that a 675 given address may denote different physical systems in different VPNs 676 (concept of 'private addresses'). If two routes, to the same IP 677 address prefix, are actually routes leading to separate systems, we 678 must make sure that BGP treats them as two different routes. 679 Otherwise BGP might choose to install only one of them, making the 680 other system unreachable. Further, we must make sure that policy is 681 used to determine which packets get sent on which routes. Given that 682 several routes are installed by BGP, only one of them may appear in a 683 particular VRF. 685 These goals are met by the use of the VPN-IPv4 address family and by 686 the use of the Route Target attribute. 688 5.1 The VPN-IPv4 Address Family 689 The BGP Multiprotocol extensions [BGP-MP] allow BGP to carry routes 690 from multiple "address families". [RFC2547] introduces the notion of 691 "VPN-IPv4 address family". The model described in this document uses 692 the same address family (but does not use the "labeled"-version of 693 it). A VPN-IPv4 address is a 12-octet quantity, beginning with an 8- 694 octet "Route Distinguisher" (RD), and ending with a 4-octet IPv4 695 address. If two VPNs use the same IPv4 address prefix for a different 696 system, the PEs transform these into two different VPN-IPv4 address 697 prefixes (using two different RDs). 699 For the possible other uses of the RD and the structure and encoding 700 of the RD, we refer to [RFC2547bis]. 702 5.2 Controlling Route Distribution 704 In this section, we discuss the means by which the distribution of 705 the VPN-IPv4 routes is controlled. 707 5.2.1 The Route Target Attribute 709 The BGP/MPLS VPN model [RFC2547bis] introduces the concept of "Route 710 Target" attributes. These BGP attributes are encoded as BGP Extended 711 Community Route Targets [BGP-EXTCOMM]. 713 Every VRF in a PE is associated with one or more Route Target 714 attributes (= the "import" Route Target attributes). Every site 715 attached to a PE is also associated with one or more Route Target 716 attributes (= the "export" Route Target attributes). These Export 717 Route Target attributes may be associated per route, per site or per 718 VRF (thus possibly associated with more than one site, as more than 719 one site may be served by the same VRF). The two sets of Route Target 720 attributes need not be identical, they are distinct. 722 When a PE learns a customer-route from one of his attached CEs, the 723 PE creates a VPN-IPv4 route to distribute with BGP. The PE then 724 associates one or more "Route Target" attributes with that route (the 725 "export" Route Targets associated with the considered site). These 726 Route Targets are carried in BGP as attributes of the route. 728 Any route associated with a certain Route Target T must be 729 distributed to every PE router that has at least one VRF associated 730 with Route Target T (an "import" Route Target of that VRF). When such 731 a route (carrying a Route Target attribute T) is received by a PE 732 router, it is eligible to be installed only in those VRFs that are 733 associated with an "import" Route Target T. Whether the route 734 actually gets installed is dependent on the outcome of the BGP 735 decision process. 737 A Route Target Attribute can be thought of as identifying a set of 738 sites or a set of VRFs. It is used to filter the appropriate routes 739 into the correct VRFs. 741 Several methods can be used to associate routes with Route Target 742 attributes: a PE can be configured to associate every route coming 743 from a certain site with a set of Route Targets; or to associate some 744 routes with one set of Route Targets and some routes with another 745 set; or alternatively, the control could be shifted to the CE: the CE 746 could specify every route it advertises to the PE with one or more 747 Route Targets. 749 5.2.2 Route Distribution among PEs by BGP 751 If two sites of a VPN attach to PEs that are in the same Autonomous 752 System, these PEs can distribute VPN-IPv4 routes to each other by 753 means of an IBGP connection between them. The way it is done for PEs 754 that do not belong to the same Autonomous System is explained later 755 in this document (section 10). 757 Like in the model described in [RFC2547bis], the use of route 758 reflectors [BGP-RR] is strongly recommended in order to scale the 759 number of BGP connections. The model described here allows for the 760 use of all the route reflector techniques to improve scalability. As 761 it is explained in [RFC2547bis], the set of VPN-IPv4 routes may be 762 partitioned among a set of route reflectors. 764 When a PE router distributes a VPN-IPv4 route via BGP, it uses its 765 own address as the "BGP next hop". As BGP must use only one kind of 766 Address Family ([BGP-MP]), this address is encoded as a VPN-IPv4 767 address with a RD of 0. In addition, the PE assigns an appropriate 768 (SPI-)label Attribute (and a set of Route Target Attributes, see 769 later) to the route and distributes it. This (SPI-)label identifies 770 the destination within the PE (a certain customer-interface or a 771 certain VRF) of the packets coming from the backbone and following 772 the considered route. 774 When the PE processes a packet received from the core, it goes 775 through the following steps: 777 - identify the correct SA by means of the SPI, the destination 778 address and the security protocol. 780 - process the packet according to the IPsec process defined by the 781 SA. 783 - (if the SPI is a VPN-SPI) use the label-part of the VPN-SPI in the 784 security header of the IPsec packet (more precisely compare it to the 785 SPI-labels distributed via BGP in the SPI-label attribute) to direct 786 the packet to the correct outgoing interface or to a certain VRF for 787 further processing. 789 The use of the BGP refresh mechanism [BGP-RFSH] and the outbound 790 route filtering mechanism [BGP-ORF] is strongly recommended to assure 791 maximum scalability of the model. 793 In the BGP-point of view, the model described in this document has 794 the same advantages as the model described in [RFC2547bis]: a PE 795 router should not install VPN-IPv4 routes belonging to VPNs it is not 796 attached to; a router which is not attached to any VPN (a P router), 797 never installs any VPN-IPv4 routes at all. This also means that 798 there is no box that needs to know all the VPN-IPv4 routes that are 799 supported over the backbone. 801 5.2.3 How VPN-IPv4 NLRI is Carried by BGP 803 VPN-IPv4 NLRI is carried by BGP in the same way as in [RFC2547bis]. 804 Labelled addresses are used. 806 5.2.4 Building VPNs using Route Targets 808 By setting up the Import Route Targets and Export Route Targets 809 properly, one can construct different kinds of VPNs. 811 [RFC2547bis] gives two examples: a fully meshed closed user group 812 (i.e. a set of sites where each can send traffic directly to the 813 other, but where no communication is possible with other non-member 814 sites), and a hub and spoke model (i.e. a communication topology 815 where all the traffic between sites (the "spoke sites") must go 816 through a central site (the "hub site"). 818 To form a fully meshed closed user group for example, a single Route 819 Target is needed. That Route Target is assigned to the VRFs 820 associated with the participating sites, as both the Import and the 821 Export Route Target. 823 The method for controlling the distribution of routing information 824 among various sets of sites are very flexible. This provides great 825 flexibility in constructing VPNs. 827 6.0 Forwarding Across the Backbone 829 As PE to PE IPsec tunnels are deployed across the backbone, the 830 forwarding in the backbone is based on regular IP forwarding, using 831 the destination addresses in the outer IP-headers. These outer IP 832 headers contain no VPN information. The addresses included in the 833 outer IP headers are PE global IP addresses. This means that no VPN 834 awareness is needed in the backbone at all, and that all the 835 forwarding relies on regular IP, so no non-IP tunneling mechanisms 836 are needed (such as MPLS). The only requirement is that PE routers 837 need to insert /32 address prefixes for themselves (the IPsec tunnel 838 endpoints) into the IGP routing tables of the backbone. 840 7.0 How PEs Learn Routes from CEs 842 The PE routers which attach to a particular VPN need to know, for 843 each of that VPN's sites, which addresses in that VPN are at each 844 site. 846 If the CE device is a switch or a host, the set of addresses will 847 generally be configured into the PE router. If the CE is a user 848 dialing in, it will usually receive a temporary IP address from the 849 PE. In the case where the CE is a router, there are a number of 850 possible ways that a PE router can obtain this set of addresses. 852 The PE translates these private IPv4 addresses into VPN-IPv4 853 addresses, using a configured RD. The PE then treats these VPN-IPv4 854 routes as input to BGP. Routes from a site are NOT leaked into the 855 backbone's IGP. 857 We can imagine a lot of route distribution techniques from CE to PE. 858 However, the distinction must be made between CEs in a "transit VPN" 859 (= a VPN that contains a router that receives routes from another, 860 non-PE router that is not in the VPN) and CEs in a "stub VPN" (= a 861 VPN without "third party" routing exchanges). 863 The possible PE/CE distribution techniques are: static routing, RIP, 864 OSPF, EBGP, etc. 866 [RFC2547bis] gives a more detailed overview of the possible CE/PE 867 route distribution scenario's. 869 Once the CE-routes are learned by the PE, it distributes the 870 resulting VPN-IPv4 routes via BGP. These routes are associated with 871 the following attributes: an SPI-label attribute, one or more Route 872 Target attributes and eventually a Site of Origin attribute. 874 The Site of Origin attribute, if used, is encoded as a Route Origin 875 Extended Community [BGP-EXTCOMM]. The purpose of this attribute is to 876 uniquely identify the set of routes learned from a particular site. 877 This attribute is needed in some cases to ensure that a route learned 878 from a particular site via a particular PE/CE connection is not 879 distributed back to the site through a different PE/CE connection. 881 8.0 How CEs Learn Routes from PEs 883 In this section, it is assumed that the CE device is a router. 885 If the PE places a particular route in the VRF associated with a 886 certain site, then in general, the PE may distribute that route to 887 the CE. Of course, the PE may distribute that route to the CE only if 888 this is permitted by the rules of the PE/CE protocol. Note that 889 whatever procedure is used to distribute routes from CE to PE will 890 also be used to distribute routes from PE to CE. 892 One more restriction is added on the distribution of routes from PE 893 to CE: if a route's Site of Origin attribute identifies a particular 894 site, that route must never be redistributed to any CE in that site. 896 Note also that in most cases, it will be sufficient for the PE to 897 simply distribute the default route to the CE. 899 9.0 Inter-Provider Backbones 901 A usual requirement for VPNs is that VPNs must be able to span across 902 multiple backbones. This allows sites that are connected to different 903 SPs to 'be in the same VPN'. This requirement introduces two main 904 issues: 906 - the PE routers participating in the VPN topology are not able to 907 establish IBGP connections with each other or with a common route 908 reflector 910 - the security aspect becomes an important issue 912 The latter issue is covered by the use of the PE-PE end to end IPsec 913 tunnels. For the first issue, [RFC2547bis] discusses 3 different 914 solutions. 916 The first two solutions ('VRF-to-VRF connections at the AS border 917 routers' and 'EBGP redistribution of labeled VPN IPv4 routes from AS 918 to neighboring AS') are not applicable in the model presented in this 919 document, because this model requires PE-PE end-to-end IPsec tunnels. 921 The third solution is perfectly applicable: multihop EBGP 922 redistribution of VPN-IPv4 routes (associated with VPN-SPI 923 attributes) between source and destination ASs. The participating PEs 924 still need to set up IPsec tunnels with each other (whether they are 925 in the same AS or not) via IKE. The /32 routes to all the 926 participating PEs must be known in all the participating ASs (PE and 927 P routers) to allow for normal end-to-end IP forwarding. 929 Now PE routers in different ASs can establish multi-hop EBGP 930 connections to each other, and can exchange VPN-IPv4 routes over 931 these connections. 933 To improve scalability, one can have multi-hop EBGP connections only 934 between a route reflector in one AS and an other route reflector in 935 an other AS. Care must then be taken that these route reflectors do 936 not change the BGP next hop attribute of the routes). 938 10.0 Use of an MPLS backbone 940 The model presented in this document does not in any way preclude the 941 existence of an MPLS core network. An MPLS network can carry IPsec 942 packets as easily as it can carry IP packets. This means that if an 943 MPLS network is present in the backbone of the ISP network, all the 944 extra functionalities that MPLS offers (Traffic Engineering, QoS, 945 etc.) can still be used in the core of this BGP/IPsec VPN 946 architecture. 948 11.0 Security 950 The model described in this document offers a higher level of 951 security than [RFC2547bis]. The IPsec security mechanisms protect the 952 IP packets when traversing the backbone(s). This is an ingress PE to 953 egress PE end-to-end IPsec protection. Especially in the case when 954 non-participating ('transit') SPs are traversed, this is an important 955 requirement. 957 In addition, by introducing the VPN-SPI concept and formats, this 958 architecture in itself provides a security level that is virtually 959 identical to a 'layer-2' mechanism in the scope of an individual PE: 960 the PE can decide to accept or reject an IP packet based on the SPI 961 included in the security header of the IPsec packet, and the 962 directing of the packets within the PE relies on the label-part of 963 the VPN-SPI. If no misconfiguration occurs, the traffic from one VPN 964 is perfectly shielded from the traffic in another VPN within the same 965 PE. 967 12.0 Scalability 969 The model proposed in this document uses IPsec (tunnel mode) to 970 tunnel the (private address) IPv4 packets through the shared 971 backbone(s). As the model requires only one IPsec tunnel between 972 every two PEs (and not a full mesh between sites or between VRFs), 973 the solution remains scalable for large topologies. 975 All the scalability considerations that apply for [RFC2547bis] also 976 apply for the model described in this document. 978 P routers (which are neither PE routers nor Route Reflectors) do not 979 maintain any VPN routes. They only need to maintain global IP routes 980 to all the participating PEs. 982 PE routers maintain VPN routes only for the VPNs they are attached 983 to. 985 Route Reflectors can be partitioned among VPNs so that each partition 986 carries only routes for a subset of the VPNs supported by the Service 987 Provider. 989 These remarks apply also for the inter-provider VPNs, if multi-hop 990 EBGP is used. 992 As a result, no single component within the SP network has to 993 maintain all the routes for all the VPNs. This means that the support 994 of an increasing number of VPNs is not limited by the capacity of an 995 individual component. 997 13.0 References 999 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1000 Requirement Levels", RFC 2119, March 1997 1002 [RFC2547] Rosen, E. and Rekhter, Y., "BGP/MPLS VPN", RFC 2547, March 1003 1999. 1005 [RFC2547bis] Rosen E., Rekhter Y., et al., "BGP/MPLS VPN", Work in 1006 Progress. 1008 [RFC2401] Kent, S. and Atkinson R., "Security Architecture for the 1009 Internet Protocol", RFC 2401, November 1998. 1011 [BGP-RR] Bates, T. and Chandrasekaran, R., "BGP Route Reflection: An 1012 alternative to full mesh IBGP", RFC 1966, June 1996. 1014 [BGP-EXTCOMM] Ramachandra, S. and Tappan, D., "BGP Extended 1015 Communities Attribute", Work in Progress. 1017 [BGP-MP] Bates, T., et al., "Multiprotocol Extensions for BGP4", RFC 1018 2283, February 1998. 1020 [BGP-RFSH] Chen, E., "Route Refresh Capability for BGP4", Work in 1021 Progress. 1023 [BGP-ORF] Chen, E. and Rekhter, Y., "Cooperative Route Filtering 1024 Capability for BGP-4", Work in Progress. 1026 14.0 Acknowledgements 1028 The model presented in this document is based on a lot of ideas 1029 presented in [RFC2547bis]. We would like therefor to thank all the 1030 authors of "BGP/MPLS VPN" for their work that has been the basis for 1031 the ideas presented in this document. We also would like to thank 1032 Peter De Schrijver for his contribution to this draft. 1034 15.0 Authors' Addresses 1036 Jeremy De Clercq 1037 Alcatel 1038 Francis Wellesplein 1 1039 2018 Antwerpen, Belgium 1040 Phone: +32 3 240 4752 1041 Email: jeremy.de_clercq@alcatel.be 1043 Yves T'joens 1044 Alcatel 1045 Francis Wellesplein 1 1046 2018 Antwerpen, Belgium 1047 Phone: +32 3 240 7890 1048 Email: yves.tjoens@alcatel.be 1050 Olivier Paridaens 1051 Alcatel 1052 Francis Wellesplein 1 1053 2018 Antwerpen, Belgium 1054 Phone: +32 3 240 9320 1055 Email: olivier.paridaens@alcatel.be 1057 Chandru Sargor 1058 CoSine Communications 1059 1200 Bridge Parkway 1060 Redwood City, CA 94065 1061 Email: csargor@cosinecom.com 1063 Vijay Srinivasan 1064 CoSine Communications 1065 1200 Bridge Parkway 1066 Redwood City, CA 94065 1067 Email: vijay@cosinecom.com