idnits 2.17.1 draft-ietf-l3vpn-ipsec-2547-05.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.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 781. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 2005) is 6828 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-mpls-over-l2tpv3-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: February 2006 5 Jeremy De Clercq 6 Olivier Paridaens 7 Yves T'Joens 8 Alcatel 10 Chandru Sargor 12 August 2005 14 Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs 16 draft-ietf-l3vpn-ipsec-2547-05.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets 43 traveling from one Provider Edge (PE) router to another generally 44 carry two MPLS labels, an "inner" label that corresponds to a VPN- 45 specific route, and an "outer" label that corresponds to a Label 46 Switched Path (LSP) between the PE routers. In some circumstances, 47 it is desirable to support the same type of VPN architecture, but 48 using an IPsec Security Association in place of that LSP. The 49 "outer" MPLS label would thus be replaced by an IP/IPsec header. 50 This enables the VPN packets to be carried securely over non-MPLS 51 networks, using standard IPsec authentication and/or encryption 52 functions to protect them. This draft specifies the procedures which 53 are specific to support of BGP/MPLS IP VPNs using the IPsec 54 encapsulation. 56 Table of Contents 58 1 Introduction ........................................... 3 59 1.1 Issue: Protection Against Spoofed Packets .............. 4 60 1.2 Issue: Protection Against Misbehavior by Transit Nodes . 5 61 1.3 Issue: Limitations on Multi-Provider Misconfigurations . 5 62 1.4 Issue: Privacy for VPN Data ............................ 6 63 1.5 Non-Issue: General Protection against Misconfiguration . 7 64 1.6 Conclusion ............................................. 7 65 2 Specification .......................................... 7 66 2.1 Technical Approach ..................................... 7 67 2.2 Selecting the Security Policy .......................... 8 68 2.3 BGP Label, Route, and Policy Distribution .............. 9 69 2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10 70 2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11 71 2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11 72 2.7 Application of IPsec by Egress PE ...................... 13 73 3 Comparison with Using Part of SPI Field as a Label ..... 15 74 4 Security Considerations ................................ 16 75 5 IANA Considerations .................................... 16 76 6 Acknowledgments ........................................ 16 77 7 Authors' Addresses ..................................... 16 78 8 Normative References ................................... 17 79 9 Informative References ................................. 17 80 10 Full Copyright Statement ............................... 17 81 11 Intellectual Property .................................. 18 83 1. Introduction 85 The present document uses terminology from [RFC2547bis], and 86 presupposes familiarity with that document and its terminology. 88 In BGP/MPLS IP VPNs, when an ingress PE router receives a packet from 89 a CE router, it looks up the packet's destination IP address in a VRF 90 ("VPN Routing and Forwarding Table"). As a result of this lookup, it 91 learns the output interface on which the packet must be sent, and it 92 also learns the set of headers which must be prepended to the packet 93 before it is sent on that interface. In "conventional" BGP/MPLS IP 94 VPNs, this set of headers consists of a data link layer header 95 followed by (possibly) an MPLS label stack. If the packet is going 96 out an interface to a CE router (i.e. the ingress PE is the same as 97 the egress PE), no MPLS label stack is needed. If the packet's 98 egress PE router is directly adjacent to the ingress PE, the MPLS 99 label stack will have one or more entries. In other cases, the MPLS 100 label stack has two or more entries. 102 Unless the packet goes directly to a CE router on the same PE, the 103 MPLS label stack will contain a label that will not be seen until the 104 packet reaches its point of egress from the network. This label 105 represents a particular route within the packet's VPN, and we will 106 call it the "VPN route label". Directly above the VPN route label is 107 a label which represents a route across the backbone to the egress PE 108 router. We will call this label the "backbone route label". 110 The backbone route label may or may not be the packet's top label; 111 additional entries may also be pushed on the label stack, if 112 additional MPLS services (e.g., traffic engineering) are used to 113 carry traffic to the egress PE. These additional labels may be 114 pushed on by the ingress PE, or by a P router somewhere along the 115 path. 117 This document specifies procedures for replacing the backbone route 118 label with an IPsec encapsulation. In effect, this creates an MPLS- 119 in-IPsec encapsulation, in which the VPN route label is carried 120 across the network within an IPsec encapsulation. By "within an 121 IPsec encapsulation", we mean "in a packet containing an IP header 122 and an IPsec header". This IPsec encapsulation corresponds to an 123 IPsec Security Association (SA) whose two endpoints are the ingress 124 PE router and the egress PE router. The payload of the IPsec 125 encapsulation is an authenticated and/or encrypted MPLS packet, whose 126 label stack contains a single entry, viz., the VPN route label. The 127 payload of this MPLS packet is the user data packet being sent within 128 the VPN. 130 The IP/IPsec encapsulation will be used even if the ingress PE and 131 the egress PE are directly adjacent, i.e., even in the case where a 132 backbone route label might not be used. However, no IP/IPsec 133 encapsulation is applied if the ingress PE is the same device as the 134 egress PE. 136 If additional MPLS services, such as traffic engineering, are used in 137 the backbone network, an MPLS label stack will appear above the IP 138 header. This is orthogonal to any issues discussed in the present 139 document. This results in an MPLS packet containing an IP packet 140 containing an IPsec packet containing an MPLS packet; the latter MPLS 141 packet may have only a single label, the VPN route label. 143 This document is inspired by [VPN-SPI], and originated as an attempt 144 to improve upon it. 146 The remainder of section 1 outlines a number of issues which can be 147 addressed by the use of IPsec in this manner. 149 1.1. Issue: Protection Against Spoofed Packets 151 According to [RFC2547bis]: 153 "Before a customer data packet travels across the Service 154 Provider's backbone, it is encapsulated with the MPLS label that 155 corresponds, in the customer's VPN, to the route that is the best 156 match to the packet's destination address. This MPLS packet is 157 further encapsulated (e.g., with another MPLS label, or with an 158 IP or GRE ("Generic Routing Encapsulation" tunnel header [MPLS- 159 in-IP-GRE]) so that it gets tunneled across the backbone to the 160 proper PE router." 162 This explicitly allows the use of three different tunnel 163 encapsulations: MPLS, MPLS-in-IP, and MPLS-in-GRE. [MPLS-in-L2TPv3] 164 allows a fourth. The latter three encapsulations all require the 165 packets to have an IP header in which the address of the egress PE 166 appears in the destination IP address field. However, it then 167 becomes quite difficult, in general, to protect the VPNs against 168 spoofed packets. 170 A Service Provider (SP) can protect against spoofed MPLS packets by 171 the simple expedient of not accepting MPLS packets from outside its 172 own boundaries (or more generally by keeping track of which labels 173 are validly received over which interfaces, and discarding packets 174 which arrive with labels that are not valid for their incoming 175 interfaces). However, this does depend on the assumption that the SP 176 network is not serving as a transit network for arbitrary MPLS 177 packets from other networks. 179 Protection against spoofed IP packets requires having all the 180 boundary routers perform filtering; either (a) filtering out packets 181 from "outside" which are addressed to PE routers, or (b) filtering 182 out packets from "outside" which have source addresses that belong 183 "inside", and having PE routers refuse to accept packets addressed to 184 them but with "outside" source addresses. The maintenance of these 185 filter lists can be management-intensive, and the their use at all 186 border routers can affect the performance seen by all traffic 187 entering the SP's network. Further, these filtering techniques may 188 be difficult to apply in the case of multi-provider VPNs, because in 189 multi-provider VPNs, packets from outside an SP's network can 190 legitimately be addressed to its PE routers. 192 If, on the other hand, the backbone route label is replaced by an 193 IPsec encapsulation, protection against spoofed packets does not rely 194 on any sort of filtering at the border. The cryptographic 195 authentication features of IPsec enable an egress PE to detect and 196 discard packets for a particular VPN that were not generated by a 197 valid ingress PE for that VPN. Thus spoofing protection is managed 198 entirely at the ingress and egress PE routers, transparently to the 199 border routers. IPsec does have its own management and performance 200 implications, of course. 202 1.2. Issue: Protection Against Misbehavior by Transit Nodes 204 Cryptographic authentication applied by the ingress PE on a PE-to-PE 205 basis can protect against the misrouting or modification (intentional 206 or accidental) of packets by the transit nodes. Packets which get 207 forwarded to the "wrong" egress PE will not pass authentication, nor 208 will packets which have been modified. As the VPN route label is 209 part of the IPsec packet payload, the egress PE will know that the 210 VPN route label was placed in the packet by a valid ingress PE. 212 1.3. Issue: Limitations on Multi-Provider Misconfigurations 214 Sometimes a VPN will have some sites which connect to one SP (SP1), 215 and some other sites which connect to another SP (SP2). 217 Consider a case in which VPN V1 has sites attaching to SP1 and SP2, 218 but VPN V2 has all of its sites attaching only to SP2. 220 SP2 would like to ensure that nothing done by SP1 can cause V1 to get 221 illegitimately cross-connected to V2. Since V2 has no sites in SP1, 222 it should be immune to the effects of any misconfigurations within 223 SP1. 225 This assurance can be achieved if the egress PE (in SP2) can 226 determine, for each VPN packet, whether that packet came from SP1, 227 and if so, whether it carries an MPLS label which corresponds to a 228 VPN route that was actually distributed to SP1. (That is, packets 229 originating from SP1 destined for VPNs in SP2 would be checked if 230 they are for VPNs which really have sites in SP1.) SP2's egress PEs 231 could be configured with the knowledge of which VPNs have sites 232 attached to SP1. Cryptographic authentication could then be used to 233 determine that a particular packet did indeed originate in SP1. 235 In general, if an egress PE knows which labels may be validly applied 236 by which ingress PEs, IPsec authentication can be used to ensure that 237 a given ingress PE has not applied a label that it has no right to 238 use. However, the scalability of the VPN scheme would be severely 239 compromised if an egress PE had to distribute a different set of 240 labels to each ingress PE. Therefore we will not pursue this general 241 case, but will only pursue label authentication in the inter-provider 242 case. 244 1.4. Issue: Privacy for VPN Data 246 IPsec Security Associations that associate ingress PE routes with 247 egress PE routers do not ensure privacy for VPN data. The data is 248 exposed on the PE-CE access links, and is exposed in the PE routers 249 themselves. Complete privacy requires that the encryption/decryption 250 be performed within the enterprise, not by the SP. So the use of 251 PE-PE IPsec encryption within the network of a single SP will perhaps 252 be of less import than the use of IPsec authentication. On the other 253 hand, if an SP is trusted to properly secure its routers, but the 254 transmission media used by the SP are not trusted, then PE-PE 255 encryption does provide a valuable measure of privacy. 257 There may be a need for encryption if a VPN has sites attached to 258 different trusted SPs, but some of the transit traffic needs to go 259 through the "public Internet". In this case, it may be necessary to 260 encrypt the VPN data traffic as it crosses the public Internet. 261 However, while PE-PE encryption is one way to handle this, it is not 262 the only way. An alternative would be to use an encrypted tunnel to 263 connect a border router of one trusted SP to a border router of 264 another. Then the two trusted domains could be treated as immediate 265 neighbors, adjacent over the tunnel. This would keep the 266 encryption/decryption at the few locations where it is actually 267 needed. On the other hand, there may be performance and scalability 268 advantages to spreading the cost of the cryptography among a larger 269 set of routers, viz., the ingress and egress PEs. 271 The scenario of having VPN traffic go from a trusted domain through 272 an untrusted domain to another trusted domain may not be completely 273 realistic, though, due to the difficulty of supporting the necessary 274 Service Level Agreements through the public Internet. 276 1.5. Non-Issue: General Protection against Misconfiguration 278 In general, the integrity of a BGP/MPLS IP VPN depends upon the SP 279 having properly configured the PE routers. The SP must be careful 280 not to incorrectly create a VPN containing sites that are not 281 supposed to communicate with each other. 283 It is sometimes thought one can obtain protection against 284 misconfigurations by having the PE routers apply cryptographic 285 authentication to the VPN packets. This is not the case. If an 286 ingress PE router has been misconfigured so as to assign a particular 287 site to the wrong VPN, likely as not the PE has been misconfigured to 288 apply that VPN's authenticator to packets to/from that site. 290 Protection against misconfiguration on the part of the SP requires 291 that the authentication procedure be applied before the ingress PE 292 router sees the packets, and after the egress PE router forwards 293 them, and cannot be dealt with by PE-PE IPsec. 295 1.6. Conclusion 297 Taken together, the above set of issues suggest that there are 298 situations in which using PE-PE IPsec as the tunneling protocol for 299 BGP/MPLS IP VPNs does have value. In the next section, we specify 300 the necessary procedures for incorporating PE-PE IPsec as a tunneling 301 option for BGP/MPLS IP VPNs. 303 2. Specification 305 2.1. Technical Approach 307 In short, the technical approach specified here is: 309 1. Use the standard technique [RFC2547bis] of using an MPLS label 310 to represent a VPN route, by prepending an MPLS label stack to 311 the VPN packets. However, the label stack will contain only one 312 label, the VPN route label. 314 2. Use an MPLS-in-IP or MPLS-in-GRE encapsulation to turn the 315 above MPLS packet back into an IP packet. This in effect 316 creates an "IP tunnel" or a "GRE tunnel" between the ingress PE 317 router and the egress PE router. 319 3. Use IPsec Transport Mode to secure the above-mentioned IP 320 tunnels. 322 The net effect is that an MPLS packet gets sent through an IPsec- 323 secured IP or GRE tunnel. 325 The following sub-sections specify this procedure in greater detail. 327 2.2. Selecting the Security Policy 329 One might think that a given SP (or set of cooperating SPs) will 330 decide either that they need to use IPsec for ALL PE-PE tunnels, or 331 else that PE-PE IPsec is not needed at all. But this simple "all or 332 nothing" strategy does not really capture the set of considerations 333 discussed in the Introduction. For example, a very reasonable policy 334 might be to use IPsec only for inter-provider PE-PE tunnels, while 335 using MPLS for intra-provider PE-PE tunnels. Or one might decide to 336 use IPsec only for certain inter-provider tunnels. Or one might 337 decide to use IPsec for certain intra-provider tunnels. 339 The architecture therefore supports more finely grained policies than 340 "all or nothing". However, in order to support the more finely 341 grained policies, an SP must, at its border routers, discard all 342 labeled packets that originate from outside its network. Otherwise 343 it is difficult, if not impossible, to know for sure that a packet 344 which is not protected by IPsec originated from a trusted PE within a 345 trusted area of the network. If it is not feasible or desirable to 346 discard all labeled packets received at the border routers, then both 347 intra-provider and inter-provider tunnels would have to be protected 348 by IPsec. 350 In a BGP/MPLS IP VPN environment, if it is desired to use IPsec 351 between a pair of PEs, one might expect that the ingress PE and the 352 egress PE are each configured to ensure that traffic to the other is 353 sent via IPsec. 355 If the ingress PE is configured to use IPsec but the egress PE is 356 not, then the ingress PE will attempt to set up an SA to the egress 357 PE, and the egress PE will either cooperate or not. In the former 358 case, the SA gets set up, and traffic can be sent from ingress to 359 egress in accord with the policy configured into the ingress. 361 If the egress PE is configured to use IPsec but the egress PE is not, 362 then successful transmission of the traffic cannot occur unless there 363 is some way for the egress to signal its policy to the ingress. 364 [RFC2547bis] already provides an egress-to-ingress signaling 365 capability via BGP, and we specify below how to extend this to the 366 signalling of security policy. 368 2.3. BGP Label, Route, and Policy Distribution 370 Distribution of labeled VPN-IP routes by BGP is done exactly as 371 specified in [RFC2547bis], except that some additional BGP attributes 372 are needed for each distributed VPN-IP route. 374 A given egress PE will be configurable to indicate whether it expects 375 to receive all, some, or none of its VPN traffic through an IPsec- 376 secured IP or GRE tunnel. In general, an ingress PE will not have to 377 know in advance whether any of the egress PEs for its VPNs require 378 their VPN traffic to be sent through an IPsec-secured IP tunnel; this 379 will be signaled from the egress PE. If an egress PE wants to receive 380 traffic for a particular VPN-IP route through an IPsec-secured IP 381 tunnel, it adds a new BGP Extended Community attribute to the route. 382 This attribute will then get distributed along with the route to the 383 ingress PEs. 385 We call this attribute the "IPsec Extended Community". (It is 386 possible that this will actually be encoded as a particular value or 387 set of values of a more general "Tunnel Type Extended Community"; for 388 the purposes of this draft, however, we will continue to refer to it 389 as the "IPsec Extended Community".) 391 It is conceivable that an egress PE in a particular SP's network will 392 only want to receive IPsec-secured IP-tunneled traffic for those VPNs 393 which have sites that are attached to other SPs. In this case, one 394 would want to be able to configure, on a per-VRF basis, whether 395 routes exported from that VRF should have an IPsec Extended Community 396 attribute or not. 398 A more complex situation would arise if it were only desired to 399 receive IPsec-secured IP-tunneled traffic for a particular VPN if 400 that traffic has originated from a site which is attached to a 401 different SP's network. That is, one might want to receive inter- 402 provider traffic through an IPsec-secured IP tunnel, but to receive 403 intra-provider traffic through an unsecured MPLS LSP. As long as an 404 SP has a policy of never accepting MPLS packets from other SPs, this 405 may provide the necessary security while minimizing the amount of 406 cryptography that actually has to be used. 408 One way to do this would be to map each exportable IP address prefix 409 into two different VPN-IP prefixes, using two different RDs (say RD1 410 and RD2). Then two different RTs (say RT1 and RT2) would be used, 411 one of which causes intra-provider distribution, and one of which 412 causes inter-provider distribution. The prefixes with RD1 would be 413 given RT1 as a route target; the prefixes with RD2 would be given RT2 414 as a route target. If RT2 is the route target that causes inter- 415 provider distribution, then only the routes with RT2 would carry the 416 IPsec Extended Community. 418 A simpler approach, perhaps, would be to use only a single set of 419 VPN-IP prefixes, but to have a value of the IPsec Extended Community 420 which encodes an SP identifier, and which means "only use IPsec if 421 the ingress PE is in a different SP network than the one which is 422 identified here". (Again, the assumption is that MPLS packets are not 423 accepted from other SPs.) 425 It is conceivable that an egress PE will want some of its IPsec- 426 secured IP-tunneled VPN traffic to be encrypted, but will want some 427 to be authenticated and not encrypted. It is even conceivable that it 428 will want some traffic to arrive through an IPsec tunnel without 429 being either encrypted or authenticated. The IPsec Extended Community 430 attribute should have a value which specifies which of these are 431 required. 433 It may be desirable to allow the IPsec Extended Community to specify 434 a set of policies, so that the ingress PE can choose from among them. 436 2.4. MPLS-in-IP/GRE Encapsulation by Ingress PE 438 When a PE receives a packet from a CE, it looks up the packet's IP 439 destination address in the VRF corresponding to that CE. This enables 440 it to find a VPN-IP route. The VPN-IP route will have an associated 441 MPLS label and an associated BGP Next Hop. The label is pushed on the 442 packet. Then, if (and only if) the VPN-IP route has an IPsec Extended 443 Community attribute, an IP or GRE encapsulation header is prepended 444 to the packet, creating an MPLS-in-IP or MPLS-in-GRE encapsulated 445 packet. The IP source address field of the encapsulation header will 446 be an address of the ingress PE itself. The IP destination address 447 field of the encapsulation header will contain the value of the 448 associated BGP Next Hop attribute; this will be an IP address of the 449 egress PE. 451 (This description is not meant to specify an implementation strategy; 452 any implementation procedure which produces the same result is 453 acceptable.) 454 N.B.: If the ingress PE and the egress PE are not in the same 455 autonomous system, this requires that there be an EBGP connection 456 between a router in one autonomous system and a router in another. If 457 the two autonomous systems are not adjacent, this will need to be a 458 multi-hop EBGP connection. 460 The effect is to dynamically create an IP tunnel between the ingress 461 and egress PE routers. No apriori configuration of the remote tunnel 462 endpoints is needed. Note that these IP tunnels are NOT IGP-visible 463 links, and routing adjacencies are NOT supported across these tunnel. 464 Note also that the set of remote tunnel endpoints is NOT known in 465 advance, but is learned dynamically via the BGP distribution of VPN- 466 IP routes. 468 These IP tunneled packets will then be associated with an IPsec 469 Security Association (SA), and transported using IPsec transport 470 mode. This is described in more detail in the next sub-section. 472 2.5. MPLS-in-IP vs. MPLS-in-GRE 474 The MPLS-in-IP encapsulation header is shorter than the MPLS-in-GRE 475 encapsulation header, and, in theory at least, the latter offers no 476 advantages to compensate for its use of a longer header. 478 In practice, implementation considerations of various sorts may make 479 the MPLS-in-GRE encapsulation preferable. 481 2.6. PE-PE IPsec (Application of IPsec by Ingress PE) 483 A given ingress PE needs to have an IPsec SA with each PE router that 484 is an egress PE for traffic which the ingress PE receives from a CE. 486 In general, the set of egress PEs for a given ingress PE is not known 487 in advance. This is determined dynamically by the BGP distribution of 488 VPN-IP routes. This suggests that it will be very important to be 489 able to set up IPsec SAs dynamically, and that static keying will not 490 be a viable option. There will need to be a key distribution 491 infrastructure that supports multiple SPs, and IKE will need to be 492 used. 494 A number of different VPNs might need to have traffic carried from a 495 particular ingress PE to a particular egress PE. It is thus natural 496 to ask whether there should be one SA between the pair of PEs, or n 497 SAs between the pair of PEs, where n is the number of VPNs. Clearly, 498 scalability is improved by having only a single SA for each pair of 499 PEs. So the question is whether there is a significant security 500 advantage to having a distinct SA for each VPN. Since the SA is PE- 501 to-PE, NOT CE-to-CE, having a different SA for each VPN does not 502 provide any additional privacy. On the other hand, when multiple 503 VPNs share an SA, the compromise of a key has a greater impact, and 504 an attack on the security of one VPN may become an attack on the 505 security of all the VPNs sharing the SA. Nevertheless, the use of 506 one SA for multiple VPNs seems to be a reasonable tradeoff of 507 additional overhead against additional security. 509 It is conceivable that there might need to be two (or more) SAs 510 between a pair of PEs, e.g., one in which data encryption is used and 511 one in which authentication but not encryption is used. But this is 512 not the same as having a separate SA for each VPN. 514 We assume that the PE router will contain an IPsec module (either a 515 hardware or a software module) which is responsible for doing the key 516 exchange, for setting up the IPsec SAs as needed, and for doing the 517 cryptography. 519 As discussed in section 2.2, the PE router creates an MPLS-in-IP or 520 MPLS-in-GRE encapsulated packet. It does not simply send that packet 521 to its next hop, rather, it delivers the packet to the IPsec module. 522 (As an implementation consideration, it is not really required to 523 deliver an MPLS-in-IP or MPLS-in-GRE encapsulated packet to the IPsec 524 module; all that really needs to be delivered is the MPLS packet and 525 the information, or a pointer thereto, that would be needed to create 526 the IP encapsulation header.) 528 The IPsec module will set up an IPsec SA to the packet's destination 529 address, if one does not already exist. It will then apply the 530 appropriate IPsec procedures, generating a packet with an IP header 531 followed by an IPsec header followed by an MPLS label stack followed 532 by the original data packet. The IPsec module then delivers this 533 packet, as if it were a brand new packet, to the routing module. The 534 routing module forwards it as an IP packet. 536 While the IPsec SA is being set up, packets cannot be delivered 537 through it. Packets may be dropped during this time, though a 538 sensible policy might be to queue the first packet and drop the rest 539 (as is commonly done in ARP implementations while awaiting an ARP 540 resolution). 542 We do assume here that the IPsec module is subsidiary to the PE 543 router, and does not function itself as an independent router in the 544 network. A solution could be designed to support the latter case, but 545 at a considerable increment in complexity. 547 The procedure as specified above requires two routing lookups. Before 548 IPsec processing, The original packet's destination address is looked 549 up in a VRF. After IPsec processing, the IPsec packet's destination 550 address is looked up in the default routing table. It is worth 551 noting that the information obtained from the second lookup is really 552 available at the time of the first lookup. In some routers, it might 553 be advantageous to forward this information, along with the packet, 554 to the IPsec module; possibly this can be used to avoid the need for 555 the second lookup. However, in some routers, it will be impossible to 556 avoid the second lookup. 558 2.7. Application of IPsec by Egress PE 560 We assume that every egress PE is also an ingress PE, and hence has 561 the IPsec module which is mentioned in section 2.2. This module will 562 handle the necessary IKE functions, SA and tunnel maintenance, etc., 563 etc, as well as handling arriving IPsec packets. The IPsec module 564 will apply the necessary IPsec procedures to arriving IPsec packets, 565 and will hence recover the contained MPLS-in-IP or MPLS-in-GRE 566 packets. The IPsec module should then strip off the encapsulating IP 567 header to recover the MPLS packet, and should then deliver the 568 resulting MPLS packet to the routing function for ordinary MPLS 569 switching. (Of course, as an implementation matter, there is probably 570 no need to put the encapsulating IP header on only to then take it 571 off immediately.) 573 There are subtle issues having to do with the proper handling of MPLS 574 packets (rather than IPsec packets) which the PE router receives from 575 P routers or from other PE routers. If the top label on a received 576 MPLS packet corresponds to an IP route in the "default" routing 577 table, "ordinary" MPLS switching is done. But if the top label on a 578 received MPLS packet corresponds to a VPN-IP route, there are a 579 number of different cases to consider: 581 a. The packet has just been removed from an IPsec SA by the IPsec 582 module. In this case, ordinary MPLS switching should be done. 583 (though see below for further qualifications.) 585 b. The packet arrived from a neighboring P or PE router as an MPLS 586 packet, with no IPsec encapsulation. There are a number of 587 sub-cases: 589 i. The packet's top label corresponds to a VPN-IP route 590 which was not exported with the IPsec Extended 591 Community attribute. In this case, ordinary MPLS 592 switching is applied. 594 ii. The packet's top label corresponds to a VPN-IP route 595 which was exported with the value of the IPsec Extended 596 Community attribute which indicates that IPsec is to be 597 used only when the ingress PE is in a different SP 598 network. In this case, we assume that MPLS packets are 599 not being accepted from other networks, so ordinary 600 MPLS switching is applied. 602 iii. The packet's top label corresponds to a VPN-IP route 603 which was exported with an IPsec Extended Community 604 indicating that IPsec is to be used in all cases. In 605 this case the packet should be discarded; packets with 606 this label are supposed to be secured, but this packet 607 was not properly secured. 609 Providing this functionality requires the use of two separate label 610 lookup tables, one of which is used for packets that have been 611 removed from IPsec SAs, and one of which is used for other packets. 612 Labels which are only valid when they are carried within an IPsec 613 packet would only appear in the former lookup table. This does imply 614 that after a packet has been processed by the IPsec module, the 615 contained MPLS packet is not simply returned to the routing lookup 616 path; rather it must carry some indication of which label lookup 617 table must be used to switch that packet. This also presupposes that 618 there will be MPLS VPN code to properly populate the two different 619 lookup tables. Perhaps packets removed from IPsec SAs should appear, 620 to the routing module, to be arriving on a particular virtual 621 interface, rather than on the actual sub-interface over which they 622 really arrived. Then interface-specific label lookup tables could be 623 used. 625 In fact, it may be advantageous to have more than one label lookup 626 table that is used for packets that have been removed from IPsec SAs. 627 Certain VPN-IP routes will be exported to certain SPs, but not to 628 others. Security can thus be improved by having one label lookup 629 table for each such SP. The IPsec module would then have to say, for 630 each packet, which SP it came from. Given a proper certificate 631 authority infrastructure this can be inferred by the IPsec module 632 from the information which the IKE procedure makes available to it. 633 Of course, all this presupposes that the VPN code is capable of 634 properly populating the various lookup tables. 636 It should be noted that when two PEs negotiate (via IKE) an SA, they 637 specify the traffic to be covered, identifying the traffic with the 638 triple . This means 639 that if any MPLS-in-IP/GRE traffic between the two addresses is sent 640 through the SA, then all MPLS-in-IP/GRE traffic between the two 641 addresses is sent through the SA. If it is desired that some such 642 traffic be sent in the clear, then it may be necessary to use a 643 different source and/or destination address for the cleartext traffic 644 than is used for the protected traffic. 646 3. Comparison with Using Part of SPI Field as a Label 648 An alternative methodology that achieves similar results is the one 649 described in [VPN-SPI]. The proposal described above was in fact 650 inspired by that draft, and arose as a proposed improvement to it. 652 In the current proposal, IPsec transport mode is applied to an MPLS- 653 in-IP encapsulation, where the MPLS-in-IP encapsulation carries the 654 BGP-distributed labels of [RFC2547bis]. In [VPN-SPI], there is no 655 MPLS-in-IP encapsulation. Rather: 657 - IPsec tunnel mode is applied to the enduser's packet directly. 659 - A subfield of the IPsec SPI (Security Parameters Index) field is 660 used to provide the function of the BGP-distributed MPLS label. 661 This either requires that BGP distribute a different kind of 662 label (one that can fit into the SPI sub-field), or that an MPLS 663 label be carried within the SPI field. 665 The [VPN-SPI] proposal does have the advantage of making each packet 666 4 bytes shorter, since an entire entry in the MPLS label stack is 667 eliminated (replaced by the SPI sub-field). 669 The current proposal, unlike that in [VPN-SPI], does not in any way 670 alter the use or interpretation of the SPI field, and does not impact 671 the IPsec or IKE protocols and procedures in any way. The current 672 proposal also better preserves the distinction between fields that 673 are meaningful to IPsec and fields that are meaningful to 674 routing/forwarding. Failure to preserve this layering could 675 potentially lead to complications in the future (e.g., if BGP ever 676 needed to distribute a stack of two MPLS labels, or if some 677 enhancement to IPsec ever needed to reclaim the SPI sub-field used to 678 carry the label, etc., etc.). Failure to preserve the layering also 679 complicates the situation in which the transport is sometimes IPsec 680 and sometimes MPLS. Keeping the MPLS VPN functionality in the MPLS 681 layer and out of the IPsec layer certainly seems worthwhile. 683 4. Security Considerations 685 Security considerations are discussed throughout the document. 687 5. IANA Considerations 689 This document defines no encodings, hence there are no IANA 690 considerations. 692 6. Acknowledgments 694 The authors would like to thank Mark Duffy for his comments. 696 7. Authors' Addresses 698 Eric C. Rosen 699 Cisco Systems, Inc. 700 1414 Massachusetts Avenue 701 Boxborough, MA 01719 702 Email: erosen@cisco.com 704 Jeremy De Clercq 705 Alcatel 706 Francis Wellesplein 1 707 2018 Antwerpen, Belgium 708 Phone: +32 3 240 4752 709 Email: jeremy.de_clercq@alcatel.be 711 Olivier Paridaens 712 Alcatel 713 Francis Wellesplein 1 714 2018 Antwerpen, Belgium 715 Phone: +32 3 240 9320 716 Email: olivier.paridaens@alcatel.be 717 Yves T'Joens 718 Alcatel 719 Francis Wellesplein 1 720 2018 Antwerpen, Belgium 721 Phone: +32 3 240 7890 722 Email: yves.tjoens@alcatel.be 724 Chandru Sargor 726 8. Normative References 728 [RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn- 729 rfc2547bis-03.txt, October 2004 731 9. Informative References 733 [MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al., 734 RFC 4023, March 2005 736 [MPLS-in-L2TPv3] "Encapsulation of MPLS over Layer 2 Tunneling 737 Protocol Version 3", draft-ietf-mpls-over-l2tpv3-00.txt, Townsley, 738 Seely, Young, October 2004 740 [VPN-SPI] BGP/IPsec VPN, J. De Clercq, O. Paridaens, Y. T'Joens, C. 741 Sargor, February 2001, expired internet-draft 743 10. Full Copyright Statement 745 Copyright (C) The Internet Society (2005). 747 This document is subject to the rights, licenses and restrictions 748 contained in BCP 78, and except as set forth therein, the authors 749 retain all their rights. 751 This document and the information contained herein are provided on an 752 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 753 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 754 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 755 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 756 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 757 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 759 11. Intellectual Property 761 The IETF takes no position regarding the validity or scope of any 762 Intellectual Property Rights or other rights that might be claimed to 763 pertain to the implementation or use of the technology described in 764 this document or the extent to which any license under such rights 765 might or might not be available; nor does it represent that it has 766 made any independent effort to identify any such rights. Information 767 on the procedures with respect to rights in RFC documents can be 768 found in BCP 78 and BCP 79. 770 Copies of IPR disclosures made to the IETF Secretariat and any 771 assurances of licenses to be made available, or the result of an 772 attempt made to obtain a general license or permission for the use of 773 such proprietary rights by implementers or users of this 774 specification can be obtained from the IETF on-line IPR repository at 775 http://www.ietf.org/ipr. 777 The IETF invites any interested party to bring to its attention any 778 copyrights, patents or patent applications, or other proprietary 779 rights that may cover technology that may be required to implement 780 this standard. Please address the information to the IETF at ietf- 781 ipr@ietf.org.