idnits 2.17.1 draft-ietf-l3vpn-ipsec-2547-03.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.a on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 724. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** 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 385 has weird spacing: '...ht want to re...' == Line 386 has weird spacing: '...traffic throu...' == Line 395 has weird spacing: '... one of which...' -- 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 (September 2004) is 7162 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-02 Summary: 8 errors (**), 0 flaws (~~), 6 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: March 2005 5 Jeremy De Clercq 6 Olivier Paridaens 7 Yves T'Joens 8 Alcatel 10 Chandru Sargor 11 Cosine Communications 13 September 2004 15 Use of PE-PE IPsec in RFC2547 VPNs 17 draft-ietf-l3vpn-ipsec-2547-03.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets 44 traveling from one Provider Edge (PE) router to another generally 45 carry two MPLS labels, an inner label that corresponds to a VPN- 46 specific route, and an outer label that corresponds to a Label 47 Switched Path (LSP) between the PE routers. In some circumstances, 48 it is desirable to support the same type of VPN architecture, but 49 using an IPsec Security Association in place of that LSP. The outer 50 MPLS label would thus be replaced by an IP/IPsec header. This 51 enables the VPN packets to be carried securely over non-MPLS 52 networks, using standard IPsec authentication and/or encryption 53 functions to protect them. This draft specifies the procedures which 54 are specific to support of BGP/MPLS IP VPNs using the IPsec 55 encapsulation. 57 Table of Contents 59 1 Introduction ........................................... 3 60 1.1 Issue: MPLS Infrastructure Required .................... 4 61 1.2 Issue: Protection Against Misbehavior by Transit Nodes . 5 62 1.3 Issue: Limitations on Multi-Provider Misconfigurations . 5 63 1.4 Issue: Privacy for VPN Data ............................ 6 64 1.5 Non-Issue: General Protection against Misconfiguration . 7 65 1.6 Conclusion ............................................. 7 66 2 Specification .......................................... 7 67 2.1 Technical Approach ..................................... 7 68 2.2 Selecting the Security Policy .......................... 8 69 2.3 BGP Label, Route, and Policy Distribution .............. 9 70 2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10 71 2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11 72 2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11 73 2.7 Application of IPsec by Egress PE ...................... 13 74 3 Comparison with Using Part of SPI Field as a Label ..... 14 75 4 Authors' Addresses ..................................... 15 76 5 Normative References ................................... 16 77 6 Informative References ................................. 16 78 7 Intellectual Property Statement ........................ 17 79 8 Full Copyright Statement ............................... 17 81 1. Introduction 83 The present document uses terminology from [RFC2547bis], and 84 presupposes familiarity with that document and its terminology. 86 In BGP/MPLS IP VPNs, when an ingress PE router receives a packet from 87 a CE router, it looks up the packet's destination IP address in a 88 VRF. As a result of this lookup, it learns the output interface on 89 which the packet must be sent, and it also learns the set of headers 90 which must be prepended to the packet before it is sent on that 91 interface. In "conventional" BGP/MPLS IP VPNs, this set of headers 92 consists of a data link layer header, possibly followed by an MPLS 93 label stack. If the packet is going out an interface to a CE router 94 (i.e. the ingress PE is the same as the egress PE), no MPLS label 95 stack is needed. If the packet's egress PE router is directly 96 adjacent to the ingress PE, the MPLS label stack will have one or 97 more entries. In other cases, the MPLS label stack has two or more 98 entries. 100 The bottom label on the MPLS label stack is always a label which will 101 not be seen until the packet reaches its point of egress from the 102 network. This label represents a particular route within the packet's 103 VPN, and we will call it the "VPN route label". Directly above the 104 VPN route label is a label which represents a route across the 105 backbone to the egress PE router. We will call this label the 106 "backbone route label". 108 The backbone route label may or may not be the packet's top label; 109 additional entries may also be pushed on the label stack, if 110 additional MPLS services (e.g., traffic engineering) are used to 111 carry traffic to the egress PE. These additional labels may be 112 pushed on by the ingress PE, or by a P router somewhere along the 113 path. The VPN route label is always the packet's bottom label, 114 however. 116 This document specifies procedures for replacing the backbone route 117 label with an IPsec encapsulation. In effect, this creates an MPLS- 118 in-IPsec encapsulation, in which the VPN route label is carried 119 across the network within an IPsec encapsulation. By "within an 120 IPsec encapsulation", we mean "in a packet containing an IP header 121 and an IPsec header". This IPsec encapsulation corresponds to an 122 IPsec Security Association (SA) whose two endpoints are the ingress 123 PE router and the egress PE router. The payload of the IPsec 124 encapsulation is an authenticated and/or encrypted MPLS packet, whose 125 label stack contains a single entry, viz., the VPN route label. The 126 payload of this MPLS packet is the user data packet being sent within 127 the VPN. 129 The IP/IPsec encapsulation will be used even if the ingress PE and 130 the egress PE are directly adjacent, i.e., even in the case where a 131 backbone route label would not be used. However, no IP/IPsec 132 encapsulation is applied if the ingress PE is the same device as the 133 egress PE. 135 If additional MPLS services, such as traffic engineering, are used in 136 the backbone network, an MPLS label stack will appear above the IP 137 header. This is orthogonal to any issues discussed in the present 138 document. This results in an MPLS packet containing an IP packet 139 containing an IPsec packet containing an MPLS packet; the latter MPLS 140 packet has a single label, the VPN route label. 142 This document is inspired by [VPN-SPI], and originated as an attempt 143 to improve upon it. 145 The remainder of section 1 outlines a number of issues which can be 146 addressed by the use of IPsec in this manner. 148 1.1. Issue: MPLS Infrastructure Required 150 "Conventional" BGP/MPLS IP VPNs require that there be an MPLS Label 151 Switched Path (LSP) between a packet's ingress PE router and its 152 egress PE router. This means that an RFC2547 VPN cannot be 153 implemented if there is a part of the path between the ingress and 154 egress PE routers which does not support MPLS. 156 In order to enable BGP/MPLS IP VPNs to be deployed even when there 157 are non-MPLS routers along the path between the ingress and egress PE 158 routers, it is desirable to have an alternative which allows the 159 backbone route label to be replaced with an IP header. This 160 encapsulating IP header would encapsulate an MPLS packet containing 161 only the VPN route label. The encapsulation header would have the 162 address of the egress PE in its destination IP address field; this 163 would cause the packet to be delivered to the egress PE. 165 It is possible to replace the backbone route label with an IP header, 166 possibly followed by a GRE header [MPLS-in-IP/GRE]. However, it then 167 becomes quite difficult, in general, to protect the VPNs against 168 spoofed packets. A Service Provider (SP) can protect against spoofed 169 MPLS packets by the simple expedient of not accepting MPLS packets 170 from outside its own boundaries (or more generally by keeping track 171 of which labels are validly received over which interfaces, and 172 discarding packets which arrive with labels that are not valid for 173 their incoming interfaces). Protection against spoofed IP packets 174 requires having all the boundary routers perform filtering; either 175 (a) filtering out packets from "outside" which are addressed to PE 176 routers, or (b) filtering out packets from "outside" which have 177 source addresses that belong "inside", and having PE routers refuse 178 to accept packets addressed to them but with "outside" source 179 addresses. The maintenance of these filter lists can be management- 180 intensive, and the their use at all border routers can affect the 181 performance seen by all traffic entering the SP's network. Further, 182 these filtering techniques may be difficult to apply in the case of 183 multi-provider VPNs, because in multi-provider VPNs, packets from 184 outside an SP's network can legitimately be addressed to its PE 185 routers. 187 If, on the other hand, the backbone route label is replaced by an 188 IPsec encapsulation, protection against spoofed packets does not rely 189 on filtering at the border. The cryptographic authentication 190 features of IPsec enable an egress PE to detect and discard packets 191 for a particular VPN that were not generated by a valid ingress PE 192 for that VPN. Thus spoofing protection is managed entirely at the 193 ingress and egress PE routers, transparently to the border routers. 194 IPsec does have its own management and performance implications, of 195 course. 197 1.2. Issue: Protection Against Misbehavior by Transit Nodes 199 Cryptographic authentication applied by the ingress PE on a PE-to-PE 200 basis can protect against the misrouting or modification (intentional 201 or accidental) of packets by the transit nodes. Packets which get 202 forwarded to the "wrong" egress PE will not pass authentication, nor 203 will packets which have been modified. As the VPN route label is 204 part of the IPsec packet payload, the egress PE will know that the 205 VPN route label was placed in the packet by a valid ingress PE. 207 1.3. Issue: Limitations on Multi-Provider Misconfigurations 209 Sometimes a VPN will have some sites which connect to one SP (SP1), 210 and some other sites which connect to another SP (SP2). 212 Consider a case in which VPN V1 has sites attaching to SP1 and SP2, 213 but VPN V2 has all of its sites attaching only to SP2. 215 SP2 would like to ensure that nothing done by SP1 can cause V1 to get 216 illegitimately cross-connected to V2. Since V2 has no sites in SP1, 217 it should be immune to the effects of any misconfigurations within 218 SP1. 220 This assurance can be achieved if the egress PE (in SP2) can 221 determine, for each VPN packet, whether that packet came from SP1, 222 and if so, whether it carries an MPLS label which corresponds to a 223 VPN route that was actually distributed to SP1. (That is, packets 224 originating from SP1 destined for VPNs in SP2 would be checked if 225 they are for VPNs which really have sites in SP1.) SP2's egress PEs 226 could be configured with the knowledge of which VPNs have sites 227 attached to SP1. Cryptographic authentication could then be used to 228 determine that a particular packet did indeed originate in SP1. 230 In general, if an egress PE knows which labels may be validly applied 231 by which ingress PEs, IPsec authentication can be used to ensure that 232 a given ingress PE has not applied a label that it has no right to 233 use. However, the scalability of the VPN scheme would be severely 234 compromised if an egress PE had to distribute a different set of 235 labels to each ingress PE. Therefore we will not pursue this general 236 case, but will only pursue label authentication in the inter-provider 237 case. 239 1.4. Issue: Privacy for VPN Data 241 IPsec Security Associations that associate ingress PE routes with 242 egress PE routers do not ensure privacy for VPN data. The data is 243 exposed on the PE-CE access links, and is exposed in the PE routers 244 themselves. Complete privacy requires that the encryption/decryption 245 be performed within the enterprise, not by the SP. So the use of 246 PE-PE IPsec encryption within the network of a single SP will perhaps 247 be of less import than the use of IPsec authentication. On the other 248 hand, if an SP is trusted to properly secure its routers, but the 249 transmission media used by the SP are not trusted, then PE-PE 250 encryption does provide a valuable measure of privacy. 252 There may be a need for encryption if a VPN has sites attached to 253 different trusted SPs, but some of the transit traffic needs to go 254 through the "public Internet". In this case, it may be necessary to 255 encrypt the VPN data traffic as it crosses the public Internet. 256 However, while PE-PE encryption is the one way to handle this, it is 257 not the only way. An alternative would be to use an encrypted tunnel 258 to connecting a border router of one trusted SP to a border router of 259 another. Then the two trusted domains could be treated as immediate 260 neighbors, adjacent over the tunnel. This would keep the 261 encryption/decryption at the few locations where it is actually 262 needed. On the other hand, there may be performance and scalability 263 advantages to spreading the cost of the cryptography among a larger 264 set of routers, viz., the ingress and egress PEs. 266 The scenario of having VPN traffic go from a trusted domain through 267 an untrusted domain to another trusted domain may not be completely 268 realistic, though, due to the difficulty of supporting the necessary 269 Service Level Agreements through the public Internet. 271 1.5. Non-Issue: General Protection against Misconfiguration 273 In general, the integrity of an RFC2547 VPN depends upon the SP 274 having properly configured the PE routers. There is no way of 275 preventing an SP from creating a bogus VPN that contains sites which 276 aren't supposed to communicate with each other. It is the SP's 277 responsibility to get this right. 279 It is sometimes thought one can obtain protection against 280 misconfigurations by having the PE routers apply cryptographic 281 authentication to the VPN packets. This is not the case. If an 282 ingress PE router has been misconfigured so as to assign a particular 283 site to the wrong VPN, likely as not the PE has been misconfigured to 284 apply that VPN's authenticator to packets to/from that site. 286 Protection against misconfiguration on the part of the SP requires 287 that the authentication procedure be applied before the ingress PE 288 router sees the packets, and after the egress PE router forwards 289 them, and cannot be dealt with by PE-PE IPsec. 291 1.6. Conclusion 293 Taken together, the above set of issues suggest that there are 294 situations in which using PE-PE IPsec as the tunneling protocol for 295 BGP/MPLS IP VPNs does have value. In the next section, we specify 296 the necessary procedures for incorporating PE-PE IPsec as a tunneling 297 option for BGP/MPLS IP VPNs. 299 2. Specification 301 2.1. Technical Approach 303 In short, the technical approach specified here is: 305 1. Use the standard technique [RFC2547bis] of using an MPLS label 306 to represent a VPN route, by prepending an MPLS label stack to 307 the VPN packets. However, the label stack will contain only one 308 label, the VPN route label. 310 2. Use an MPLS-in-IP or MPLS-in-GRE encapsulation to turn the 311 above MPLS packet back into an IP packet. This in effect 312 creates an "IP tunnel" or a "GRE tunnel" between the ingress PE 313 router and the egress PE router. 315 3. Use IPsec Transport Mode to secure the above-mentioned IP 316 tunnels. 318 The net effect is that an MPLS packet gets sent through an IPsec- 319 secured IP or GRE tunnel. 321 The following sub-sections specify this procedure in greater detail. 323 2.2. Selecting the Security Policy 325 One might think that a given SP (or set of cooperating SPs) will 326 decide either that they need to use IPsec for ALL PE-PE tunnels, or 327 else that PE-PE IPsec is not needed at all. But this simple "all or 328 nothing" strategy does not really capture the set of considerations 329 discussed in the Introduction. For example, a very reasonable policy 330 might be to use IPsec only for inter-provider PE-PE tunnels, while 331 using MPLS for intra-provider PE-PE tunnels. Or one might decide to 332 use IPsec only for certain inter-provider tunnels. Or one might 333 decide to use IPsec for certain intra-provider tunnels. 335 In an RFC2547 VPN environment, it makes most sense to place control 336 of the policies with the egress PE router. It is the egress PE which 337 needs to know that it wants to process certain packets ONLY if they 338 come through encrypted tunnels, and that it wants to discard those 339 same packets if they don't come through encrypted tunnels. Thus one 340 needs to be able to configure a policy into the egress PE, and have 341 it signal that policy to the ingress PE. RFC2547 already provides an 342 egress-to-ingress signaling capability via BGP, and we specify below 343 how to extend this to the signalling of security policy. 345 Of course, there is nothing to stop an ingress PE router from being 346 configured to use IPsec even if the egress PE has not signalled its 347 desire for IPsec. This should work, as long as the necessary IPsec 348 infrastructure is in place. (However, in this sort of application 349 the ingress PE and the egress PE are NOT really independent entities 350 which might conceivably have different security policies.) 352 2.3. BGP Label, Route, and Policy Distribution 354 Distribution of labeled VPN-IP routes by BGP is done exactly as 355 specified in [RFC2547bis], except that some additional BGP attributes 356 are needed for each distributed VPN-IP route. 358 A given egress PE will be configurable to indicate whether it expects 359 to receive all, some, or none of its VPN traffic through an IPsec- 360 secured IP or GRE tunnel. In general, an ingress PE will not have to 361 know in advance whether any of the egress PEs for its VPNs require 362 their VPN traffic to be sent through an IPsec-secured IP tunnel; this 363 will be signaled from the egress PE. If an egress PE wants to receive 364 traffic for a particular VPN-IP route through an IPsec-secured IP 365 tunnel, it adds a new BGP Extended Community attribute to the route. 366 This attribute will then get distributed along with the route to the 367 ingress PEs. 369 We call this attribute the "IPsec Extended Community". (It is 370 possible that this will actually be encoded as a particular value or 371 set of values of a more general "Tunnel Type Extended Community"; for 372 the purposes of this draft, however, we will continue to refer to it 373 as the "IPsec Extended Community".) 375 It is conceivable that an egress PE in a particular SP's network will 376 only want to receive IPsec-secured IP-tunneled traffic for those VPNs 377 which have sites that are attached to other SPs. In this case, one 378 would want to be able to configure, on a per-VRF basis, whether 379 routes exported from that VRF should have an IPsec Extended Community 380 attribute or not. 382 A more complex situation would arise if it were only desired to 383 receive IPsec-secured IP-tunneled traffic for a particular VPN if 384 that traffic has originated from a site which is attached to a 385 different SP's network. That is, one might want to receive inter- 386 provider traffic through an IPsec-secured IP tunnel, but to receive 387 intra-provider traffic through an unsecured MPLS LSP. As long as an 388 SP has a policy of never accepting MPLS packets from other SPs, this 389 may provide the necessary security while minimizing the amount of 390 cryptography that actually has to be used. 392 One way to do this would be to map each exportable IP address prefix 393 into two different VPN-IP prefixes, using two different RDs (say RD1 394 and RD2). Then two different RTs (say RT1 and RT2) would be used, 395 one of which causes intra-provider distribution, and one of which 396 causes inter-provider distribution. The prefixes with RD1 would be 397 given RT1 as a route target; the prefixes with RD2 would be given RT2 398 as a route target. If RT2 is the route target that causes inter- 399 provider distribution, then only the routes with RT2 would carry the 400 IPsec Extended Community. 402 A simpler approach, perhaps, would be to use only a single set of 403 VPN-IP prefixes, but to have a value of the IPsec Extended Community 404 which encodes an SP identifier, and which means "only use IPsec if 405 the ingress PE is in a different SP network than the one which is 406 identified here". (Again, the assumption is that MPLS packets are not 407 accepted from other SPs.) 409 It is conceivable that an egress PE will want some of its IPsec- 410 secured IP-tunneled VPN traffic to be encrypted, but will want some 411 to be authenticated and not encrypted. It is even conceivable that it 412 will want some traffic to arrive through an IPsec tunnel without 413 being either encrypted or authenticated. The IPsec Extended Community 414 attribute should have a value which specifies which of these are 415 required. 417 It may be desirable to allow the IPsec Extended Community to specify 418 a set of policies, so that the ingress PE can choose from among them. 420 2.4. MPLS-in-IP/GRE Encapsulation by Ingress PE 422 When a PE receives a packet from a CE, it looks up the packet's IP 423 destination address in the VRF corresponding to that CE. This enables 424 it to find a VPN-IP route. The VPN-IP route will have an associated 425 MPLS label and an associated BGP Next Hop. The label is pushed on the 426 packet. Then, if (and only if) the VPN-IP route has an IPsec Extended 427 Community attribute, an IP or GRE encapsulation header is prepended 428 to the packet, creating an MPLS-in-IP or MPLS-in-GRE encapsulated 429 packet. The IP source address field of the encapsulation header will 430 be an address of the ingress PE itself. The IP destination address 431 field of the encapsulation header will contain the value of the 432 associated BGP Next Hop attribute; this will be an IP address of the 433 egress PE. 435 (This description is not meant to specify an implementation strategy; 436 any implementation procedure which produces the same result is 437 acceptable.) 439 N.B.: If the ingress PE and the egress PE are not in the same 440 autonomous system, this requires that there be an EBGP connection 441 between a router in one autonomous system and a router in another. If 442 the two autonomous systems are not adjacent, this will need to be a 443 multi-hop EBGP connection. 445 The effect is to dynamically create an IP tunnel between the ingress 446 and egress PE routers. No apriori configuration of the remote tunnel 447 endpoints is needed. Note that these IP tunnels are NOT IGP-visible 448 links, and routing adjacencies are NOT supported across these tunnel. 449 Note also that the set of remote tunnel endpoints is NOT known in 450 advance, but is learned dynamically via the BGP distribution of VPN- 451 IP routes. 453 These IP tunneled packets will then be associated with an IPsec 454 Security Association (SA), and transported using IPsec transport 455 mode. This is described in more detail in the next sub-section. 457 2.5. MPLS-in-IP vs. MPLS-in-GRE 459 The MPLS-in-IP encapsulation header is shorter than the MPLS-in-GRE 460 encapsulation header, and, in theory at least, the latter offers no 461 advantages to compensate for its use of a longer header. 463 In practice, implementation considerations of various sorts may make 464 the MPLS-in-GRE encapsulation preferable. 466 2.6. PE-PE IPsec (Application of IPsec by Ingress PE) 468 A given ingress PE needs to have an IPsec SA with each PE router that 469 is an egress PE for traffic which the ingress PE receives from a CE. 471 In general, the set of egress PEs for a given ingress PE is not known 472 in advance. This is determined dynamically by the BGP distribution of 473 VPN-IP routes. This suggests that it will be very important to be 474 able to set up IPsec SAs dynamically, and that static keying will not 475 be a viable option. There will need to be a key distribution 476 infrastructure that supports multiple SPs, and IKE will need to be 477 used. 479 A number of different VPNs might need to have traffic carried from a 480 particular ingress PE to a particular egress PE. It is thus natural 481 to ask whether there should be one SA between the pair of PEs, or n 482 SAs between the pair of PEs, where n is the number of VPNs. Clearly, 483 scalability is improved by having only a single SA for each pair of 484 PEs. So the question is whether there is a significant security 485 advantage to having a distinct SA for each VPN. There does not appear 486 to be any such advantage. Since the SA is PE-to-PE, NOT CE-to-CE, 487 having a different SA for each VPN does not provide any additional 488 security. 490 It is conceivable that there might need to be two (or more) SAs 491 between a pair of PEs, e.g., one in which data encryption is used and 492 one in which authentication but not encryption is used. But this is 493 not the same as having a separate SA for each VPN. 495 We assume that the PE router will contain an IPsec module (either a 496 hardware or a software module) which is responsible for doing the key 497 exchange, for setting up the IPsec SAs as needed, and for doing the 498 cryptography. 500 As discussed in section 2.2, the PE router creates an MPLS-in-IP or 501 MPLS-in-GRE encapsulated packet. It does not simply send that packet 502 to its next hop, rather, it delivers the packet, along with the 503 corresponding IPsec Extended Community value, to the IPsec module. 504 (As an implementation consideration, it is not really required to 505 deliver an MPLS-in-IP or MPLS-in-GRE encapsulated packet to the IPsec 506 module; all that really needs to be delivered is the MPLS packet and 507 the information, or a pointer thereto, that would be needed to create 508 the IP encapsulation header.) 510 The IPsec module will set up an IPsec SA to the packet's destination 511 address, if one does not already exist. It will then apply the 512 appropriate IPsec procedures, generating a packet with an IP header 513 followed by an IPsec header followed by an MPLS label stack followed 514 by the original data packet. The IPsec module then delivers this 515 packet, as if it were a brand new packet, to the routing module. The 516 routing module forwards it as an IP packet. 518 While the IPsec SA is being set up, packets cannot be delivered 519 through it. Packets may be dropped during this time, though a 520 sensible policy might be to queue the first packet and drop the rest 521 (as is commonly done in ARP implementations while awaiting an ARP 522 resolution). 524 We do assume here that the IPsec module is subsidiary to the PE 525 router, and does not function itself as an independent router in the 526 network. A solution could be designed to support the latter case, but 527 at a considerable increment in complexity. 529 The procedure as specified above requires two routing lookups. Before 530 IPsec processing, The original packet's destination address is looked 531 up in a VRF. After IPsec processing, the IPsec packet's destination 532 address is looked up in the default routing table. It is worth 533 noting that the information obtained from the second lookup is really 534 available at the time of the first lookup. In some routers, it might 535 be advantageous to forward this information, along with the packet, 536 to the IPsec module; possibly this can be used to avoid the need for 537 the second lookup. However, in some routers, it will be impossible to 538 avoid the second lookup. 540 2.7. Application of IPsec by Egress PE 542 We assume that every egress PE is also an ingress PE, and hence has 543 the IPsec module which is mentioned in section 2.2. This module will 544 handle the necessary IKE functions, SA and tunnel maintenance, etc., 545 etc, as well as handling arriving IPsec packets. The IPsec module 546 will apply the necessary IPsec procedures to arriving IPsec packets, 547 and will hence recover the contained MPLS-in-IP or MPLS-in-GRE 548 packets. The IPsec module should then strip off the encapsulating IP 549 header to recover the MPLS packet, and should then deliver the 550 resulting MPLS packet to the routing function for ordinary MPLS 551 switching. (Of course, as an implementation matter, there is probably 552 no need to put the encapsulating IP header on only to then take it 553 off immediately.) 555 There are subtle issues having to do with the proper handling of MPLS 556 packets (rather than IPsec packets) which the PE router receives from 557 P routers or from other PE routers. If the top label on a received 558 MPLS packet corresponds to an IP route in the "default" routing 559 table, "ordinary" MPLS switching is done. But if the top label on a 560 received MPLS packet corresponds to a VPN-IP route, there are a 561 number of different cases to consider: 563 a. The packet has just been removed from an IPsec SA by the IPsec 564 module. In this case, ordinary MPLS switching should be done. 565 (though see below for further qualifications.) 567 b. The packet arrived from a neighboring P or PE router as an MPLS 568 packet, with no IPsec encapsulation. There are a number of 569 sub-cases: 571 i. The packet's top label corresponds to a VPN-IP route 572 which was not exported with the IPsec Extended 573 Community attribute. In this case, ordinary MPLS 574 switching is applied. 576 ii. The packet's top label corresponds to a VPN-IP route 577 which was exported with the value of the IPsec Extended 578 Community attribute which indicates that IPsec is to be 579 used only when the ingress PE is in a different SP 580 network. In this case, we assume that MPLS packets are 581 not being accepted from other networks, so ordinary 582 MPLS switching is applied. 584 iii. The packet's top label corresponds to a VPN-IP route 585 which was exported with an IPsec Extended Community, 586 but case ii does not apply. In this case the packet 587 should be discarded; packets with this label are 588 supposed to be secured, but this packet was not 589 properly secured. 591 Providing this functionality requires the use of two separate label 592 lookup tables, one of which is used for packets that have been 593 removed from IPsec SAs, and one of which is used for other packets. 594 Labels which are only valid when they are carried within an IPsec 595 packet would only appear in the former lookup table. This does imply 596 that after a packet has been processed by the IPsec module, the 597 contained MPLS packet is not simply returned to the routing lookup 598 path; rather it must carry some indication of which label lookup 599 table must be used to switch that packet. This also presupposes that 600 there will be MPLS VPN code to properly populate the two different 601 lookup tables. Perhaps packets removed from IPsec SAs should appear, 602 to the routing module, to be arriving on a particular virtual 603 interface, rather than on the actual sub-interface over which they 604 really arrived. Then interface-specific label lookup tables could be 605 used. 607 In fact, it may be advantageous to have more than one label lookup 608 table that is used for packets that have been removed from IPsec SAs. 609 Certain VPN-IP routes will be exported to certain SPs, but not to 610 others. Security can thus be improved by having one label lookup 611 table for each such SP. The IPsec module would then have to say, for 612 each packet, which SP it came from. Given a proper certificate 613 authority infrastructure this can be inferred by the IPsec module 614 from the information which the IKE procedure makes available to it. 615 Of course, all this presupposes that the VPN code is capable of 616 properly populating the various lookup tables. 618 3. Comparison with Using Part of SPI Field as a Label 620 An alternative methodology that achieves similar results is the one 621 described in [VPN-SPI]. The proposal described above was in fact 622 inspired by that draft, and arose as a proposed improvement to it. 624 In the current proposal, IPsec transport mode is applied to an MPLS- 625 in-IP encapsulation, where the MPLS-in-IP encapsulation carries the 626 BGP-distributed labels of RFC 2547. In [VPN-SPI], there is no MPLS- 627 in-IP encapsulation. Rather: 629 - IPsec tunnel mode is applied to the enduser's packet directly. 631 - A subfield of the IPsec SPI field is used to provide the function 632 of the BGP-distributed MPLS label. This either requires that BGP 633 distribute a different kind of label (one that can fit into the 634 SPI sub-field), or that an MPLS label be carried within the SPI 635 field. 637 The [VPN-SPI] proposal does have the advantage of making each packet 638 4 bytes shorter, since an entire entry in the MPLS label stack is 639 eliminated (replaced by the SPI sub-field). 641 The current proposal, unlike that in [VPN-SPI], does not in any way 642 alter the use or interpretation of the SPI field, and does not impact 643 the IPsec or IKE protocols and procedures in any way. The current 644 proposal also better preserves the distinction between fields that 645 are meaningful to IPsec and fields that are meaningful to 646 routing/forwarding. Failure to preserve this layering could 647 potentially lead to complications in the future (e.g., if BGP ever 648 needed to distribute a stack of two MPLS labels, or if some 649 enhancement to IPsec ever needed to reclaim the SPI sub-field used to 650 carry the label, etc., etc.). Failure to preserve the layering also 651 complicates the situation in which the transport is sometimes IPsec 652 and sometimes MPLS. Keeping the MPLS VPN functionality in the MPLS 653 layer and out of the IPsec layer certainly seems worthwhile. 655 4. Authors' Addresses 657 Eric C. Rosen 658 Cisco Systems, Inc. 659 1414 Massachusetts Avenue 660 Boxborough, MA 01719 661 Email: erosen@cisco.com 663 Jeremy De Clercq 664 Alcatel 665 Francis Wellesplein 1 666 2018 Antwerpen, Belgium 667 Phone: +32 3 240 4752 668 Email: jeremy.de_clercq@alcatel.be 669 Olivier Paridaens 670 Alcatel 671 Francis Wellesplein 1 672 2018 Antwerpen, Belgium 673 Phone: +32 3 240 9320 674 Email: olivier.paridaens@alcatel.be 676 Yves T'Joens 677 Alcatel 678 Francis Wellesplein 1 679 2018 Antwerpen, Belgium 680 Phone: +32 3 240 7890 681 Email: yves.tjoens@alcatel.be 683 Chandru Sargor 684 CoSine Communications 685 1200 Bridge Parkway 686 Redwood City, CA 94065 687 Email: csargor@cosinecom.com 689 5. Normative References 691 [RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn- 692 rfc2547bis-02.txt, September 2004 694 6. Informative References 696 [MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al., 697 draft-ietf-mpls-in-ip-or-gre-08.txt, June 2004 699 [VPN-SPI] BGP/IPsec VPN, De Clercq et. al., draft-declercq-bgp- 700 ipsec-vpn-01.txt, February 2001 702 7. Intellectual Property Statement 704 The IETF takes no position regarding the validity or scope of any 705 Intellectual Property Rights or other rights that might be claimed to 706 pertain to the implementation or use of the technology described in 707 this document or the extent to which any license under such rights 708 might or might not be available; nor does it represent that it has 709 made any independent effort to identify any such rights. Information 710 on the procedures with respect to rights in RFC documents can be 711 found in BCP 78 and BCP 79. 713 Copies of IPR disclosures made to the IETF Secretariat and any 714 assurances of licenses to be made available, or the result of an 715 attempt made to obtain a general license or permission for the use of 716 such proprietary rights by implementers or users of this 717 specification can be obtained from the IETF on-line IPR repository at 718 http://www.ietf.org/ipr. 720 The IETF invites any interested party to bring to its attention any 721 copyrights, patents or patent applications, or other proprietary 722 rights that may cover technology that may be required to implement 723 this standard. Please address the information to the IETF at ietf- 724 ipr@ietf.org. 726 8. Full Copyright Statement 728 Copyright (C) The Internet Society (2004). This document is subject 729 to the rights, licenses and restrictions contained in BCP 78 and 730 except as set forth therein, the authors retain all their rights. 732 This document and the information contained herein are provided on an 733 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 734 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 735 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 736 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 737 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 738 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.