idnits 2.17.1 draft-rosen-ppvpn-ipsec-2547-00.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 333 has weird spacing: '...ht want to re...' == Line 334 has weird spacing: '...traffic throu...' == Line 343 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 (June 2001) is 8352 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 (-04) exists of draft-rosen-rfc2547bis-03 -- Possible downref: Normative reference to a draft: ref. 'RFC2547bis' -- Possible downref: Normative reference to a draft: ref. 'VPN-SPI' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: December 2001 5 Jeremy De Clercq 6 Olivier Paridaens 7 Yves T'Joens 8 Alcatel 10 Chandru Sargor 11 Cosine Communications 13 June 2001 15 Use of PE-PE IPsec in RFC2547 VPNs 17 draft-rosen-ppvpn-ipsec-2547-00.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 This draft describes a variation of RFC2547 [RFC2547bis] in which the 42 outermost MPLS label of a VPN packet is replaced with an IPsec 43 encapsulation. This enables the VPN packets to be carried over non- 44 MPLS networks, and allows the IPsec authentication and encryption 45 functions to be used to protect VPN packets. 47 Table of Contents 49 1 Introduction ........................................... 2 50 1.1 Issue: MPLS Infrastructure Required .................... 3 51 1.2 Issue: Protection Against Misbehavior by Transit Nodes . 4 52 1.3 Issue: Limitations on Multi-Provider Misconfigurations . 4 53 1.4 Issue: Privacy for VPN Data ............................ 5 54 1.5 Non-Issue: General Protection against Misconfiguration . 6 55 1.6 Conclusion ............................................. 6 56 2 Specification .......................................... 6 57 2.1 Technical Approach ..................................... 6 58 2.2 Selecting the Security Policy .......................... 7 59 2.3 BGP Label, Route, and Policy Distribution .............. 7 60 2.4 MPLS-in-IP Encapsulation by Ingress PE ................. 9 61 2.5 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 10 62 2.6 Application of IPsec by Egress PE ...................... 11 63 3 Comparison with Using Part of SPI Field as a Label ..... 13 64 4 Summary for Sub-IP Area ................................ 14 65 4.1 Summary ................................................ 14 66 4.2 Where does it fit in the Picture of the Sub-IP Work .... 14 67 4.3 Why is it Targeted at this WG .......................... 14 68 4.4 Justification .......................................... 14 69 5 Authors' Addresses ..................................... 14 70 6 References ............................................. 15 72 1. Introduction 74 In "conventional" RFC2547 VPNs, when a PE router receives a packet 75 from a CE router, it looks up the packet's destination IP address in 76 a VRF. As a result of this lookup, it obtains an MPLS label stack, a 77 data link header, an output interface. The label stack is prepended 78 to the packet, the data link header is prepended to that, and the 79 resulting frame is queued for the output interface. 81 The bottom label on the MPLS label stack is always a label which will 82 not be seen until the packet reaches its point of egress from the 83 network. This label represents a particular route within the packet's 84 VPN. The purpose of the upper labels is to cause the packet to be 85 delivered to the router which understands the bottom label. 87 What we discuss here are procedures creating an MPLS packet which 88 carries ONLY the bottom label, and then using an IPsec encapsulation 89 to carry that MPLS packet (authenticated and/or encrypted) across the 90 network. That is, the upper labels are replaced with an IP header and 91 an IPsec header. The two endpoints of the IPsec Security Association 92 will be the ingress PE router and the egress PE router. 94 This note is inspired by [VPN-SPI], and originated as an attempt to 95 improve upon it. 97 The remainder of section 1 outlines a number of issues which can be 98 addressed by the use of IPsec. 100 1.1. Issue: MPLS Infrastructure Required 102 "Conventional" RFC2547 VPNs require that there be an MPLS Label 103 Switched Path (LSP) between a packet's ingress PE router and its 104 egress PE router. This means that an RFC2547 VPN cannot be 105 implemented if there is a part of the path between the ingress and 106 egress PE routers which does not support MPLS. 108 In order to enable RFC2547 VPNs to be deployed even when there are 109 non-MPLS router along the path between the ingress and egress PE 110 routers, it is desirable to have an alternative which allows the 111 upper labels to be replaced with an IP header. This encapsulating IP 112 header would encapsulate an MPLS packet containing only a bottom 113 label. The encapsulation header would have the address of the egress 114 PE in its destination IP address field, and this would cause the 115 packet to be delivered to the egress PE. 117 In this procedure, the ingress and egress PEs themselves must support 118 MPLS, but that is not an issue, as those routers must necessarily 119 have RFC2547 VPN support, whereas the transit routers arguably should 120 be able to be "vanilla" routers with no special MPLS or VPN support. 121 This is most likely to be of import when VPN traffic must transit 122 through multiple providers. 124 It should be noted that if the upper MPLS labels are replaced with an 125 unsecured IP encapsulation, it becomes more difficult to protect the 126 VPNs against spoofed packets. A Service Provider (SP) can protect 127 against spoofed MPLS packets by the simple expedient of not accepting 128 MPLS packets from outside its own boundaries (or more generally by 129 keeping track of which labels are validly received over which 130 interfaces, and discarding packets which arrive with labels that are 131 not valid for their incoming interfaces). Protection against spoofed 132 IP packets requires having all the boundary routers perform 133 filtering; either filtering out packets from "outside" which are 134 addressed to PE routers, or filtering out packets from "outside" 135 which have source addresses that belong "inside". The maintenance of 136 these filter lists can be management-intensive, and the their use at 137 all border routers can affect the performance seen by all traffic 138 entering the SP's network. 140 If an IPsec encapsulation is used, however, this filtering at the 141 border can be eliminated, and the spoofing protection can be managed 142 at the ingress and egress PE routers, transparently to the border 143 routers. IPsec does have its own management and performance 144 implications, of course. 146 1.2. Issue: Protection Against Misbehavior by Transit Nodes 148 Authentication applied by the ingress PE on a PE-to-PE basis can 149 protect against the misrouting or modification (intentional or 150 accidental) of packets by the transit nodes. Packets which get 151 forwarded to the "wrong" egress PE will not pass authentication, nor 152 will packets which have been modified. In particular, the 153 authentication should guarantee the integrity of whatever MPLS labels 154 are carried by the packet. 156 1.3. Issue: Limitations on Multi-Provider Misconfigurations 158 Sometimes a VPN will have some sites which connect to one SP (SP1), 159 and some other sites which connect to another SP (SP2). 161 Consider a case in which VPN V1 has sites attaching to SP1 and SP2, 162 but VPN V2 has all of its sites attaching only to SP2. 164 SP2 would like to ensure that nothing done by SP1 can cause V1 to get 165 illegitimately cross-connected to V2. Since V2 has no sites in SP1, 166 it should be immune to the effects of any misconfigurations within 167 SP1. 169 This assurance can be achieved if the egress PE (in SP2) can 170 determine, for each VPN packet, whether that packet came from SP1, 171 and if so, whether it carries an MPLS label which corresponds to a 172 VPN route that was actually distributed to SP1. (That is, packets 173 originating from SP1 destined for VPNs in SP2 would be checked if 174 they are for VPNs which really have sites in SP1.) SP2's egress PEs 175 could be configured with the knowledge of which VPNs have sites 176 attached to SP1. Cryptographic authentication could then be used to 177 determine that a particular packet did indeed originate in SP1. 179 In general, if an egress PE knows which labels may be validly applied 180 by which ingress PEs, IPsec authentication can be used to ensure that 181 a given ingress PE has not applied a label that it has no right to 182 use. However, the scalability of the VPN scheme would be severely 183 compromised if an egress PE had to distribute a different set of 184 labels to each ingress PE, so we will not pursue this general case, 185 but will only pursue label authentication in the inter-provider case. 187 1.4. Issue: Privacy for VPN Data 189 IPsec Security Associations that associate ingress PE routes with 190 egress PE routers do not ensure privacy for VPN data. The data is 191 exposed on the PE-CE access links, and is exposed in the PE routers 192 themselves. Complete privacy requires that the encryption/decryption 193 be performed within the enterprise, not by the SP. So the use of 194 PE-PE IPsec encryption within the network of a single SP will perhaps 195 be of less import than the use of IPsec authentication. On the other 196 hand, if an SP is trusted to properly secure its routers, but the 197 transmission media used by the SP are not trusted, then PE-PE 198 encryption does provide the necessary privacy. 200 There may be a need for encryption if a VPN has sites attached to 201 different trusted SPs, but some of the transit traffic needs to go 202 through the "public Internet". In this case, it may be necessary to 203 encrypt the VPN data traffic as it crosses the public Internet. 204 However, while PE-PE encryption is the one way to handle this, it is 205 not the only way. An alternative would be to use an encrypted tunnel 206 to connecting a border router of one trusted SP to a border router of 207 another. Then the two trusted domains could be treated as immediate 208 neighbors, adjacent over the tunnel. This would keep the 209 encryption/decryption at the few locations where it is actually 210 needed. On the other hand, there may be performance and scalability 211 advantages to spreading the cost of the cryptography among a larger 212 set of routers, viz., the ingress and egress PEs. 214 The scenario of having VPN traffic go from a trusted domain through 215 an untrusted domain to another trusted domain may not be completely 216 realistic, though, due to the difficulty of supporting the necessary 217 Service Level Agreements through the public Internet. (This is an 218 issue of some controversy.) 220 1.5. Non-Issue: General Protection against Misconfiguration 222 In general, the integrity of an RFC2547 VPN depends upon the SP 223 having properly configured the PE routers. There is no way of 224 preventing an SP from creating a bogus VPN that contains sites which 225 aren't supposed to communicate with each other. It is the SP's 226 responsibility to get this right. 228 It is sometimes thought one can obtain protection against 229 misconfigurations by having the PE routers apply cryptographic 230 authentication to the VPN packets. This is not the case. If an 231 ingress PE router has been misconfigured so as to assign a particular 232 site to the wrong VPN, likely as not the PE has been misconfigured to 233 apply that VPN's authenticator to packets to/from that site. 235 Protection against misconfiguration on the part of the SP requires 236 that the authentication procedure be applied before the ingress PE 237 router sees the packets, and after the egress PE router forwards 238 them, and cannot be dealt with by PE-PE IPsec. 240 1.6. Conclusion 242 Taken together, the above set of issues suggest that there are 243 situations in which using PE-PE IPsec as the tunneling protocol for 244 RFC2547 VPNs does have value. In the next section, we specify the 245 necessary procedures for incorporating PE-PE IPsec as a tunneling 246 option for RFC2547 VPNs. 248 2. Specification 250 2.1. Technical Approach 252 In short, the technical approach specified here is: 254 1. Continue to use MPLS to identify a VPN-IP route, by continuing 255 to add an MPLS label stack to the VPN packets. However, the 256 label stack will carry only one label, the current "bottom 257 label." 259 2. An MPLS-in-IP encapsulation will be used to turn the above MPLS 260 packet back into an IP packet. This in effect creates an IP 261 tunnel between the ingress PE router and the egress PE router. 263 3. IPsec Transport Mode will be used to secure the above-mentioned 264 IP tunnels. 266 The net effect is that an MPLS packet gets sent through an IPsec- 267 secured IP tunnel. 269 The following sub-sections attempt to flesh this out in more detail. 271 2.2. Selecting the Security Policy 273 One might think that a given SP (or set of cooperating SPs) will 274 decide either that they need to use IPsec for ALL PE-PE tunnels, or 275 else that PE-PE IPsec is not needed at all. But this simple "all or 276 nothing" strategy does not really capture the set of considerations 277 discussed in the Introduction. For example, a very reasonable policy 278 might be to use IPsec only for inter-provider PE-PE tunnels, while 279 using MPLS for intra-provider PE-PE tunnels. Or one might decide to 280 use IPsec only for certain inter-provider tunnels. Or one might 281 decide to use IPsec for certain intra-provider tunnels. 283 In an RFC2547 VPN environment, it makes most sense to place control 284 of the policies with the egress PE router. It is the egress PE which 285 needs to know that it wants to process certain packets ONLY if they 286 come through encrypted tunnels, and that it wants to discard those 287 same packets if they don't come through encrypted tunnels. This means 288 that we need to be able to configure a policy into the egress PE, and 289 have it signal that policy to the ingress PE. RFC2547 already 290 provides an egress-to-ingress signaling capability via BGP, and we 291 will specify how to extend this to the signalling of security policy. 293 Of course, there is nothing to stop an ingress PE router from being 294 configured to use IPsec even if the egress PE has not signalled its 295 desire for IPsec. This should work, as long as the necessary IPsec 296 infrastructure is in place. (However, in this sort of application 297 the ingress PE and the egress PE are NOT really independent entities 298 which might conceivably have different security policies.) 300 2.3. BGP Label, Route, and Policy Distribution 302 Distribution of labeled VPN-IP routes by BGP is done exactly as at 303 present, except that some additional BGP attributes are needed for 304 each distributed VPN-IP route. 306 A given egress PE will be configurable to indicate whether it expects 307 to receive all, some, or none of its VPN traffic through an IPsec- 308 secured IP tunnel. In general, an ingress PE will not have to know 309 in advance whether any of the egress PEs for its VPNs require their 310 VPN traffic to be sent through an IPsec-secured IP tunnel; this will 311 be signaled from the egress PE. The obvious way to do this is the 312 following. If an egress PE wants to receive traffic for a particular 313 VPN-IP route through an IPsec-secured IP tunnel, it adds a new BGP 314 Extended Community attribute to the route. This attribute will then 315 get distributed along with the route to the ingress PEs. 317 Let's call this attribute the "IPsec Extended Community". (It is 318 possible that this will actually be encoded as a particular value or 319 set of values of a more general "Tunnel Type Extended Community"; for 320 the purposes of this draft, however, we will continue to refer to it 321 as the "IPsec Extended Community".) 323 It is conceivable that an egress PE in a particular SP's network will 324 only want to receive IPsec-secured IP-tunneled traffic for those VPNs 325 which have sites that are attached to other SPs. In this case, one 326 would want to be able to configure, on a per-VRF basis, whether 327 routes exported from that VRF should have an IPsec Extended Community 328 attribute or not. 330 A more complex situation would arise if it were only desired to 331 receive IPsec-secured IP-tunneled traffic for a particular VPN if 332 that traffic has originated from a site which is attached to a 333 different SP's network. That is, one might want to receive inter- 334 provider traffic through an IPsec-secured IP tunnel, but to receive 335 intra-provider traffic through an unsecured MPLS LSP. As long as an 336 SP has a policy of never accepting MPLS packets from other SPs, this 337 may provide the necessary security while minimizing the amount of 338 cryptography that actually has to be used. 340 One way to do this would be to map each exportable IP address prefix 341 into two different VPN-IP prefixes, using two different RDs (say RD1 342 and RD2). Then two different RTs (say RT1 and RT2) would be used, 343 one of which causes intra-provider distribution, and one of which 344 causes inter-provider distribution. The prefixes with RD1 would be 345 given RT1 as a route target; the prefixes with RD2 would be given RT2 346 as a route target. If RT2 is the route target that causes inter- 347 provider distribution, then only the routes with RT2 would carry the 348 IPsec Extended Community. 350 A simpler approach, perhaps, would be to use only a single set of 351 VPN-IP prefixes, but to have a value of the IPsec Extended Community 352 which encodes an SP identifier, and which means "only use IPsec if 353 the ingress PE is in a different SP network than the one which is 354 identified here". (Again, the assumption is that MPLS packets are not 355 accepted from other SPs.) 356 It is conceivable that an egress PE will want some of its IPsec- 357 secured IP-tunneled VPN traffic to be encrypted, but will want some 358 to be authenticated and not encrypted. It is even conceivable that it 359 will want some traffic to arrive through an IPsec tunnel without 360 being either encrypted or authenticated. The IPsec Extended Community 361 attribute should have a value which specifies which of these are 362 required. 364 It may be desirable to allow the IPsec Extended Community to specify 365 a set of policies, so that the ingress PE can choose from among them. 367 2.4. MPLS-in-IP Encapsulation by Ingress PE 369 When a PE receives a packet from a CE, it looks up the packet's IP 370 destination address in the VRF corresponding to that CE. This enables 371 it to find a VPN-IP route. The VPN-IP route will have an associated 372 MPLS label and an associated BGP Next Hop. The label is pushed on the 373 packet. Then, if (and only if) the VPN-IP route has an IPsec Extended 374 Community attribute, an IP encapsulation header is prepended to the 375 packet, creating an MPLS-in-IP encapsulated packet. The IP source 376 address field of the encapsulation header will be an address of the 377 ingress PE itself. The IP destination address field of the 378 encapsulation header will contain the value of the associated BGP 379 Next Hop attribute; this will be an IP address of the egress PE. 381 (This description is not meant to specify an implementation strategy; 382 any implementation procedure which produces the same result is 383 acceptable.) 385 N.B.: If the ingress PE and the egress PE are not in the same 386 autonomous system, this requires that there be an EBGP connection 387 between a router in one autonomous system and a router in another. If 388 the two autonomous systems are not adjacent, this will need to be a 389 multi-hop EBGP connection. 391 The effect is to dynamically create an IP tunnel between the ingress 392 and egress PE routers. No apriori configuration of the remote tunnel 393 endpoints is needed. Note that these IP tunnels are NOT IGP-visible 394 links, and routing adjacencies are not supported across these tunnel. 395 Note also that the set of remote tunnel endpoints is NOT known in 396 advance, but is learned dynamically via the BGP distribution of VPN- 397 IP routes. 399 These IP tunneled packets will then be associated with an IPsec 400 Security Association (SA), and transported using IPsec transport 401 mode. This is described in more detail in the next sub-section. 403 2.5. PE-PE IPsec (Application of IPsec by Ingress PE) 405 A given ingress PE needs to have an IPsec SA with each PE router that 406 is an egress PE for traffic which the ingress PE receives from a CE. 408 In general, the set of egress PEs for a given ingress PE is not known 409 in advance. This is determined dynamically by the BGP distribution of 410 VPN-IP routes. This suggests that it will be very important to be 411 able to set up IPsec SAs dynamically, and that static keying will not 412 be a viable option. There will need to be a key distribution 413 infrastructure that supports multiple SPs, and IKE will need to be 414 used. 416 A number of different VPNs might need to have traffic carried from a 417 particular ingress PE to a particular egress PE. It is thus natural 418 to ask whether there should be one SA between the pair of PEs, or n 419 SAs between the pair of PEs, where n is the number of VPNs. Clearly, 420 scalability is improved by having only a single SA for each pair of 421 PEs. So the question is whether there is a significant security 422 advantage to having a distinct SA for each VPN. There does not appear 423 to be any such advantage. Since the SA is PE-to-PE, NOT CE-to-CE, 424 having a different SA for each VPN does not appear to provide any 425 additional protection. 427 It is conceivable that there might need to be two (or more) SAs 428 between a pair of PEs, e.g., one in which data encryption is used and 429 one in which authentication but not encryption is used. But this is 430 not the same as having a separate SA for each VPN. 432 We assume that the PE router will contain an IPsec module (either a 433 hardware or a software module) which is responsible for doing the key 434 exchange, for setting up the IPsec SAs as needed, and for doing the 435 cryptography. 437 As discussed in section 2.2, the PE router creates an MPLS-in-IP 438 encapsulated packet. It does not simply send that packet to its next 439 hop, rather, it delivers the packet, along with the corresponding 440 IPsec Extended Community value, to the IPsec module. (As an 441 implementation consideration, it is not really required to deliver an 442 MPLS-in-IP encapsulated packet to the IPsec module; all that really 443 needs to be delivered is the MPLS packet and the information (or 444 pointer thereto) that would be needed to create the IP encapsulation 445 header.) 447 The IPsec module will set up an IPsec SA to the packet's destination 448 address, if one does not already exist. It will then apply the 449 appropriate IPsec procedures, generating a packet with an IP header 450 followed by an IPsec header followed by an MPLS label stack followed 451 by the original data packet. The IPsec module then delivers this 452 packet, as if it were a brand new packet, to the routing module. The 453 routing module forwards it as an IP packet. 455 While the IPsec SA is being set up, packets cannot be delivered 456 through it. Packets may be dropped during this time, though a 457 sensible policy might be to queue the first packet and drop the rest 458 (as is commonly done in ARP implementations while awaiting an ARP 459 resolution). 461 We do assume here that the IPsec module is subsidiary to the PE 462 router, and does not function itself as an independent router in the 463 network. A solution could be designed to support the latter case, but 464 at a considerable increment in complexity. 466 The procedure as specified above requires two routing lookups. Before 467 IPsec processing, The original packet's destination address is looked 468 up in a VRF. After IPsec processing, the IPsec packet's destination 469 address is looked up in the default routing table. It is worth 470 noting that the information obtained from the second lookup is really 471 available at the time of the first lookup. In some environments, it 472 might be advantageous to forward this information, along with the 473 packet, to the IPsec module; possibly this can be used to avoid the 474 need for the second lookup. However, in some environments, it will be 475 impossible to avoid the second lookup. 477 2.6. Application of IPsec by Egress PE 479 We assume that every egress PE is also an ingress PE, and hence has 480 the IPsec module which is mentioned in section 2.2. This module will 481 handle the necessary IKE functions, SA and tunnel maintenance, etc., 482 etc, as well as handling arriving IPsec packets. The IPsec module 483 will apply the necessary IPsec procedures to arriving IPsec packets, 484 and will hence recover the contained MPLS-in-IP packets. The IPsec 485 module should then strip off the encapsulating IP header to recover 486 the MPLS packet, and should then deliver the resulting MPLS packet to 487 the routing function for ordinary MPLS switching. (Of course, as an 488 implementation matter, there is probably no need to put the 489 encapsulating IP header on only to then take it off immediately.) 491 There are subtle issues having to do with the proper handling of MPLS 492 packets (rather than IPsec packets) which the PE router receives from 493 P routers or from other PE routers. If the top label on a received 494 MPLS packet corresponds to an IP route in the "default" routing 495 table, "ordinary" MPLS switching is done. But if the top label on a 496 received MPLS packet corresponds to a VPN-IP route, there are a 497 number of different cases to consider: 499 a. The packet has just been removed from an IPsec SA by the IPsec 500 module. In this case, ordinary MPLS switching should be done. 501 (Well, ... see below for further qualifications.) 503 b. The packet arrived from a neighboring P or PE router as an MPLS 504 packet, with no IPsec encapsulation. Now we have some sub- 505 cases: 507 i. The packet's top label corresponds to a VPN-IP route 508 which was not exported with the IPsec Extended 509 Community attribute. In this case, ordinary MPLS 510 switching is applied. 512 ii. The packet's top label corresponds to a VPN-IP route 513 which was exported with the value of the IPsec Extended 514 Community attribute which indicates that IPsec is to be 515 used only when the ingress PE is in a different SP 516 network. In this case, we assume that MPLS packets are 517 not being accepted from other networks, so ordinary 518 MPLS switching is applied. 520 iii. The packet's top label corresponds to a VPN-IP route 521 which was exported with an IPsec Extended Community, 522 but case ii does not apply. In this case the packet 523 should be discarded; packets with this label are 524 supposed to be secured, but this packet was not 525 properly secured. 527 Providing this functionality requires the use of two separate label 528 lookup tables, one of which is used for packets that have been 529 removed from IPsec SAs, and one of which is used for other packets. 530 Labels which are only valid when they are carried within an IPsec 531 packet would only appear in the former lookup table. This does imply 532 that after a packet has been processed by the IPsec module, the 533 contained MPLS packet is not simply returned to the routing lookup 534 path; rather it must carry some indication of which label lookup 535 table must be used to switch that packet. This also presupposes that 536 there will be MPLS VPN code to properly populate the two different 537 lookup tables. Perhaps packets removed from IPsec SAs should appear, 538 to the routing module, to be arriving on a particular virtual 539 interface, rather than on the actual sub-interface over which they 540 really arrived. Then interface-specific label lookup tables could be 541 used. 543 In fact, it may be advantageous to have more than one label lookup 544 table that is used for packets that have been removed from IPsec SAs. 545 Certain VPN-IP routes will be exported to certain SPs, but not to 546 others. Security can thus be improved by having one label lookup 547 table for each such SP. The IPsec module would then have to say, for 548 each packet, which SP it came from. I think that given a proper 549 certificate authority infrastructure this can be inferred by the 550 IPsec module from the information which the IKE procedure makes 551 available to it. For this to work, the MPLS VPN code would have to be 552 able to properly populate the various lookup tables. 554 3. Comparison with Using Part of SPI Field as a Label 556 An alternative methodology that achieves similar results is the one 557 described in [VPN-SPI]. The proposal described above was in fact 558 inspired by that draft, and arose as a proposed improvement to it. 560 In the current proposal, IPsec transport mode is applied to an MPLS- 561 in-IP encapsulation, where the MPLS-in-IP encapsulation carries the 562 BGP-distributed labels of RFC 2547. In [VPN-SPI], there is no MPLS- 563 in-IP encapsulation. Rather: 565 - IPsec tunnel mode is applied to the enduser's packet directly. 567 - A subfield of the IPsec SPI field is used to provide the function 568 of the BGP-distributed MPLS label. This either requires that BGP 569 distribute a different kind of label (one that can fit into the 570 SPI sub-field), or that an MPLS label be carried within the SPI 571 field. 573 The [VPN-SPI] proposal does have the advantage of making each packet 574 4 bytes shorter, since an entire entry in the MPLS label stack is 575 eliminated (replaced by the SPI sub-field). 577 The current proposal, unlike that in [VPN-SPI], does not in any way 578 alter the use or interpretation of the SPI field, and does not impact 579 the IPsec or IKE protocols and procedures in any way. The current 580 proposal also better preserves the distinction between fields that 581 are meaningful to IPsec and fields that are meaningful to 582 routing/forwarding. Failure to preserve this layering could 583 potentially lead to complications in the future (e.g., if BGP ever 584 needed to distribute a stack of two MPLS labels, or if some 585 enhancement to IPsec ever needed to reclaim the SPI sub-field used to 586 carry the label, etc., etc.). Keeping the MPLS VPN functionality in 587 the MPLS layer and out of the IPsec layer certainly seems worthwhile. 589 4. Summary for Sub-IP Area 591 4.1. Summary 593 The base specification for RFC2547 VPNs, i.e., draft-rosen- 594 rfc2547bis-03.txt, specifies the procedures for providing a 595 particular style of VPN, using MPLS label switched paths between 596 Provider Edge (PE) routers. The base specification does not discuss 597 other types of tunnels between PE routers. 599 This draft extends the base specification by specifying the 600 procedures for providing the RFC2547 style of VPN using IPsec tunnels 601 (rather than MPLS LSPs) between PE routers. 603 4.2. Where does it fit in the Picture of the Sub-IP Work 605 This work fits squarely in the PPVPN box. 607 4.3. Why is it Targeted at this WG 609 The WG is chartered with considering the RFC2547 style of VPN. This 610 draft specifies procedures to allow that style of VPN to run on 611 networks which do not implement MPLS in the core switches, and/or in 612 environments in which increased security is needed. 614 Thus the draft allows the RFC2547 style of VPN to meet additional 615 requirements that are not met by the base specification. 617 4.4. Justification 619 The WG should consider this document as it extends a style of VPN 620 explicitly called out in the charter so that (a) additional security 621 requirements can be met, (b) it becomes applicable to a wider range 622 of IP-based backbone environments. 624 5. Authors' Addresses 626 Eric C. Rosen 627 Cisco Systems, Inc. 628 250 Apollo Drive 629 Chelmsford, MA, 01824 630 Email: erosen@cisco.com 631 Jeremy De Clercq 632 Alcatel 633 Francis Wellesplein 1 634 2018 Antwerpen, Belgium 635 Phone: +32 3 240 4752 636 Email: jeremy.de_clercq@alcatel.be 638 Olivier Paridaens 639 Alcatel 640 Francis Wellesplein 1 641 2018 Antwerpen, Belgium 642 Phone: +32 3 240 9320 643 Email: olivier.paridaens@alcatel.be 645 Yves T'Joens 646 Alcatel 647 Francis Wellesplein 1 648 2018 Antwerpen, Belgium 649 Phone: +32 3 240 7890 650 Email: yves.tjoens@alcatel.be 652 Chandru Sargor 653 CoSine Communications 654 1200 Bridge Parkway 655 Redwood City, CA 94065 656 Email: csargor@cosinecom.com 658 6. References 660 [RFC2547bis] BGP/MPLS VPNs, Rosen et. al., draft-rosen-rfc2547bis- 661 03.txt, 2/01. 663 [VPN-SPI] BGP/IPsec VPN, De Clercq et. al., draft-declercq-bgp- 664 ipsec-vpn-01.txt, 2/01.