idnits 2.17.1 draft-ietf-l3vpn-ipsec-2547-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1460. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 34 longer pages, the longest (page 1) being 83 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 383 has weird spacing: '...ht want to re...' == Line 384 has weird spacing: '...traffic throu...' == Line 393 has weird spacing: '... one of which...' == Line 1121 has weird spacing: '...ht want to re...' == Line 1122 has weird spacing: '...traffic throu...' == (1 more instance...) -- 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 (March 2004) is 7347 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) == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-01 Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: September 2004 5 Jeremy De Clercq 6 Olivier Paridaens 7 Yves T'Joens 8 Alcatel 10 Chandru Sargor 11 Cosine Communications 13 March 2004 15 Use of PE-PE IPsec in RFC2547 VPNs 17 draft-ietf-l3vpn-ipsec-2547-02.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets 42 traveling from one Provider Edge (PE) router to another generally 43 carry two MPLS labels, an inner label that corresponds to a VPN- 44 specific route, and an outer label that corresponds to a Label 45 Switched Path (LSP) between the PE routers. In some circumstances, 46 it is desirable to support the same type of VPN architecture, but 47 using an IPsec Security Association in place of that LSP. The outer 48 MPLS label would thus be replaced by an IP/IPsec header. This 49 enables the VPN packets to be carried securely over non-MPLS 50 networks, using standard IPsec authentication and/or encryption 51 functions to protect them. This draft specifies the procedures which 52 are specific to support of BGP/MPLS IP VPNs using the IPsec 53 encapsulation. 55 Table of Contents 57 1 Introduction ........................................... 3 58 1.1 Issue: MPLS Infrastructure Required .................... 4 59 1.2 Issue: Protection Against Misbehavior by Transit Nodes . 5 60 1.3 Issue: Limitations on Multi-Provider Misconfigurations . 5 61 1.4 Issue: Privacy for VPN Data ............................ 6 62 1.5 Non-Issue: General Protection against Misconfiguration . 7 63 1.6 Conclusion ............................................. 7 64 2 Specification .......................................... 7 65 2.1 Technical Approach ..................................... 7 66 2.2 Selecting the Security Policy .......................... 8 67 2.3 BGP Label, Route, and Policy Distribution .............. 9 68 2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10 69 2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11 70 2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11 71 2.7 Application of IPsec by Egress PE ...................... 13 72 3 Comparison with Using Part of SPI Field as a Label ..... 14 73 4 Authors' Addresses ..................................... 15 74 5 Normative References ................................... 16 75 6 Informative References ................................. 16 76 7 Intellectual Property Statement ........................ 17 77 8 Full Copyright Statement ............................... 17 79 1. Introduction 81 The present document uses terminology from [RFC2547bis], and 82 presupposes familiarity with that document and its terminology. 84 In BGP/MPLS IP VPNs, when an ingress PE router receives a packet from 85 a CE router, it looks up the packet's destination IP address in a 86 VRF. As a result of this lookup, it learns the output interface on 87 which the packet must be sent, and it also learns the set of headers 88 which must be prepended to the packet before it is sent on that 89 interface. In "conventional" BGP/MPLS IP VPNs, this set of headers 90 consists of a data link layer header, possibly followed by an MPLS 91 label stack. If the packet is going out an interface to a CE router 92 (i.e. the ingress PE is the same as the egress PE), no MPLS label 93 stack is needed. If the packet's egress PE router is directly 94 adjacent to the ingress PE, the MPLS label stack will have one or 95 more entries. In other cases, the MPLS label stack has two or more 96 entries. 98 The bottom label on the MPLS label stack is always a label which will 99 not be seen until the packet reaches its point of egress from the 100 network. This label represents a particular route within the packet's 101 VPN, and we will call it the "VPN route label". Directly above the 102 VPN route label is a label which represents a route across the 103 backbone to the egress PE router. We will call this label the 104 "backbone route label". 106 The backbone route label may or may not be the packet's top label; 107 additional entries may also be pushed on the label stack, if 108 additional MPLS services (e.g., traffic engineering) are used to 109 carry traffic to the egress PE. These additional labels may be 110 pushed on by the ingress PE, or by a P router somewhere along the 111 path. The VPN route label is always the packet's bottom label, 112 however. 114 This document specifies procedures for replacing the backbone route 115 label with an IPsec encapsulation. In effect, this creates an MPLS- 116 in-IPsec encapsulation, in which the VPN route label is carried 117 across the network within an IPsec encapsulation. By "within an 118 IPsec encapsulation", we mean "in a packet containing an IP header 119 and an IPsec header". This IPsec encapsulation corresponds to an 120 IPsec Security Association (SA) whose two endpoints are the ingress 121 PE router and the egress PE router. The payload of the IPsec 122 encapsulation is an authenticated and/or encrypted MPLS packet, whose 123 label stack contains a single entry, viz., the VPN route label. The 124 payload of this MPLS packet is the user data packet being sent within 125 the VPN. 127 The IP/IPsec encapsulation will be used even if the ingress PE and 128 the egress PE are directly adjacent, i.e., even in the case where a 129 backbone route label would not be used. However, no IP/IPsec 130 encapsulation is applied if the ingress PE is the same device as the 131 egress PE. 133 If additional MPLS services, such as traffic engineering, are used in 134 the backbone network, an MPLS label stack will appear above the IP 135 header. This is orthogonal to any issues discussed in the present 136 document. This results in an MPLS packet containing an IP packet 137 containing an IPsec packet containing an MPLS packet; the latter MPLS 138 packet has a single label, the VPN route label. 140 This document is inspired by [VPN-SPI], and originated as an attempt 141 to improve upon it. 143 The remainder of section 1 outlines a number of issues which can be 144 addressed by the use of IPsec in this manner. 146 1.1. Issue: MPLS Infrastructure Required 148 "Conventional" BGP/MPLS IP VPNs require that there be an MPLS Label 149 Switched Path (LSP) between a packet's ingress PE router and its 150 egress PE router. This means that an RFC2547 VPN cannot be 151 implemented if there is a part of the path between the ingress and 152 egress PE routers which does not support MPLS. 154 In order to enable BGP/MPLS IP VPNs to be deployed even when there 155 are non-MPLS routers along the path between the ingress and egress PE 156 routers, it is desirable to have an alternative which allows the 157 backbone route label to be replaced with an IP header. This 158 encapsulating IP header would encapsulate an MPLS packet containing 159 only the VPN route label. The encapsulation header would have the 160 address of the egress PE in its destination IP address field; this 161 would cause the packet to be delivered to the egress PE. 163 It is possible to replace the backbone route label with an IP header, 164 possibly followed by a GRE header [MPLS-in-IP/GRE]. However, it then 165 becomes quite difficult, in general, to protect the VPNs against 166 spoofed packets. A Service Provider (SP) can protect against spoofed 167 MPLS packets by the simple expedient of not accepting MPLS packets 168 from outside its own boundaries (or more generally by keeping track 169 of which labels are validly received over which interfaces, and 170 discarding packets which arrive with labels that are not valid for 171 their incoming interfaces). Protection against spoofed IP packets 172 requires having all the boundary routers perform filtering; either 173 (a) filtering out packets from "outside" which are addressed to PE 174 routers, or (b) filtering out packets from "outside" which have 175 source addresses that belong "inside", and having PE routers refuse 176 to accept packets addressed to them but with "outside" source 177 addresses. The maintenance of these filter lists can be management- 178 intensive, and the their use at all border routers can affect the 179 performance seen by all traffic entering the SP's network. Further, 180 these filtering techniques may be difficult to apply in the case of 181 multi-provider VPNs, because in multi-provider VPNs, packets from 182 outside an SP's network can legitimately be addressed to its PE 183 routers. 185 If, on the other hand, the backbone route label is replaced by an 186 IPsec encapsulation, protection against spoofed packets does not rely 187 on filtering at the border. The cryptographic authentication 188 features of IPsec enable an egress PE to detect and discard packets 189 for a particular VPN that were not generated by a valid ingress PE 190 for that VPN. Thus spoofing protection is managed entirely at the 191 ingress and egress PE routers, transparently to the border routers. 192 IPsec does have its own management and performance implications, of 193 course. 195 1.2. Issue: Protection Against Misbehavior by Transit Nodes 197 Cryptographic authentication applied by the ingress PE on a PE-to-PE 198 basis can protect against the misrouting or modification (intentional 199 or accidental) of packets by the transit nodes. Packets which get 200 forwarded to the "wrong" egress PE will not pass authentication, nor 201 will packets which have been modified. As the VPN route label is 202 part of the IPsec packet payload, the egress PE will know that the 203 VPN route label was placed in the packet by a valid ingress PE. 205 1.3. Issue: Limitations on Multi-Provider Misconfigurations 207 Sometimes a VPN will have some sites which connect to one SP (SP1), 208 and some other sites which connect to another SP (SP2). 210 Consider a case in which VPN V1 has sites attaching to SP1 and SP2, 211 but VPN V2 has all of its sites attaching only to SP2. 213 SP2 would like to ensure that nothing done by SP1 can cause V1 to get 214 illegitimately cross-connected to V2. Since V2 has no sites in SP1, 215 it should be immune to the effects of any misconfigurations within 216 SP1. 218 This assurance can be achieved if the egress PE (in SP2) can 219 determine, for each VPN packet, whether that packet came from SP1, 220 and if so, whether it carries an MPLS label which corresponds to a 221 VPN route that was actually distributed to SP1. (That is, packets 222 originating from SP1 destined for VPNs in SP2 would be checked if 223 they are for VPNs which really have sites in SP1.) SP2's egress PEs 224 could be configured with the knowledge of which VPNs have sites 225 attached to SP1. Cryptographic authentication could then be used to 226 determine that a particular packet did indeed originate in SP1. 228 In general, if an egress PE knows which labels may be validly applied 229 by which ingress PEs, IPsec authentication can be used to ensure that 230 a given ingress PE has not applied a label that it has no right to 231 use. However, the scalability of the VPN scheme would be severely 232 compromised if an egress PE had to distribute a different set of 233 labels to each ingress PE. Therefore we will not pursue this general 234 case, but will only pursue label authentication in the inter-provider 235 case. 237 1.4. Issue: Privacy for VPN Data 239 IPsec Security Associations that associate ingress PE routes with 240 egress PE routers do not ensure privacy for VPN data. The data is 241 exposed on the PE-CE access links, and is exposed in the PE routers 242 themselves. Complete privacy requires that the encryption/decryption 243 be performed within the enterprise, not by the SP. So the use of 244 PE-PE IPsec encryption within the network of a single SP will perhaps 245 be of less import than the use of IPsec authentication. On the other 246 hand, if an SP is trusted to properly secure its routers, but the 247 transmission media used by the SP are not trusted, then PE-PE 248 encryption does provide a valuable measure of privacy. 250 There may be a need for encryption if a VPN has sites attached to 251 different trusted SPs, but some of the transit traffic needs to go 252 through the "public Internet". In this case, it may be necessary to 253 encrypt the VPN data traffic as it crosses the public Internet. 254 However, while PE-PE encryption is the one way to handle this, it is 255 not the only way. An alternative would be to use an encrypted tunnel 256 to connecting a border router of one trusted SP to a border router of 257 another. Then the two trusted domains could be treated as immediate 258 neighbors, adjacent over the tunnel. This would keep the 259 encryption/decryption at the few locations where it is actually 260 needed. On the other hand, there may be performance and scalability 261 advantages to spreading the cost of the cryptography among a larger 262 set of routers, viz., the ingress and egress PEs. 264 The scenario of having VPN traffic go from a trusted domain through 265 an untrusted domain to another trusted domain may not be completely 266 realistic, though, due to the difficulty of supporting the necessary 267 Service Level Agreements through the public Internet. 269 1.5. Non-Issue: General Protection against Misconfiguration 271 In general, the integrity of an RFC2547 VPN depends upon the SP 272 having properly configured the PE routers. There is no way of 273 preventing an SP from creating a bogus VPN that contains sites which 274 aren't supposed to communicate with each other. It is the SP's 275 responsibility to get this right. 277 It is sometimes thought one can obtain protection against 278 misconfigurations by having the PE routers apply cryptographic 279 authentication to the VPN packets. This is not the case. If an 280 ingress PE router has been misconfigured so as to assign a particular 281 site to the wrong VPN, likely as not the PE has been misconfigured to 282 apply that VPN's authenticator to packets to/from that site. 284 Protection against misconfiguration on the part of the SP requires 285 that the authentication procedure be applied before the ingress PE 286 router sees the packets, and after the egress PE router forwards 287 them, and cannot be dealt with by PE-PE IPsec. 289 1.6. Conclusion 291 Taken together, the above set of issues suggest that there are 292 situations in which using PE-PE IPsec as the tunneling protocol for 293 BGP/MPLS IP VPNs does have value. In the next section, we specify 294 the necessary procedures for incorporating PE-PE IPsec as a tunneling 295 option for BGP/MPLS IP VPNs. 297 2. Specification 299 2.1. Technical Approach 301 In short, the technical approach specified here is: 303 1. Use the standard technique [RFC2547bis] of using an MPLS label 304 to represent a VPN route, by prepending an MPLS label stack to 305 the VPN packets. However, the label stack will contain only one 306 label, the VPN route label. 308 2. Use an MPLS-in-IP or MPLS-in-GRE encapsulation to turn the 309 above MPLS packet back into an IP packet. This in effect 310 creates an "IP tunnel" or a "GRE tunnel" between the ingress PE 311 router and the egress PE router. 313 3. Use IPsec Transport Mode to secure the above-mentioned IP 314 tunnels. 316 The net effect is that an MPLS packet gets sent through an IPsec- 317 secured IP or GRE tunnel. 319 The following sub-sections specify this procedure in greater detail. 321 2.2. Selecting the Security Policy 323 One might think that a given SP (or set of cooperating SPs) will 324 decide either that they need to use IPsec for ALL PE-PE tunnels, or 325 else that PE-PE IPsec is not needed at all. But this simple "all or 326 nothing" strategy does not really capture the set of considerations 327 discussed in the Introduction. For example, a very reasonable policy 328 might be to use IPsec only for inter-provider PE-PE tunnels, while 329 using MPLS for intra-provider PE-PE tunnels. Or one might decide to 330 use IPsec only for certain inter-provider tunnels. Or one might 331 decide to use IPsec for certain intra-provider tunnels. 333 In an RFC2547 VPN environment, it makes most sense to place control 334 of the policies with the egress PE router. It is the egress PE which 335 needs to know that it wants to process certain packets ONLY if they 336 come through encrypted tunnels, and that it wants to discard those 337 same packets if they don't come through encrypted tunnels. Thus one 338 needs to be able to configure a policy into the egress PE, and have 339 it signal that policy to the ingress PE. RFC2547 already provides an 340 egress-to-ingress signaling capability via BGP, and we specify below 341 how to extend this to the signalling of security policy. 343 Of course, there is nothing to stop an ingress PE router from being 344 configured to use IPsec even if the egress PE has not signalled its 345 desire for IPsec. This should work, as long as the necessary IPsec 346 infrastructure is in place. (However, in this sort of application 347 the ingress PE and the egress PE are NOT really independent entities 348 which might conceivably have different security policies.) 350 2.3. BGP Label, Route, and Policy Distribution 352 Distribution of labeled VPN-IP routes by BGP is done exactly as 353 specified in [RFC2547bis], except that some additional BGP attributes 354 are needed for each distributed VPN-IP route. 356 A given egress PE will be configurable to indicate whether it expects 357 to receive all, some, or none of its VPN traffic through an IPsec- 358 secured IP or GRE tunnel. In general, an ingress PE will not have to 359 know in advance whether any of the egress PEs for its VPNs require 360 their VPN traffic to be sent through an IPsec-secured IP tunnel; this 361 will be signaled from the egress PE. If an egress PE wants to receive 362 traffic for a particular VPN-IP route through an IPsec-secured IP 363 tunnel, it adds a new BGP Extended Community attribute to the route. 364 This attribute will then get distributed along with the route to the 365 ingress PEs. 367 We call this attribute the "IPsec Extended Community". (It is 368 possible that this will actually be encoded as a particular value or 369 set of values of a more general "Tunnel Type Extended Community"; for 370 the purposes of this draft, however, we will continue to refer to it 371 as the "IPsec Extended Community".) 373 It is conceivable that an egress PE in a particular SP's network will 374 only want to receive IPsec-secured IP-tunneled traffic for those VPNs 375 which have sites that are attached to other SPs. In this case, one 376 would want to be able to configure, on a per-VRF basis, whether 377 routes exported from that VRF should have an IPsec Extended Community 378 attribute or not. 380 A more complex situation would arise if it were only desired to 381 receive IPsec-secured IP-tunneled traffic for a particular VPN if 382 that traffic has originated from a site which is attached to a 383 different SP's network. That is, one might want to receive inter- 384 provider traffic through an IPsec-secured IP tunnel, but to receive 385 intra-provider traffic through an unsecured MPLS LSP. As long as an 386 SP has a policy of never accepting MPLS packets from other SPs, this 387 may provide the necessary security while minimizing the amount of 388 cryptography that actually has to be used. 390 One way to do this would be to map each exportable IP address prefix 391 into two different VPN-IP prefixes, using two different RDs (say RD1 392 and RD2). Then two different RTs (say RT1 and RT2) would be used, 393 one of which causes intra-provider distribution, and one of which 394 causes inter-provider distribution. The prefixes with RD1 would be 395 given RT1 as a route target; the prefixes with RD2 would be given RT2 396 as a route target. If RT2 is the route target that causes inter- 397 provider distribution, then only the routes with RT2 would carry the 398 IPsec Extended Community. 400 A simpler approach, perhaps, would be to use only a single set of 401 VPN-IP prefixes, but to have a value of the IPsec Extended Community 402 which encodes an SP identifier, and which means "only use IPsec if 403 the ingress PE is in a different SP network than the one which is 404 identified here". (Again, the assumption is that MPLS packets are not 405 accepted from other SPs.) 407 It is conceivable that an egress PE will want some of its IPsec- 408 secured IP-tunneled VPN traffic to be encrypted, but will want some 409 to be authenticated and not encrypted. It is even conceivable that it 410 will want some traffic to arrive through an IPsec tunnel without 411 being either encrypted or authenticated. The IPsec Extended Community 412 attribute should have a value which specifies which of these are 413 required. 415 It may be desirable to allow the IPsec Extended Community to specify 416 a set of policies, so that the ingress PE can choose from among them. 418 2.4. MPLS-in-IP/GRE Encapsulation by Ingress PE 420 When a PE receives a packet from a CE, it looks up the packet's IP 421 destination address in the VRF corresponding to that CE. This enables 422 it to find a VPN-IP route. The VPN-IP route will have an associated 423 MPLS label and an associated BGP Next Hop. The label is pushed on the 424 packet. Then, if (and only if) the VPN-IP route has an IPsec Extended 425 Community attribute, an IP or GRE encapsulation header is prepended 426 to the packet, creating an MPLS-in-IP or MPLS-in-GRE encapsulated 427 packet. The IP source address field of the encapsulation header will 428 be an address of the ingress PE itself. The IP destination address 429 field of the encapsulation header will contain the value of the 430 associated BGP Next Hop attribute; this will be an IP address of the 431 egress PE. 433 (This description is not meant to specify an implementation strategy; 434 any implementation procedure which produces the same result is 435 acceptable.) 437 N.B.: If the ingress PE and the egress PE are not in the same 438 autonomous system, this requires that there be an EBGP connection 439 between a router in one autonomous system and a router in another. If 440 the two autonomous systems are not adjacent, this will need to be a 441 multi-hop EBGP connection. 443 The effect is to dynamically create an IP tunnel between the ingress 444 and egress PE routers. No apriori configuration of the remote tunnel 445 endpoints is needed. Note that these IP tunnels are NOT IGP-visible 446 links, and routing adjacencies are NOT supported across these tunnel. 447 Note also that the set of remote tunnel endpoints is NOT known in 448 advance, but is learned dynamically via the BGP distribution of VPN- 449 IP routes. 451 These IP tunneled packets will then be associated with an IPsec 452 Security Association (SA), and transported using IPsec transport 453 mode. This is described in more detail in the next sub-section. 455 2.5. MPLS-in-IP vs. MPLS-in-GRE 457 The MPLS-in-IP encapsulation header is shorter than the MPLS-in-GRE 458 encapsulation header, and, in theory at least, the latter offers no 459 advantages to compensate for its use of a longer header. 461 In practice, implementation considerations of various sorts may make 462 the MPLS-in-GRE encapsulation preferable. 464 2.6. PE-PE IPsec (Application of IPsec by Ingress PE) 466 A given ingress PE needs to have an IPsec SA with each PE router that 467 is an egress PE for traffic which the ingress PE receives from a CE. 469 In general, the set of egress PEs for a given ingress PE is not known 470 in advance. This is determined dynamically by the BGP distribution of 471 VPN-IP routes. This suggests that it will be very important to be 472 able to set up IPsec SAs dynamically, and that static keying will not 473 be a viable option. There will need to be a key distribution 474 infrastructure that supports multiple SPs, and IKE will need to be 475 used. 477 A number of different VPNs might need to have traffic carried from a 478 particular ingress PE to a particular egress PE. It is thus natural 479 to ask whether there should be one SA between the pair of PEs, or n 480 SAs between the pair of PEs, where n is the number of VPNs. Clearly, 481 scalability is improved by having only a single SA for each pair of 482 PEs. So the question is whether there is a significant security 483 advantage to having a distinct SA for each VPN. There does not appear 484 to be any such advantage. Since the SA is PE-to-PE, NOT CE-to-CE, 485 having a different SA for each VPN does not provide any additional 486 security. 488 It is conceivable that there might need to be two (or more) SAs 489 between a pair of PEs, e.g., one in which data encryption is used and 490 one in which authentication but not encryption is used. But this is 491 not the same as having a separate SA for each VPN. 493 We assume that the PE router will contain an IPsec module (either a 494 hardware or a software module) which is responsible for doing the key 495 exchange, for setting up the IPsec SAs as needed, and for doing the 496 cryptography. 498 As discussed in section 2.2, the PE router creates an MPLS-in-IP or 499 MPLS-in-GRE encapsulated packet. It does not simply send that packet 500 to its next hop, rather, it delivers the packet, along with the 501 corresponding IPsec Extended Community value, to the IPsec module. 502 (As an implementation consideration, it is not really required to 503 deliver an MPLS-in-IP or MPLS-in-GRE encapsulated packet to the IPsec 504 module; all that really needs to be delivered is the MPLS packet and 505 the information, or a pointer thereto, that would be needed to create 506 the IP encapsulation header.) 508 The IPsec module will set up an IPsec SA to the packet's destination 509 address, if one does not already exist. It will then apply the 510 appropriate IPsec procedures, generating a packet with an IP header 511 followed by an IPsec header followed by an MPLS label stack followed 512 by the original data packet. The IPsec module then delivers this 513 packet, as if it were a brand new packet, to the routing module. The 514 routing module forwards it as an IP packet. 516 While the IPsec SA is being set up, packets cannot be delivered 517 through it. Packets may be dropped during this time, though a 518 sensible policy might be to queue the first packet and drop the rest 519 (as is commonly done in ARP implementations while awaiting an ARP 520 resolution). 522 We do assume here that the IPsec module is subsidiary to the PE 523 router, and does not function itself as an independent router in the 524 network. A solution could be designed to support the latter case, but 525 at a considerable increment in complexity. 527 The procedure as specified above requires two routing lookups. Before 528 IPsec processing, The original packet's destination address is looked 529 up in a VRF. After IPsec processing, the IPsec packet's destination 530 address is looked up in the default routing table. It is worth 531 noting that the information obtained from the second lookup is really 532 available at the time of the first lookup. In some routers, it might 533 be advantageous to forward this information, along with the packet, 534 to the IPsec module; possibly this can be used to avoid the need for 535 the second lookup. However, in some routers, it will be impossible to 536 avoid the second lookup. 538 2.7. Application of IPsec by Egress PE 540 We assume that every egress PE is also an ingress PE, and hence has 541 the IPsec module which is mentioned in section 2.2. This module will 542 handle the necessary IKE functions, SA and tunnel maintenance, etc., 543 etc, as well as handling arriving IPsec packets. The IPsec module 544 will apply the necessary IPsec procedures to arriving IPsec packets, 545 and will hence recover the contained MPLS-in-IP or MPLS-in-GRE 546 packets. The IPsec module should then strip off the encapsulating IP 547 header to recover the MPLS packet, and should then deliver the 548 resulting MPLS packet to the routing function for ordinary MPLS 549 switching. (Of course, as an implementation matter, there is probably 550 no need to put the encapsulating IP header on only to then take it 551 off immediately.) 553 There are subtle issues having to do with the proper handling of MPLS 554 packets (rather than IPsec packets) which the PE router receives from 555 P routers or from other PE routers. If the top label on a received 556 MPLS packet corresponds to an IP route in the "default" routing 557 table, "ordinary" MPLS switching is done. But if the top label on a 558 received MPLS packet corresponds to a VPN-IP route, there are a 559 number of different cases to consider: 561 a. The packet has just been removed from an IPsec SA by the IPsec 562 module. In this case, ordinary MPLS switching should be done. 563 (though see below for further qualifications.) 565 b. The packet arrived from a neighboring P or PE router as an MPLS 566 packet, with no IPsec encapsulation. There are a number of 567 sub-cases: 569 i. The packet's top label corresponds to a VPN-IP route 570 which was not exported with the IPsec Extended 571 Community attribute. In this case, ordinary MPLS 572 switching is applied. 574 ii. The packet's top label corresponds to a VPN-IP route 575 which was exported with the value of the IPsec Extended 576 Community attribute which indicates that IPsec is to be 577 used only when the ingress PE is in a different SP 578 network. In this case, we assume that MPLS packets are 579 not being accepted from other networks, so ordinary 580 MPLS switching is applied. 582 iii. The packet's top label corresponds to a VPN-IP route 583 which was exported with an IPsec Extended Community, 584 but case ii does not apply. In this case the packet 585 should be discarded; packets with this label are 586 supposed to be secured, but this packet was not 587 properly secured. 589 Providing this functionality requires the use of two separate label 590 lookup tables, one of which is used for packets that have been 591 removed from IPsec SAs, and one of which is used for other packets. 592 Labels which are only valid when they are carried within an IPsec 593 packet would only appear in the former lookup table. This does imply 594 that after a packet has been processed by the IPsec module, the 595 contained MPLS packet is not simply returned to the routing lookup 596 path; rather it must carry some indication of which label lookup 597 table must be used to switch that packet. This also presupposes that 598 there will be MPLS VPN code to properly populate the two different 599 lookup tables. Perhaps packets removed from IPsec SAs should appear, 600 to the routing module, to be arriving on a particular virtual 601 interface, rather than on the actual sub-interface over which they 602 really arrived. Then interface-specific label lookup tables could be 603 used. 605 In fact, it may be advantageous to have more than one label lookup 606 table that is used for packets that have been removed from IPsec SAs. 607 Certain VPN-IP routes will be exported to certain SPs, but not to 608 others. Security can thus be improved by having one label lookup 609 table for each such SP. The IPsec module would then have to say, for 610 each packet, which SP it came from. Given a proper certificate 611 authority infrastructure this can be inferred by the IPsec module 612 from the information which the IKE procedure makes available to it. 613 Of course, all this presupposes that the VPN code is capable of 614 properly populating the various lookup tables. 616 3. Comparison with Using Part of SPI Field as a Label 618 An alternative methodology that achieves similar results is the one 619 described in [VPN-SPI]. The proposal described above was in fact 620 inspired by that draft, and arose as a proposed improvement to it. 622 In the current proposal, IPsec transport mode is applied to an MPLS- 623 in-IP encapsulation, where the MPLS-in-IP encapsulation carries the 624 BGP-distributed labels of RFC 2547. In [VPN-SPI], there is no MPLS- 625 in-IP encapsulation. Rather: 627 - IPsec tunnel mode is applied to the enduser's packet directly. 629 - A subfield of the IPsec SPI field is used to provide the function 630 of the BGP-distributed MPLS label. This either requires that BGP 631 distribute a different kind of label (one that can fit into the 632 SPI sub-field), or that an MPLS label be carried within the SPI 633 field. 635 The [VPN-SPI] proposal does have the advantage of making each packet 636 4 bytes shorter, since an entire entry in the MPLS label stack is 637 eliminated (replaced by the SPI sub-field). 639 The current proposal, unlike that in [VPN-SPI], does not in any way 640 alter the use or interpretation of the SPI field, and does not impact 641 the IPsec or IKE protocols and procedures in any way. The current 642 proposal also better preserves the distinction between fields that 643 are meaningful to IPsec and fields that are meaningful to 644 routing/forwarding. Failure to preserve this layering could 645 potentially lead to complications in the future (e.g., if BGP ever 646 needed to distribute a stack of two MPLS labels, or if some 647 enhancement to IPsec ever needed to reclaim the SPI sub-field used to 648 carry the label, etc., etc.). Failure to preserve the layering also 649 complicates the situation in which the transport is sometimes IPsec 650 and sometimes MPLS. Keeping the MPLS VPN functionality in the MPLS 651 layer and out of the IPsec layer certainly seems worthwhile. 653 4. Authors' Addresses 655 Eric C. Rosen 656 Cisco Systems, Inc. 657 1414 Massachusetts Avenue 658 Boxborough, MA 01719 659 Email: erosen@cisco.com 661 Jeremy De Clercq 662 Alcatel 663 Francis Wellesplein 1 664 2018 Antwerpen, Belgium 665 Phone: +32 3 240 4752 666 Email: jeremy.de_clercq@alcatel.be 667 Olivier Paridaens 668 Alcatel 669 Francis Wellesplein 1 670 2018 Antwerpen, Belgium 671 Phone: +32 3 240 9320 672 Email: olivier.paridaens@alcatel.be 674 Yves T'Joens 675 Alcatel 676 Francis Wellesplein 1 677 2018 Antwerpen, Belgium 678 Phone: +32 3 240 7890 679 Email: yves.tjoens@alcatel.be 681 Chandru Sargor 682 CoSine Communications 683 1200 Bridge Parkway 684 Redwood City, CA 94065 685 Email: csargor@cosinecom.com 687 5. Normative References 689 [RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn- 690 rfc2547bis-01.txt, September 2003 692 6. Informative References 694 [MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al., 695 draft-ietf-mpls-in-ip-or-gre-05.txt, February 2004 697 [VPN-SPI] BGP/IPsec VPN, De Clercq et. al., draft-declercq-bgp- 698 ipsec-vpn-01.txt, February 2001 700 7. Intellectual Property Statement 702 The IETF takes no position regarding the validity or scope of any 703 Intellectual Property Rights or other rights that might be claimed to 704 pertain to the implementation or use of the technology described in 705 this document or the extent to which any license under such rights 706 might or might not be available; nor does it represent that it has 707 made any independent effort to identify any such rights. Information 708 on the procedures with respect to rights in RFC documents can be 709 found in BCP 78 and BCP 79. 711 Copies of IPR disclosures made to the IETF Secretariat and any 712 assurances of licenses to be made available, or the result of an 713 attempt made to obtain a general license or permission for the use of 714 such proprietary rights by implementers or users of this 715 specification can be obtained from the IETF on-line IPR repository at 716 http://www.ietf.org/ipr. 718 The IETF invites any interested party to bring to its attention any 719 copyrights, patents or patent applications, or other proprietary 720 rights that may cover technology that may be required to implement 721 this standard. Please address the information to the IETF at ietf- 722 ipr@ietf.org. 724 8. Full Copyright Statement 726 Copyright (C) The Internet Society (2004). This document is subject 727 to the rights, licenses and restrictions contained in BCP 78 and 728 except as set forth therein, the authors retain all their rights. 730 This document and the information contained herein are provided on an 731 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 732 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 733 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 734 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 735 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 736 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 738 Rebecca F. Bunch 740 Network Working Group Eric C. Rosen 741 Internet Draft Cisco Systems, Inc. 742 Expiration Date: September 2004 743 Jeremy De Clercq 744 Olivier Paridaens 745 Yves T'Joens 746 Alcatel 748 Chandru Sargor 749 Cosine Communications 751 March 2004 753 Use of PE-PE IPsec in RFC2547 VPNs 755 draft-ietf-l3vpn-ipsec-2547-02.txt 757 Status of this Memo 759 This document is an Internet-Draft and is in full conformance with 760 all provisions of Section 10 of RFC2026. 762 Internet-Drafts are working documents of the Internet Engineering 763 Task Force (IETF), its areas, and its working groups. Note that other 764 groups may also distribute working documents as Internet-Drafts. 766 Internet-Drafts are draft documents valid for a maximum of six months 767 and may be updated, replaced, or obsoleted by other documents at any 768 time. It is inappropriate to use Internet-Drafts as reference 769 material or to cite them other than as "work in progress." 771 The list of current Internet-Drafts can be accessed at 772 http://www.ietf.org/ietf/1id-abstracts.txt. 774 The list of Internet-Draft Shadow Directories can be accessed at 775 http://www.ietf.org/shadow.html. 777 Abstract 779 In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets 780 traveling from one Provider Edge (PE) router to another generally 781 carry two MPLS labels, an inner label that corresponds to a VPN- 782 specific route, and an outer label that corresponds to a Label 783 Switched Path (LSP) between the PE routers. In some circumstances, 784 it is desirable to support the same type of VPN architecture, but 785 using an IPsec Security Association in place of that LSP. The outer 786 MPLS label would thus be replaced by an IP/IPsec header. This 787 enables the VPN packets to be carried securely over non-MPLS 788 networks, using standard IPsec authentication and/or encryption 789 functions to protect them. This draft specifies the procedures which 790 are specific to support of BGP/MPLS IP VPNs using the IPsec 791 encapsulation. 793 Table of Contents 795 1 Introduction ........................................... 3 796 1.1 Issue: MPLS Infrastructure Required .................... 4 797 1.2 Issue: Protection Against Misbehavior by Transit Nodes . 5 798 1.3 Issue: Limitations on Multi-Provider Misconfigurations . 5 799 1.4 Issue: Privacy for VPN Data ............................ 6 800 1.5 Non-Issue: General Protection against Misconfiguration . 7 801 1.6 Conclusion ............................................. 7 802 2 Specification .......................................... 7 803 2.1 Technical Approach ..................................... 7 804 2.2 Selecting the Security Policy .......................... 8 805 2.3 BGP Label, Route, and Policy Distribution .............. 9 806 2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10 807 2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11 808 2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11 809 2.7 Application of IPsec by Egress PE ...................... 13 810 3 Comparison with Using Part of SPI Field as a Label ..... 14 811 4 Authors' Addresses ..................................... 15 812 5 Normative References ................................... 16 813 6 Informative References ................................. 16 814 7 Intellectual Property Statement ........................ 17 815 8 Full Copyright Statement ............................... 17 817 1. Introduction 819 The present document uses terminology from [RFC2547bis], and 820 presupposes familiarity with that document and its terminology. 822 In BGP/MPLS IP VPNs, when an ingress PE router receives a packet from 823 a CE router, it looks up the packet's destination IP address in a 824 VRF. As a result of this lookup, it learns the output interface on 825 which the packet must be sent, and it also learns the set of headers 826 which must be prepended to the packet before it is sent on that 827 interface. In "conventional" BGP/MPLS IP VPNs, this set of headers 828 consists of a data link layer header, possibly followed by an MPLS 829 label stack. If the packet is going out an interface to a CE router 830 (i.e. the ingress PE is the same as the egress PE), no MPLS label 831 stack is needed. If the packet's egress PE router is directly 832 adjacent to the ingress PE, the MPLS label stack will have one or 833 more entries. In other cases, the MPLS label stack has two or more 834 entries. 836 The bottom label on the MPLS label stack is always a label which will 837 not be seen until the packet reaches its point of egress from the 838 network. This label represents a particular route within the packet's 839 VPN, and we will call it the "VPN route label". Directly above the 840 VPN route label is a label which represents a route across the 841 backbone to the egress PE router. We will call this label the 842 "backbone route label". 844 The backbone route label may or may not be the packet's top label; 845 additional entries may also be pushed on the label stack, if 846 additional MPLS services (e.g., traffic engineering) are used to 847 carry traffic to the egress PE. These additional labels may be 848 pushed on by the ingress PE, or by a P router somewhere along the 849 path. The VPN route label is always the packet's bottom label, 850 however. 852 This document specifies procedures for replacing the backbone route 853 label with an IPsec encapsulation. In effect, this creates an MPLS- 854 in-IPsec encapsulation, in which the VPN route label is carried 855 across the network within an IPsec encapsulation. By "within an 856 IPsec encapsulation", we mean "in a packet containing an IP header 857 and an IPsec header". This IPsec encapsulation corresponds to an 858 IPsec Security Association (SA) whose two endpoints are the ingress 859 PE router and the egress PE router. The payload of the IPsec 860 encapsulation is an authenticated and/or encrypted MPLS packet, whose 861 label stack contains a single entry, viz., the VPN route label. The 862 payload of this MPLS packet is the user data packet being sent within 863 the VPN. 865 The IP/IPsec encapsulation will be used even if the ingress PE and 866 the egress PE are directly adjacent, i.e., even in the case where a 867 backbone route label would not be used. However, no IP/IPsec 868 encapsulation is applied if the ingress PE is the same device as the 869 egress PE. 871 If additional MPLS services, such as traffic engineering, are used in 872 the backbone network, an MPLS label stack will appear above the IP 873 header. This is orthogonal to any issues discussed in the present 874 document. This results in an MPLS packet containing an IP packet 875 containing an IPsec packet containing an MPLS packet; the latter MPLS 876 packet has a single label, the VPN route label. 878 This document is inspired by [VPN-SPI], and originated as an attempt 879 to improve upon it. 881 The remainder of section 1 outlines a number of issues which can be 882 addressed by the use of IPsec in this manner. 884 1.1. Issue: MPLS Infrastructure Required 886 "Conventional" BGP/MPLS IP VPNs require that there be an MPLS Label 887 Switched Path (LSP) between a packet's ingress PE router and its 888 egress PE router. This means that an RFC2547 VPN cannot be 889 implemented if there is a part of the path between the ingress and 890 egress PE routers which does not support MPLS. 892 In order to enable BGP/MPLS IP VPNs to be deployed even when there 893 are non-MPLS routers along the path between the ingress and egress PE 894 routers, it is desirable to have an alternative which allows the 895 backbone route label to be replaced with an IP header. This 896 encapsulating IP header would encapsulate an MPLS packet containing 897 only the VPN route label. The encapsulation header would have the 898 address of the egress PE in its destination IP address field; this 899 would cause the packet to be delivered to the egress PE. 901 It is possible to replace the backbone route label with an IP header, 902 possibly followed by a GRE header [MPLS-in-IP/GRE]. However, it then 903 becomes quite difficult, in general, to protect the VPNs against 904 spoofed packets. A Service Provider (SP) can protect against spoofed 905 MPLS packets by the simple expedient of not accepting MPLS packets 906 from outside its own boundaries (or more generally by keeping track 907 of which labels are validly received over which interfaces, and 908 discarding packets which arrive with labels that are not valid for 909 their incoming interfaces). Protection against spoofed IP packets 910 requires having all the boundary routers perform filtering; either 911 (a) filtering out packets from "outside" which are addressed to PE 912 routers, or (b) filtering out packets from "outside" which have 913 source addresses that belong "inside", and having PE routers refuse 914 to accept packets addressed to them but with "outside" source 915 addresses. The maintenance of these filter lists can be management- 916 intensive, and the their use at all border routers can affect the 917 performance seen by all traffic entering the SP's network. Further, 918 these filtering techniques may be difficult to apply in the case of 919 multi-provider VPNs, because in multi-provider VPNs, packets from 920 outside an SP's network can legitimately be addressed to its PE 921 routers. 923 If, on the other hand, the backbone route label is replaced by an 924 IPsec encapsulation, protection against spoofed packets does not rely 925 on filtering at the border. The cryptographic authentication 926 features of IPsec enable an egress PE to detect and discard packets 927 for a particular VPN that were not generated by a valid ingress PE 928 for that VPN. Thus spoofing protection is managed entirely at the 929 ingress and egress PE routers, transparently to the border routers. 930 IPsec does have its own management and performance implications, of 931 course. 933 1.2. Issue: Protection Against Misbehavior by Transit Nodes 935 Cryptographic authentication applied by the ingress PE on a PE-to-PE 936 basis can protect against the misrouting or modification (intentional 937 or accidental) of packets by the transit nodes. Packets which get 938 forwarded to the "wrong" egress PE will not pass authentication, nor 939 will packets which have been modified. As the VPN route label is 940 part of the IPsec packet payload, the egress PE will know that the 941 VPN route label was placed in the packet by a valid ingress PE. 943 1.3. Issue: Limitations on Multi-Provider Misconfigurations 945 Sometimes a VPN will have some sites which connect to one SP (SP1), 946 and some other sites which connect to another SP (SP2). 948 Consider a case in which VPN V1 has sites attaching to SP1 and SP2, 949 but VPN V2 has all of its sites attaching only to SP2. 951 SP2 would like to ensure that nothing done by SP1 can cause V1 to get 952 illegitimately cross-connected to V2. Since V2 has no sites in SP1, 953 it should be immune to the effects of any misconfigurations within 954 SP1. 956 This assurance can be achieved if the egress PE (in SP2) can 957 determine, for each VPN packet, whether that packet came from SP1, 958 and if so, whether it carries an MPLS label which corresponds to a 959 VPN route that was actually distributed to SP1. (That is, packets 960 originating from SP1 destined for VPNs in SP2 would be checked if 961 they are for VPNs which really have sites in SP1.) SP2's egress PEs 962 could be configured with the knowledge of which VPNs have sites 963 attached to SP1. Cryptographic authentication could then be used to 964 determine that a particular packet did indeed originate in SP1. 966 In general, if an egress PE knows which labels may be validly applied 967 by which ingress PEs, IPsec authentication can be used to ensure that 968 a given ingress PE has not applied a label that it has no right to 969 use. However, the scalability of the VPN scheme would be severely 970 compromised if an egress PE had to distribute a different set of 971 labels to each ingress PE. Therefore we will not pursue this general 972 case, but will only pursue label authentication in the inter-provider 973 case. 975 1.4. Issue: Privacy for VPN Data 977 IPsec Security Associations that associate ingress PE routes with 978 egress PE routers do not ensure privacy for VPN data. The data is 979 exposed on the PE-CE access links, and is exposed in the PE routers 980 themselves. Complete privacy requires that the encryption/decryption 981 be performed within the enterprise, not by the SP. So the use of 982 PE-PE IPsec encryption within the network of a single SP will perhaps 983 be of less import than the use of IPsec authentication. On the other 984 hand, if an SP is trusted to properly secure its routers, but the 985 transmission media used by the SP are not trusted, then PE-PE 986 encryption does provide a valuable measure of privacy. 988 There may be a need for encryption if a VPN has sites attached to 989 different trusted SPs, but some of the transit traffic needs to go 990 through the "public Internet". In this case, it may be necessary to 991 encrypt the VPN data traffic as it crosses the public Internet. 992 However, while PE-PE encryption is the one way to handle this, it is 993 not the only way. An alternative would be to use an encrypted tunnel 994 to connecting a border router of one trusted SP to a border router of 995 another. Then the two trusted domains could be treated as immediate 996 neighbors, adjacent over the tunnel. This would keep the 997 encryption/decryption at the few locations where it is actually 998 needed. On the other hand, there may be performance and scalability 999 advantages to spreading the cost of the cryptography among a larger 1000 set of routers, viz., the ingress and egress PEs. 1002 The scenario of having VPN traffic go from a trusted domain through 1003 an untrusted domain to another trusted domain may not be completely 1004 realistic, though, due to the difficulty of supporting the necessary 1005 Service Level Agreements through the public Internet. 1007 1.5. Non-Issue: General Protection against Misconfiguration 1009 In general, the integrity of an RFC2547 VPN depends upon the SP 1010 having properly configured the PE routers. There is no way of 1011 preventing an SP from creating a bogus VPN that contains sites which 1012 aren't supposed to communicate with each other. It is the SP's 1013 responsibility to get this right. 1015 It is sometimes thought one can obtain protection against 1016 misconfigurations by having the PE routers apply cryptographic 1017 authentication to the VPN packets. This is not the case. If an 1018 ingress PE router has been misconfigured so as to assign a particular 1019 site to the wrong VPN, likely as not the PE has been misconfigured to 1020 apply that VPN's authenticator to packets to/from that site. 1022 Protection against misconfiguration on the part of the SP requires 1023 that the authentication procedure be applied before the ingress PE 1024 router sees the packets, and after the egress PE router forwards 1025 them, and cannot be dealt with by PE-PE IPsec. 1027 1.6. Conclusion 1029 Taken together, the above set of issues suggest that there are 1030 situations in which using PE-PE IPsec as the tunneling protocol for 1031 BGP/MPLS IP VPNs does have value. In the next section, we specify 1032 the necessary procedures for incorporating PE-PE IPsec as a tunneling 1033 option for BGP/MPLS IP VPNs. 1035 2. Specification 1037 2.1. Technical Approach 1039 In short, the technical approach specified here is: 1041 1. Use the standard technique [RFC2547bis] of using an MPLS label 1042 to represent a VPN route, by prepending an MPLS label stack to 1043 the VPN packets. However, the label stack will contain only one 1044 label, the VPN route label. 1046 2. Use an MPLS-in-IP or MPLS-in-GRE encapsulation to turn the 1047 above MPLS packet back into an IP packet. This in effect 1048 creates an "IP tunnel" or a "GRE tunnel" between the ingress PE 1049 router and the egress PE router. 1051 3. Use IPsec Transport Mode to secure the above-mentioned IP 1052 tunnels. 1054 The net effect is that an MPLS packet gets sent through an IPsec- 1055 secured IP or GRE tunnel. 1057 The following sub-sections specify this procedure in greater detail. 1059 2.2. Selecting the Security Policy 1061 One might think that a given SP (or set of cooperating SPs) will 1062 decide either that they need to use IPsec for ALL PE-PE tunnels, or 1063 else that PE-PE IPsec is not needed at all. But this simple "all or 1064 nothing" strategy does not really capture the set of considerations 1065 discussed in the Introduction. For example, a very reasonable policy 1066 might be to use IPsec only for inter-provider PE-PE tunnels, while 1067 using MPLS for intra-provider PE-PE tunnels. Or one might decide to 1068 use IPsec only for certain inter-provider tunnels. Or one might 1069 decide to use IPsec for certain intra-provider tunnels. 1071 In an RFC2547 VPN environment, it makes most sense to place control 1072 of the policies with the egress PE router. It is the egress PE which 1073 needs to know that it wants to process certain packets ONLY if they 1074 come through encrypted tunnels, and that it wants to discard those 1075 same packets if they don't come through encrypted tunnels. Thus one 1076 needs to be able to configure a policy into the egress PE, and have 1077 it signal that policy to the ingress PE. RFC2547 already provides an 1078 egress-to-ingress signaling capability via BGP, and we specify below 1079 how to extend this to the signalling of security policy. 1081 Of course, there is nothing to stop an ingress PE router from being 1082 configured to use IPsec even if the egress PE has not signalled its 1083 desire for IPsec. This should work, as long as the necessary IPsec 1084 infrastructure is in place. (However, in this sort of application 1085 the ingress PE and the egress PE are NOT really independent entities 1086 which might conceivably have different security policies.) 1088 2.3. BGP Label, Route, and Policy Distribution 1090 Distribution of labeled VPN-IP routes by BGP is done exactly as 1091 specified in [RFC2547bis], except that some additional BGP attributes 1092 are needed for each distributed VPN-IP route. 1094 A given egress PE will be configurable to indicate whether it expects 1095 to receive all, some, or none of its VPN traffic through an IPsec- 1096 secured IP or GRE tunnel. In general, an ingress PE will not have to 1097 know in advance whether any of the egress PEs for its VPNs require 1098 their VPN traffic to be sent through an IPsec-secured IP tunnel; this 1099 will be signaled from the egress PE. If an egress PE wants to receive 1100 traffic for a particular VPN-IP route through an IPsec-secured IP 1101 tunnel, it adds a new BGP Extended Community attribute to the route. 1102 This attribute will then get distributed along with the route to the 1103 ingress PEs. 1105 We call this attribute the "IPsec Extended Community". (It is 1106 possible that this will actually be encoded as a particular value or 1107 set of values of a more general "Tunnel Type Extended Community"; for 1108 the purposes of this draft, however, we will continue to refer to it 1109 as the "IPsec Extended Community".) 1111 It is conceivable that an egress PE in a particular SP's network will 1112 only want to receive IPsec-secured IP-tunneled traffic for those VPNs 1113 which have sites that are attached to other SPs. In this case, one 1114 would want to be able to configure, on a per-VRF basis, whether 1115 routes exported from that VRF should have an IPsec Extended Community 1116 attribute or not. 1118 A more complex situation would arise if it were only desired to 1119 receive IPsec-secured IP-tunneled traffic for a particular VPN if 1120 that traffic has originated from a site which is attached to a 1121 different SP's network. That is, one might want to receive inter- 1122 provider traffic through an IPsec-secured IP tunnel, but to receive 1123 intra-provider traffic through an unsecured MPLS LSP. As long as an 1124 SP has a policy of never accepting MPLS packets from other SPs, this 1125 may provide the necessary security while minimizing the amount of 1126 cryptography that actually has to be used. 1128 One way to do this would be to map each exportable IP address prefix 1129 into two different VPN-IP prefixes, using two different RDs (say RD1 1130 and RD2). Then two different RTs (say RT1 and RT2) would be used, 1131 one of which causes intra-provider distribution, and one of which 1132 causes inter-provider distribution. The prefixes with RD1 would be 1133 given RT1 as a route target; the prefixes with RD2 would be given RT2 1134 as a route target. If RT2 is the route target that causes inter- 1135 provider distribution, then only the routes with RT2 would carry the 1136 IPsec Extended Community. 1138 A simpler approach, perhaps, would be to use only a single set of 1139 VPN-IP prefixes, but to have a value of the IPsec Extended Community 1140 which encodes an SP identifier, and which means "only use IPsec if 1141 the ingress PE is in a different SP network than the one which is 1142 identified here". (Again, the assumption is that MPLS packets are not 1143 accepted from other SPs.) 1145 It is conceivable that an egress PE will want some of its IPsec- 1146 secured IP-tunneled VPN traffic to be encrypted, but will want some 1147 to be authenticated and not encrypted. It is even conceivable that it 1148 will want some traffic to arrive through an IPsec tunnel without 1149 being either encrypted or authenticated. The IPsec Extended Community 1150 attribute should have a value which specifies which of these are 1151 required. 1153 It may be desirable to allow the IPsec Extended Community to specify 1154 a set of policies, so that the ingress PE can choose from among them. 1156 2.4. MPLS-in-IP/GRE Encapsulation by Ingress PE 1158 When a PE receives a packet from a CE, it looks up the packet's IP 1159 destination address in the VRF corresponding to that CE. This enables 1160 it to find a VPN-IP route. The VPN-IP route will have an associated 1161 MPLS label and an associated BGP Next Hop. The label is pushed on the 1162 packet. Then, if (and only if) the VPN-IP route has an IPsec Extended 1163 Community attribute, an IP or GRE encapsulation header is prepended 1164 to the packet, creating an MPLS-in-IP or MPLS-in-GRE encapsulated 1165 packet. The IP source address field of the encapsulation header will 1166 be an address of the ingress PE itself. The IP destination address 1167 field of the encapsulation header will contain the value of the 1168 associated BGP Next Hop attribute; this will be an IP address of the 1169 egress PE. 1171 (This description is not meant to specify an implementation strategy; 1172 any implementation procedure which produces the same result is 1173 acceptable.) 1175 N.B.: If the ingress PE and the egress PE are not in the same 1176 autonomous system, this requires that there be an EBGP connection 1177 between a router in one autonomous system and a router in another. If 1178 the two autonomous systems are not adjacent, this will need to be a 1179 multi-hop EBGP connection. 1181 The effect is to dynamically create an IP tunnel between the ingress 1182 and egress PE routers. No apriori configuration of the remote tunnel 1183 endpoints is needed. Note that these IP tunnels are NOT IGP-visible 1184 links, and routing adjacencies are NOT supported across these tunnel. 1185 Note also that the set of remote tunnel endpoints is NOT known in 1186 advance, but is learned dynamically via the BGP distribution of VPN- 1187 IP routes. 1189 These IP tunneled packets will then be associated with an IPsec 1190 Security Association (SA), and transported using IPsec transport 1191 mode. This is described in more detail in the next sub-section. 1193 2.5. MPLS-in-IP vs. MPLS-in-GRE 1195 The MPLS-in-IP encapsulation header is shorter than the MPLS-in-GRE 1196 encapsulation header, and, in theory at least, the latter offers no 1197 advantages to compensate for its use of a longer header. 1199 In practice, implementation considerations of various sorts may make 1200 the MPLS-in-GRE encapsulation preferable. 1202 2.6. PE-PE IPsec (Application of IPsec by Ingress PE) 1204 A given ingress PE needs to have an IPsec SA with each PE router that 1205 is an egress PE for traffic which the ingress PE receives from a CE. 1207 In general, the set of egress PEs for a given ingress PE is not known 1208 in advance. This is determined dynamically by the BGP distribution of 1209 VPN-IP routes. This suggests that it will be very important to be 1210 able to set up IPsec SAs dynamically, and that static keying will not 1211 be a viable option. There will need to be a key distribution 1212 infrastructure that supports multiple SPs, and IKE will need to be 1213 used. 1215 A number of different VPNs might need to have traffic carried from a 1216 particular ingress PE to a particular egress PE. It is thus natural 1217 to ask whether there should be one SA between the pair of PEs, or n 1218 SAs between the pair of PEs, where n is the number of VPNs. Clearly, 1219 scalability is improved by having only a single SA for each pair of 1220 PEs. So the question is whether there is a significant security 1221 advantage to having a distinct SA for each VPN. There does not appear 1222 to be any such advantage. Since the SA is PE-to-PE, NOT CE-to-CE, 1223 having a different SA for each VPN does not provide any additional 1224 security. 1226 It is conceivable that there might need to be two (or more) SAs 1227 between a pair of PEs, e.g., one in which data encryption is used and 1228 one in which authentication but not encryption is used. But this is 1229 not the same as having a separate SA for each VPN. 1231 We assume that the PE router will contain an IPsec module (either a 1232 hardware or a software module) which is responsible for doing the key 1233 exchange, for setting up the IPsec SAs as needed, and for doing the 1234 cryptography. 1236 As discussed in section 2.2, the PE router creates an MPLS-in-IP or 1237 MPLS-in-GRE encapsulated packet. It does not simply send that packet 1238 to its next hop, rather, it delivers the packet, along with the 1239 corresponding IPsec Extended Community value, to the IPsec module. 1240 (As an implementation consideration, it is not really required to 1241 deliver an MPLS-in-IP or MPLS-in-GRE encapsulated packet to the IPsec 1242 module; all that really needs to be delivered is the MPLS packet and 1243 the information, or a pointer thereto, that would be needed to create 1244 the IP encapsulation header.) 1246 The IPsec module will set up an IPsec SA to the packet's destination 1247 address, if one does not already exist. It will then apply the 1248 appropriate IPsec procedures, generating a packet with an IP header 1249 followed by an IPsec header followed by an MPLS label stack followed 1250 by the original data packet. The IPsec module then delivers this 1251 packet, as if it were a brand new packet, to the routing module. The 1252 routing module forwards it as an IP packet. 1254 While the IPsec SA is being set up, packets cannot be delivered 1255 through it. Packets may be dropped during this time, though a 1256 sensible policy might be to queue the first packet and drop the rest 1257 (as is commonly done in ARP implementations while awaiting an ARP 1258 resolution). 1260 We do assume here that the IPsec module is subsidiary to the PE 1261 router, and does not function itself as an independent router in the 1262 network. A solution could be designed to support the latter case, but 1263 at a considerable increment in complexity. 1265 The procedure as specified above requires two routing lookups. Before 1266 IPsec processing, The original packet's destination address is looked 1267 up in a VRF. After IPsec processing, the IPsec packet's destination 1268 address is looked up in the default routing table. It is worth 1269 noting that the information obtained from the second lookup is really 1270 available at the time of the first lookup. In some routers, it might 1271 be advantageous to forward this information, along with the packet, 1272 to the IPsec module; possibly this can be used to avoid the need for 1273 the second lookup. However, in some routers, it will be impossible to 1274 avoid the second lookup. 1276 2.7. Application of IPsec by Egress PE 1278 We assume that every egress PE is also an ingress PE, and hence has 1279 the IPsec module which is mentioned in section 2.2. This module will 1280 handle the necessary IKE functions, SA and tunnel maintenance, etc., 1281 etc, as well as handling arriving IPsec packets. The IPsec module 1282 will apply the necessary IPsec procedures to arriving IPsec packets, 1283 and will hence recover the contained MPLS-in-IP or MPLS-in-GRE 1284 packets. The IPsec module should then strip off the encapsulating IP 1285 header to recover the MPLS packet, and should then deliver the 1286 resulting MPLS packet to the routing function for ordinary MPLS 1287 switching. (Of course, as an implementation matter, there is probably 1288 no need to put the encapsulating IP header on only to then take it 1289 off immediately.) 1291 There are subtle issues having to do with the proper handling of MPLS 1292 packets (rather than IPsec packets) which the PE router receives from 1293 P routers or from other PE routers. If the top label on a received 1294 MPLS packet corresponds to an IP route in the "default" routing 1295 table, "ordinary" MPLS switching is done. But if the top label on a 1296 received MPLS packet corresponds to a VPN-IP route, there are a 1297 number of different cases to consider: 1299 a. The packet has just been removed from an IPsec SA by the IPsec 1300 module. In this case, ordinary MPLS switching should be done. 1301 (though see below for further qualifications.) 1303 b. The packet arrived from a neighboring P or PE router as an MPLS 1304 packet, with no IPsec encapsulation. There are a number of 1305 sub-cases: 1307 i. The packet's top label corresponds to a VPN-IP route 1308 which was not exported with the IPsec Extended 1309 Community attribute. In this case, ordinary MPLS 1310 switching is applied. 1312 ii. The packet's top label corresponds to a VPN-IP route 1313 which was exported with the value of the IPsec Extended 1314 Community attribute which indicates that IPsec is to be 1315 used only when the ingress PE is in a different SP 1316 network. In this case, we assume that MPLS packets are 1317 not being accepted from other networks, so ordinary 1318 MPLS switching is applied. 1320 iii. The packet's top label corresponds to a VPN-IP route 1321 which was exported with an IPsec Extended Community, 1322 but case ii does not apply. In this case the packet 1323 should be discarded; packets with this label are 1324 supposed to be secured, but this packet was not 1325 properly secured. 1327 Providing this functionality requires the use of two separate label 1328 lookup tables, one of which is used for packets that have been 1329 removed from IPsec SAs, and one of which is used for other packets. 1330 Labels which are only valid when they are carried within an IPsec 1331 packet would only appear in the former lookup table. This does imply 1332 that after a packet has been processed by the IPsec module, the 1333 contained MPLS packet is not simply returned to the routing lookup 1334 path; rather it must carry some indication of which label lookup 1335 table must be used to switch that packet. This also presupposes that 1336 there will be MPLS VPN code to properly populate the two different 1337 lookup tables. Perhaps packets removed from IPsec SAs should appear, 1338 to the routing module, to be arriving on a particular virtual 1339 interface, rather than on the actual sub-interface over which they 1340 really arrived. Then interface-specific label lookup tables could be 1341 used. 1343 In fact, it may be advantageous to have more than one label lookup 1344 table that is used for packets that have been removed from IPsec SAs. 1345 Certain VPN-IP routes will be exported to certain SPs, but not to 1346 others. Security can thus be improved by having one label lookup 1347 table for each such SP. The IPsec module would then have to say, for 1348 each packet, which SP it came from. Given a proper certificate 1349 authority infrastructure this can be inferred by the IPsec module 1350 from the information which the IKE procedure makes available to it. 1351 Of course, all this presupposes that the VPN code is capable of 1352 properly populating the various lookup tables. 1354 3. Comparison with Using Part of SPI Field as a Label 1356 An alternative methodology that achieves similar results is the one 1357 described in [VPN-SPI]. The proposal described above was in fact 1358 inspired by that draft, and arose as a proposed improvement to it. 1360 In the current proposal, IPsec transport mode is applied to an MPLS- 1361 in-IP encapsulation, where the MPLS-in-IP encapsulation carries the 1362 BGP-distributed labels of RFC 2547. In [VPN-SPI], there is no MPLS- 1363 in-IP encapsulation. Rather: 1365 - IPsec tunnel mode is applied to the enduser's packet directly. 1367 - A subfield of the IPsec SPI field is used to provide the function 1368 of the BGP-distributed MPLS label. This either requires that BGP 1369 distribute a different kind of label (one that can fit into the 1370 SPI sub-field), or that an MPLS label be carried within the SPI 1371 field. 1373 The [VPN-SPI] proposal does have the advantage of making each packet 1374 4 bytes shorter, since an entire entry in the MPLS label stack is 1375 eliminated (replaced by the SPI sub-field). 1377 The current proposal, unlike that in [VPN-SPI], does not in any way 1378 alter the use or interpretation of the SPI field, and does not impact 1379 the IPsec or IKE protocols and procedures in any way. The current 1380 proposal also better preserves the distinction between fields that 1381 are meaningful to IPsec and fields that are meaningful to 1382 routing/forwarding. Failure to preserve this layering could 1383 potentially lead to complications in the future (e.g., if BGP ever 1384 needed to distribute a stack of two MPLS labels, or if some 1385 enhancement to IPsec ever needed to reclaim the SPI sub-field used to 1386 carry the label, etc., etc.). Failure to preserve the layering also 1387 complicates the situation in which the transport is sometimes IPsec 1388 and sometimes MPLS. Keeping the MPLS VPN functionality in the MPLS 1389 layer and out of the IPsec layer certainly seems worthwhile. 1391 4. Authors' Addresses 1393 Eric C. Rosen 1394 Cisco Systems, Inc. 1395 1414 Massachusetts Avenue 1396 Boxborough, MA 01719 1397 Email: erosen@cisco.com 1399 Jeremy De Clercq 1400 Alcatel 1401 Francis Wellesplein 1 1402 2018 Antwerpen, Belgium 1403 Phone: +32 3 240 4752 1404 Email: jeremy.de_clercq@alcatel.be 1405 Olivier Paridaens 1406 Alcatel 1407 Francis Wellesplein 1 1408 2018 Antwerpen, Belgium 1409 Phone: +32 3 240 9320 1410 Email: olivier.paridaens@alcatel.be 1412 Yves T'Joens 1413 Alcatel 1414 Francis Wellesplein 1 1415 2018 Antwerpen, Belgium 1416 Phone: +32 3 240 7890 1417 Email: yves.tjoens@alcatel.be 1419 Chandru Sargor 1420 CoSine Communications 1421 1200 Bridge Parkway 1422 Redwood City, CA 94065 1423 Email: csargor@cosinecom.com 1425 5. Normative References 1427 [RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn- 1428 rfc2547bis-01.txt, September 2003 1430 6. Informative References 1432 [MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al., 1433 draft-ietf-mpls-in-ip-or-gre-05.txt, February 2004 1435 [VPN-SPI] BGP/IPsec VPN, De Clercq et. al., draft-declercq-bgp- 1436 ipsec-vpn-01.txt, February 2001 1438 7. Intellectual Property Statement 1440 The IETF takes no position regarding the validity or scope of any 1441 Intellectual Property Rights or other rights that might be claimed to 1442 pertain to the implementation or use of the technology described in 1443 this document or the extent to which any license under such rights 1444 might or might not be available; nor does it represent that it has 1445 made any independent effort to identify any such rights. Information 1446 on the procedures with respect to rights in RFC documents can be 1447 found in BCP 78 and BCP 79. 1449 Copies of IPR disclosures made to the IETF Secretariat and any 1450 assurances of licenses to be made available, or the result of an 1451 attempt made to obtain a general license or permission for the use of 1452 such proprietary rights by implementers or users of this 1453 specification can be obtained from the IETF on-line IPR repository at 1454 http://www.ietf.org/ipr. 1456 The IETF invites any interested party to bring to its attention any 1457 copyrights, patents or patent applications, or other proprietary 1458 rights that may cover technology that may be required to implement 1459 this standard. Please address the information to the IETF at ietf- 1460 ipr@ietf.org. 1462 8. Full Copyright Statement 1464 Copyright (C) The Internet Society (2004). This document is subject 1465 to the rights, licenses and restrictions contained in BCP 78 and 1466 except as set forth therein, the authors retain all their rights. 1468 This document and the information contained herein are provided on an 1469 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1470 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1471 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1472 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1473 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1474 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.