idnits 2.17.1 draft-ietf-l3vpn-ipsec-2547-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2547bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 378 has weird spacing: '...ht want to re...' == Line 379 has weird spacing: '...traffic throu...' == Line 388 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 (August 2003) is 7553 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-00 -- Possible downref: Normative reference to a draft: ref. 'VPN-SPI' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 2004 5 Jeremy De Clercq 6 Olivier Paridaens 7 Yves T'Joens 8 Alcatel 10 Chandru Sargor 11 Cosine Communications 13 August 2003 15 Use of PE-PE IPsec in RFC2547 VPNs 17 draft-ietf-l3vpn-ipsec-2547-01.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 [RFC2547bis] specifies a particular way of implementing Layer 3 VPNs. 42 It presupposes the use of MPLS Label Switched Paths (LSPs) for 43 carrying VPN traffic between Provider Edge (PE) routers, and 44 specifies the use of two labels in the MPLS label stack. In some 45 circumstances, it is desirable to support the same type of VPN 46 architecture, using an IPsec Security Association in place of an MPLS 47 LSP, thus replacing the topmost of the two MPLS labels with an 48 IP/IPsec header. This enables the VPN packets to be carried securely 49 over non-MPLS networks, using standard IPsec authentication and/or 50 encryption functions to protect them. This draft specifies the 51 procedures which are specific to support of RFC2547bis VPNs using the 52 IPsec encapsulation. 54 Table of Contents 56 1 Introduction ........................................... 2 57 1.1 Issue: MPLS Infrastructure Required .................... 4 58 1.2 Issue: Protection Against Misbehavior by Transit Nodes . 5 59 1.3 Issue: Limitations on Multi-Provider Misconfigurations . 5 60 1.4 Issue: Privacy for VPN Data ............................ 6 61 1.5 Non-Issue: General Protection against Misconfiguration . 6 62 1.6 Conclusion ............................................. 7 63 2 Specification .......................................... 7 64 2.1 Technical Approach ..................................... 7 65 2.2 Selecting the Security Policy .......................... 8 66 2.3 BGP Label, Route, and Policy Distribution .............. 8 67 2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10 68 2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11 69 2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11 70 2.7 Application of IPsec by Egress PE ...................... 12 71 3 Comparison with Using Part of SPI Field as a Label ..... 14 72 4 Authors' Addresses ..................................... 15 73 5 References ............................................. 16 75 1. Introduction 77 The present document uses terminology from [RFC2547bis], and 78 presupposes familiarity with that document and its terminology. 80 In RFC2547 VPNs, when an ingress PE router receives a packet from a 81 CE router, it looks up the packet's destination IP address in a VRF. 82 As a result of this lookup, it learns the output interface on which 83 the packet must be sent, and it also learns the set of headers which 84 must be prepended to the packet before it is sent on that interface. 85 In "conventional" RFC2547 VPNs, this set of headers consists of a 86 data link layer header, possibly followed by an MPLS label stack. If 87 the packet is going out an interface to a CE router (i.e. the ingress 88 PE is the same as the egress PE), no MPLS label stack is needed. If 89 the packet's egress PE router is directly adjacent to the ingress PE, 90 the MPLS label stack will have one or more entries. In other cases, 91 the MPLS label stack has two or more entries. 93 The bottom label on the MPLS label stack is always a label which will 94 not be seen until the packet reaches its point of egress from the 95 network. This label represents a particular route within the packet's 96 VPN, and we will call it the "VPN route label". Directly above the 97 VPN route label is a label which represents a route across the 98 backbone to the egress PE router. We will call this label the 99 "backbone route label". 101 The backbone route label may or may not be the packet's top label; 102 additional entries may also be pushed on the label stack, if 103 additional MPLS services (e.g., traffic engineering) are used to 104 carry traffic to the egress PE. These additional labels may be 105 pushed on by the ingress PE, or by a P router somewhere along the 106 path. The VPN route label is always the packet's bottom label, 107 however. 109 This document specifies procedures for replacing the backbone route 110 label with an IPsec encapsulation. In effect, this creates an MPLS- 111 in-IPsec encapsulation, in which the VPN route label is carried 112 across the network within an IPsec encapsulation. By "within an 113 IPsec encapsulation", we mean "in a packet containing an IP header 114 and an IPsec header". This IPsec encapsulation corresponds to an 115 IPsec Security Association (SA) whose two endpoints are the ingress 116 PE router and the egress PE router. The payload of the IPsec 117 encapsulation is an authenticated and/or encrypted MPLS packet, whose 118 label stack contains a single entry, viz., the VPN route label. The 119 payload of this MPLS packet is the user data packet being sent within 120 the VPN. 122 The IP/IPsec encapsulation will be used even if the ingress PE and 123 the egress PE are directly adjacent, i.e., even in the case where a 124 backbone route label would not be used. However, no IP/IPsec 125 encapsulation is applied if the ingress PE is the same device as the 126 egress PE. 128 If additional MPLS services, such as traffic engineering, are used in 129 the backbone network, an MPLS label stack will appear above the IP 130 header. This is orthogonal to any issues discussed in the present 131 document. This results in an MPLS packet containing an IP packet 132 containing an IPsec packet containing an MPLS packet; the latter MPLS 133 packet has a single label, the VPN route label. 135 This document is inspired by [VPN-SPI], and originated as an attempt 136 to improve upon it. 138 The remainder of section 1 outlines a number of issues which can be 139 addressed by the use of IPsec in this manner. 141 1.1. Issue: MPLS Infrastructure Required 143 "Conventional" RFC2547 VPNs require that there be an MPLS Label 144 Switched Path (LSP) between a packet's ingress PE router and its 145 egress PE router. This means that an RFC2547 VPN cannot be 146 implemented if there is a part of the path between the ingress and 147 egress PE routers which does not support MPLS. 149 In order to enable RFC2547 VPNs to be deployed even when there are 150 non-MPLS routers along the path between the ingress and egress PE 151 routers, it is desirable to have an alternative which allows the 152 backbone route label to be replaced with an IP header. This 153 encapsulating IP header would encapsulate an MPLS packet containing 154 only the VPN route label. The encapsulation header would have the 155 address of the egress PE in its destination IP address field; this 156 would cause the packet to be delivered to the egress PE. 158 It is possible to replace the backbone route label with an IP header, 159 possibly followed by a GRE header [MPLS-in-IP/GRE]. However, it then 160 becomes quite difficult, in general, to protect the VPNs against 161 spoofed packets. A Service Provider (SP) can protect against spoofed 162 MPLS packets by the simple expedient of not accepting MPLS packets 163 from outside its own boundaries (or more generally by keeping track 164 of which labels are validly received over which interfaces, and 165 discarding packets which arrive with labels that are not valid for 166 their incoming interfaces). Protection against spoofed IP packets 167 requires having all the boundary routers perform filtering; either 168 (a) filtering out packets from "outside" which are addressed to PE 169 routers, or (b) filtering out packets from "outside" which have 170 source addresses that belong "inside", and having PE routers refuse 171 to accept packets addressed to them but with "outside" source 172 addresses. The maintenance of these filter lists can be management- 173 intensive, and the their use at all border routers can affect the 174 performance seen by all traffic entering the SP's network. Further, 175 these filtering techniques may be difficult to apply in the case of 176 multi-provider VPNs, because in multi-provider VPNs, packets from 177 outside an SP's network can legitimately be addressed to its PE 178 routers. 180 If, on the other hand, the backbone route label is replaced by an 181 IPsec encapsulation, protection against spoofed packets does not rely 182 on filtering at the border. The cryptographic authentication 183 features of IPsec enable an egress PE to detect and discard packets 184 for a particular VPN that were not generated by a valid ingress PE 185 for that VPN. Thus spoofing protection is managed entirely at the 186 ingress and egress PE routers, transparently to the border routers. 187 IPsec does have its own management and performance implications, of 188 course. 190 1.2. Issue: Protection Against Misbehavior by Transit Nodes 192 Cryptographic authentication applied by the ingress PE on a PE-to-PE 193 basis can protect against the misrouting or modification (intentional 194 or accidental) of packets by the transit nodes. Packets which get 195 forwarded to the "wrong" egress PE will not pass authentication, nor 196 will packets which have been modified. As the VPN route label is 197 part of the IPsec packet payload, the egress PE will know that the 198 VPN route label was placed in the packet by a valid ingress PE. 200 1.3. Issue: Limitations on Multi-Provider Misconfigurations 202 Sometimes a VPN will have some sites which connect to one SP (SP1), 203 and some other sites which connect to another SP (SP2). 205 Consider a case in which VPN V1 has sites attaching to SP1 and SP2, 206 but VPN V2 has all of its sites attaching only to SP2. 208 SP2 would like to ensure that nothing done by SP1 can cause V1 to get 209 illegitimately cross-connected to V2. Since V2 has no sites in SP1, 210 it should be immune to the effects of any misconfigurations within 211 SP1. 213 This assurance can be achieved if the egress PE (in SP2) can 214 determine, for each VPN packet, whether that packet came from SP1, 215 and if so, whether it carries an MPLS label which corresponds to a 216 VPN route that was actually distributed to SP1. (That is, packets 217 originating from SP1 destined for VPNs in SP2 would be checked if 218 they are for VPNs which really have sites in SP1.) SP2's egress PEs 219 could be configured with the knowledge of which VPNs have sites 220 attached to SP1. Cryptographic authentication could then be used to 221 determine that a particular packet did indeed originate in SP1. 223 In general, if an egress PE knows which labels may be validly applied 224 by which ingress PEs, IPsec authentication can be used to ensure that 225 a given ingress PE has not applied a label that it has no right to 226 use. However, the scalability of the VPN scheme would be severely 227 compromised if an egress PE had to distribute a different set of 228 labels to each ingress PE. Therefore we will not pursue this general 229 case, but will only pursue label authentication in the inter-provider 230 case. 232 1.4. Issue: Privacy for VPN Data 234 IPsec Security Associations that associate ingress PE routes with 235 egress PE routers do not ensure privacy for VPN data. The data is 236 exposed on the PE-CE access links, and is exposed in the PE routers 237 themselves. Complete privacy requires that the encryption/decryption 238 be performed within the enterprise, not by the SP. So the use of 239 PE-PE IPsec encryption within the network of a single SP will perhaps 240 be of less import than the use of IPsec authentication. On the other 241 hand, if an SP is trusted to properly secure its routers, but the 242 transmission media used by the SP are not trusted, then PE-PE 243 encryption does provide a valuable measure of privacy. 245 There may be a need for encryption if a VPN has sites attached to 246 different trusted SPs, but some of the transit traffic needs to go 247 through the "public Internet". In this case, it may be necessary to 248 encrypt the VPN data traffic as it crosses the public Internet. 249 However, while PE-PE encryption is the one way to handle this, it is 250 not the only way. An alternative would be to use an encrypted tunnel 251 to connecting a border router of one trusted SP to a border router of 252 another. Then the two trusted domains could be treated as immediate 253 neighbors, adjacent over the tunnel. This would keep the 254 encryption/decryption at the few locations where it is actually 255 needed. On the other hand, there may be performance and scalability 256 advantages to spreading the cost of the cryptography among a larger 257 set of routers, viz., the ingress and egress PEs. 259 The scenario of having VPN traffic go from a trusted domain through 260 an untrusted domain to another trusted domain may not be completely 261 realistic, though, due to the difficulty of supporting the necessary 262 Service Level Agreements through the public Internet. 264 1.5. Non-Issue: General Protection against Misconfiguration 266 In general, the integrity of an RFC2547 VPN depends upon the SP 267 having properly configured the PE routers. There is no way of 268 preventing an SP from creating a bogus VPN that contains sites which 269 aren't supposed to communicate with each other. It is the SP's 270 responsibility to get this right. 272 It is sometimes thought one can obtain protection against 273 misconfigurations by having the PE routers apply cryptographic 274 authentication to the VPN packets. This is not the case. If an 275 ingress PE router has been misconfigured so as to assign a particular 276 site to the wrong VPN, likely as not the PE has been misconfigured to 277 apply that VPN's authenticator to packets to/from that site. 279 Protection against misconfiguration on the part of the SP requires 280 that the authentication procedure be applied before the ingress PE 281 router sees the packets, and after the egress PE router forwards 282 them, and cannot be dealt with by PE-PE IPsec. 284 1.6. Conclusion 286 Taken together, the above set of issues suggest that there are 287 situations in which using PE-PE IPsec as the tunneling protocol for 288 RFC2547 VPNs does have value. In the next section, we specify the 289 necessary procedures for incorporating PE-PE IPsec as a tunneling 290 option for RFC2547 VPNs. 292 2. Specification 294 2.1. Technical Approach 296 In short, the technical approach specified here is: 298 1. Use the standard technique [RFC2547bis] of using an MPLS label 299 to represent a VPN route, by prepending an MPLS label stack to 300 the VPN packets. However, the label stack will contain only one 301 label, the VPN route label. 303 2. Use an MPLS-in-IP or MPLS-in-GRE encapsulation to turn the 304 above MPLS packet back into an IP packet. This in effect 305 creates an "IP tunnel" or a "GRE tunnel" between the ingress PE 306 router and the egress PE router. 308 3. Use IPsec Transport Mode to secure the above-mentioned IP 309 tunnels. 311 The net effect is that an MPLS packet gets sent through an IPsec- 312 secured IP or GRE tunnel. 314 The following sub-sections specify this procedure in greater detail. 316 2.2. Selecting the Security Policy 318 One might think that a given SP (or set of cooperating SPs) will 319 decide either that they need to use IPsec for ALL PE-PE tunnels, or 320 else that PE-PE IPsec is not needed at all. But this simple "all or 321 nothing" strategy does not really capture the set of considerations 322 discussed in the Introduction. For example, a very reasonable policy 323 might be to use IPsec only for inter-provider PE-PE tunnels, while 324 using MPLS for intra-provider PE-PE tunnels. Or one might decide to 325 use IPsec only for certain inter-provider tunnels. Or one might 326 decide to use IPsec for certain intra-provider tunnels. 328 In an RFC2547 VPN environment, it makes most sense to place control 329 of the policies with the egress PE router. It is the egress PE which 330 needs to know that it wants to process certain packets ONLY if they 331 come through encrypted tunnels, and that it wants to discard those 332 same packets if they don't come through encrypted tunnels. Thus one 333 needs to be able to configure a policy into the egress PE, and have 334 it signal that policy to the ingress PE. RFC2547 already provides an 335 egress-to-ingress signaling capability via BGP, and we specify below 336 how to extend this to the signalling of security policy. 338 Of course, there is nothing to stop an ingress PE router from being 339 configured to use IPsec even if the egress PE has not signalled its 340 desire for IPsec. This should work, as long as the necessary IPsec 341 infrastructure is in place. (However, in this sort of application 342 the ingress PE and the egress PE are NOT really independent entities 343 which might conceivably have different security policies.) 345 2.3. BGP Label, Route, and Policy Distribution 347 Distribution of labeled VPN-IP routes by BGP is done exactly as 348 specified in [RFC2547bis], except that some additional BGP attributes 349 are needed for each distributed VPN-IP route. 351 A given egress PE will be configurable to indicate whether it expects 352 to receive all, some, or none of its VPN traffic through an IPsec- 353 secured IP or GRE tunnel. In general, an ingress PE will not have to 354 know in advance whether any of the egress PEs for its VPNs require 355 their VPN traffic to be sent through an IPsec-secured IP tunnel; this 356 will be signaled from the egress PE. If an egress PE wants to receive 357 traffic for a particular VPN-IP route through an IPsec-secured IP 358 tunnel, it adds a new BGP Extended Community attribute to the route. 359 This attribute will then get distributed along with the route to the 360 ingress PEs. 362 We call this attribute the "IPsec Extended Community". (It is 363 possible that this will actually be encoded as a particular value or 364 set of values of a more general "Tunnel Type Extended Community"; for 365 the purposes of this draft, however, we will continue to refer to it 366 as the "IPsec Extended Community".) 368 It is conceivable that an egress PE in a particular SP's network will 369 only want to receive IPsec-secured IP-tunneled traffic for those VPNs 370 which have sites that are attached to other SPs. In this case, one 371 would want to be able to configure, on a per-VRF basis, whether 372 routes exported from that VRF should have an IPsec Extended Community 373 attribute or not. 375 A more complex situation would arise if it were only desired to 376 receive IPsec-secured IP-tunneled traffic for a particular VPN if 377 that traffic has originated from a site which is attached to a 378 different SP's network. That is, one might want to receive inter- 379 provider traffic through an IPsec-secured IP tunnel, but to receive 380 intra-provider traffic through an unsecured MPLS LSP. As long as an 381 SP has a policy of never accepting MPLS packets from other SPs, this 382 may provide the necessary security while minimizing the amount of 383 cryptography that actually has to be used. 385 One way to do this would be to map each exportable IP address prefix 386 into two different VPN-IP prefixes, using two different RDs (say RD1 387 and RD2). Then two different RTs (say RT1 and RT2) would be used, 388 one of which causes intra-provider distribution, and one of which 389 causes inter-provider distribution. The prefixes with RD1 would be 390 given RT1 as a route target; the prefixes with RD2 would be given RT2 391 as a route target. If RT2 is the route target that causes inter- 392 provider distribution, then only the routes with RT2 would carry the 393 IPsec Extended Community. 395 A simpler approach, perhaps, would be to use only a single set of 396 VPN-IP prefixes, but to have a value of the IPsec Extended Community 397 which encodes an SP identifier, and which means "only use IPsec if 398 the ingress PE is in a different SP network than the one which is 399 identified here". (Again, the assumption is that MPLS packets are not 400 accepted from other SPs.) 402 It is conceivable that an egress PE will want some of its IPsec- 403 secured IP-tunneled VPN traffic to be encrypted, but will want some 404 to be authenticated and not encrypted. It is even conceivable that it 405 will want some traffic to arrive through an IPsec tunnel without 406 being either encrypted or authenticated. The IPsec Extended Community 407 attribute should have a value which specifies which of these are 408 required. 410 It may be desirable to allow the IPsec Extended Community to specify 411 a set of policies, so that the ingress PE can choose from among them. 413 2.4. MPLS-in-IP/GRE Encapsulation by Ingress PE 415 When a PE receives a packet from a CE, it looks up the packet's IP 416 destination address in the VRF corresponding to that CE. This enables 417 it to find a VPN-IP route. The VPN-IP route will have an associated 418 MPLS label and an associated BGP Next Hop. The label is pushed on the 419 packet. Then, if (and only if) the VPN-IP route has an IPsec Extended 420 Community attribute, an IP or GRE encapsulation header is prepended 421 to the packet, creating an MPLS-in-IP or MPLS-in-GRE encapsulated 422 packet. The IP source address field of the encapsulation header will 423 be an address of the ingress PE itself. The IP destination address 424 field of the encapsulation header will contain the value of the 425 associated BGP Next Hop attribute; this will be an IP address of the 426 egress PE. 428 (This description is not meant to specify an implementation strategy; 429 any implementation procedure which produces the same result is 430 acceptable.) 432 N.B.: If the ingress PE and the egress PE are not in the same 433 autonomous system, this requires that there be an EBGP connection 434 between a router in one autonomous system and a router in another. If 435 the two autonomous systems are not adjacent, this will need to be a 436 multi-hop EBGP connection. 438 The effect is to dynamically create an IP tunnel between the ingress 439 and egress PE routers. No apriori configuration of the remote tunnel 440 endpoints is needed. Note that these IP tunnels are NOT IGP-visible 441 links, and routing adjacencies are NOT supported across these tunnel. 442 Note also that the set of remote tunnel endpoints is NOT known in 443 advance, but is learned dynamically via the BGP distribution of VPN- 444 IP routes. 446 These IP tunneled packets will then be associated with an IPsec 447 Security Association (SA), and transported using IPsec transport 448 mode. This is described in more detail in the next sub-section. 450 2.5. MPLS-in-IP vs. MPLS-in-GRE 452 The MPLS-in-IP encapsulation header is shorter than the MPLS-in-GRE 453 encapsulation header, and, in theory at least, the latter offers no 454 advantages to compensate for its use of a longer header. 456 In practice, implementation considerations of various sorts may make 457 the MPLS-in-GRE encapsulation preferable. 459 2.6. PE-PE IPsec (Application of IPsec by Ingress PE) 461 A given ingress PE needs to have an IPsec SA with each PE router that 462 is an egress PE for traffic which the ingress PE receives from a CE. 464 In general, the set of egress PEs for a given ingress PE is not known 465 in advance. This is determined dynamically by the BGP distribution of 466 VPN-IP routes. This suggests that it will be very important to be 467 able to set up IPsec SAs dynamically, and that static keying will not 468 be a viable option. There will need to be a key distribution 469 infrastructure that supports multiple SPs, and IKE will need to be 470 used. 472 A number of different VPNs might need to have traffic carried from a 473 particular ingress PE to a particular egress PE. It is thus natural 474 to ask whether there should be one SA between the pair of PEs, or n 475 SAs between the pair of PEs, where n is the number of VPNs. Clearly, 476 scalability is improved by having only a single SA for each pair of 477 PEs. So the question is whether there is a significant security 478 advantage to having a distinct SA for each VPN. There does not appear 479 to be any such advantage. Since the SA is PE-to-PE, NOT CE-to-CE, 480 having a different SA for each VPN does not provide any additional 481 security. 483 It is conceivable that there might need to be two (or more) SAs 484 between a pair of PEs, e.g., one in which data encryption is used and 485 one in which authentication but not encryption is used. But this is 486 not the same as having a separate SA for each VPN. 488 We assume that the PE router will contain an IPsec module (either a 489 hardware or a software module) which is responsible for doing the key 490 exchange, for setting up the IPsec SAs as needed, and for doing the 491 cryptography. 493 As discussed in section 2.2, the PE router creates an MPLS-in-IP or 494 MPLS-in-GRE encapsulated packet. It does not simply send that packet 495 to its next hop, rather, it delivers the packet, along with the 496 corresponding IPsec Extended Community value, to the IPsec module. 498 (As an implementation consideration, it is not really required to 499 deliver an MPLS-in-IP or MPLS-in-GRE encapsulated packet to the IPsec 500 module; all that really needs to be delivered is the MPLS packet and 501 the information, or a pointer thereto, that would be needed to create 502 the IP encapsulation header.) 504 The IPsec module will set up an IPsec SA to the packet's destination 505 address, if one does not already exist. It will then apply the 506 appropriate IPsec procedures, generating a packet with an IP header 507 followed by an IPsec header followed by an MPLS label stack followed 508 by the original data packet. The IPsec module then delivers this 509 packet, as if it were a brand new packet, to the routing module. The 510 routing module forwards it as an IP packet. 512 While the IPsec SA is being set up, packets cannot be delivered 513 through it. Packets may be dropped during this time, though a 514 sensible policy might be to queue the first packet and drop the rest 515 (as is commonly done in ARP implementations while awaiting an ARP 516 resolution). 518 We do assume here that the IPsec module is subsidiary to the PE 519 router, and does not function itself as an independent router in the 520 network. A solution could be designed to support the latter case, but 521 at a considerable increment in complexity. 523 The procedure as specified above requires two routing lookups. Before 524 IPsec processing, The original packet's destination address is looked 525 up in a VRF. After IPsec processing, the IPsec packet's destination 526 address is looked up in the default routing table. It is worth 527 noting that the information obtained from the second lookup is really 528 available at the time of the first lookup. In some routers, it might 529 be advantageous to forward this information, along with the packet, 530 to the IPsec module; possibly this can be used to avoid the need for 531 the second lookup. However, in some routers, it will be impossible to 532 avoid the second lookup. 534 2.7. Application of IPsec by Egress PE 536 We assume that every egress PE is also an ingress PE, and hence has 537 the IPsec module which is mentioned in section 2.2. This module will 538 handle the necessary IKE functions, SA and tunnel maintenance, etc., 539 etc, as well as handling arriving IPsec packets. The IPsec module 540 will apply the necessary IPsec procedures to arriving IPsec packets, 541 and will hence recover the contained MPLS-in-IP or MPLS-in-GRE 542 packets. The IPsec module should then strip off the encapsulating IP 543 header to recover the MPLS packet, and should then deliver the 544 resulting MPLS packet to the routing function for ordinary MPLS 545 switching. (Of course, as an implementation matter, there is probably 546 no need to put the encapsulating IP header on only to then take it 547 off immediately.) 549 There are subtle issues having to do with the proper handling of MPLS 550 packets (rather than IPsec packets) which the PE router receives from 551 P routers or from other PE routers. If the top label on a received 552 MPLS packet corresponds to an IP route in the "default" routing 553 table, "ordinary" MPLS switching is done. But if the top label on a 554 received MPLS packet corresponds to a VPN-IP route, there are a 555 number of different cases to consider: 557 a. The packet has just been removed from an IPsec SA by the IPsec 558 module. In this case, ordinary MPLS switching should be done. 559 (though see below for further qualifications.) 561 b. The packet arrived from a neighboring P or PE router as an MPLS 562 packet, with no IPsec encapsulation. There are a number of 563 sub-cases: 565 i. The packet's top label corresponds to a VPN-IP route 566 which was not exported with the IPsec Extended 567 Community attribute. In this case, ordinary MPLS 568 switching is applied. 570 ii. The packet's top label corresponds to a VPN-IP route 571 which was exported with the value of the IPsec Extended 572 Community attribute which indicates that IPsec is to be 573 used only when the ingress PE is in a different SP 574 network. In this case, we assume that MPLS packets are 575 not being accepted from other networks, so ordinary 576 MPLS switching is applied. 578 iii. The packet's top label corresponds to a VPN-IP route 579 which was exported with an IPsec Extended Community, 580 but case ii does not apply. In this case the packet 581 should be discarded; packets with this label are 582 supposed to be secured, but this packet was not 583 properly secured. 585 Providing this functionality requires the use of two separate label 586 lookup tables, one of which is used for packets that have been 587 removed from IPsec SAs, and one of which is used for other packets. 588 Labels which are only valid when they are carried within an IPsec 589 packet would only appear in the former lookup table. This does imply 590 that after a packet has been processed by the IPsec module, the 591 contained MPLS packet is not simply returned to the routing lookup 592 path; rather it must carry some indication of which label lookup 593 table must be used to switch that packet. This also presupposes that 594 there will be MPLS VPN code to properly populate the two different 595 lookup tables. Perhaps packets removed from IPsec SAs should appear, 596 to the routing module, to be arriving on a particular virtual 597 interface, rather than on the actual sub-interface over which they 598 really arrived. Then interface-specific label lookup tables could be 599 used. 601 In fact, it may be advantageous to have more than one label lookup 602 table that is used for packets that have been removed from IPsec SAs. 603 Certain VPN-IP routes will be exported to certain SPs, but not to 604 others. Security can thus be improved by having one label lookup 605 table for each such SP. The IPsec module would then have to say, for 606 each packet, which SP it came from. Given a proper certificate 607 authority infrastructure this can be inferred by the IPsec module 608 from the information which the IKE procedure makes available to it. 609 Of course, all this presupposes that the VPN code is capable of 610 properly populating the various lookup tables. 612 3. Comparison with Using Part of SPI Field as a Label 614 An alternative methodology that achieves similar results is the one 615 described in [VPN-SPI]. The proposal described above was in fact 616 inspired by that draft, and arose as a proposed improvement to it. 618 In the current proposal, IPsec transport mode is applied to an MPLS- 619 in-IP encapsulation, where the MPLS-in-IP encapsulation carries the 620 BGP-distributed labels of RFC 2547. In [VPN-SPI], there is no MPLS- 621 in-IP encapsulation. Rather: 623 - IPsec tunnel mode is applied to the enduser's packet directly. 625 - A subfield of the IPsec SPI field is used to provide the function 626 of the BGP-distributed MPLS label. This either requires that BGP 627 distribute a different kind of label (one that can fit into the 628 SPI sub-field), or that an MPLS label be carried within the SPI 629 field. 631 The [VPN-SPI] proposal does have the advantage of making each packet 632 4 bytes shorter, since an entire entry in the MPLS label stack is 633 eliminated (replaced by the SPI sub-field). 635 The current proposal, unlike that in [VPN-SPI], does not in any way 636 alter the use or interpretation of the SPI field, and does not impact 637 the IPsec or IKE protocols and procedures in any way. The current 638 proposal also better preserves the distinction between fields that 639 are meaningful to IPsec and fields that are meaningful to 640 routing/forwarding. Failure to preserve this layering could 641 potentially lead to complications in the future (e.g., if BGP ever 642 needed to distribute a stack of two MPLS labels, or if some 643 enhancement to IPsec ever needed to reclaim the SPI sub-field used to 644 carry the label, etc., etc.). Failure to preserve the layering also 645 complicates the situation in which the transport is sometimes IPsec 646 and sometimes MPLS. Keeping the MPLS VPN functionality in the MPLS 647 layer and out of the IPsec layer certainly seems worthwhile. 649 4. Authors' Addresses 651 Eric C. Rosen 652 Cisco Systems, Inc. 653 1414 Massachusetts Avenue 654 Boxborough, MA 01719 655 Email: erosen@cisco.com 657 Jeremy De Clercq 658 Alcatel 659 Francis Wellesplein 1 660 2018 Antwerpen, Belgium 661 Phone: +32 3 240 4752 662 Email: jeremy.de_clercq@alcatel.be 664 Olivier Paridaens 665 Alcatel 666 Francis Wellesplein 1 667 2018 Antwerpen, Belgium 668 Phone: +32 3 240 9320 669 Email: olivier.paridaens@alcatel.be 670 Yves T'Joens 671 Alcatel 672 Francis Wellesplein 1 673 2018 Antwerpen, Belgium 674 Phone: +32 3 240 7890 675 Email: yves.tjoens@alcatel.be 677 Chandru Sargor 678 CoSine Communications 679 1200 Bridge Parkway 680 Redwood City, CA 94065 681 Email: csargor@cosinecom.com 683 5. References 685 [MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al., 686 draft-ietf-mpls-in-ip-or-gre-01.txt, July 2003 688 [RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn- 689 rfc2547bis-00.txt, July 2003 691 [VPN-SPI] BGP/IPsec VPN, De Clercq et. al., draft-declercq-bgp- 692 ipsec-vpn-01.txt, February 2001