idnits 2.17.1 draft-knight-ppvpn-ipsec-dynroute-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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2002) is 7956 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) == Unused Reference: 'RFC-2784' is defined on line 706, but no explicit reference was found in the text -- No information found for draft-ietf-ppvpn-ce-based - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CE-BASED' ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) == Outdated reference: A later version (-07) exists of draft-touch-ipsec-vpn-04 ** Downref: Normative reference to an Informational draft: draft-touch-ipsec-vpn (ref. 'TOUCH') -- Possible downref: Normative reference to a draft: ref. 'WANG' ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) -- Possible downref: Normative reference to a draft: ref. 'KHETAN' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Provider Provisioned VPN Working Group Paul Knight 2 Internet Draft Nortel Networks 3 draft-knight-ppvpn-ipsec-dynroute-01.txt 4 Expires: January 2003 Bryan Gleeson 5 Tahoe Networks 7 July 2002 9 A Method to Provide Dynamic Routing in IPsec VPNs 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Exchange of routing information between IPsec security gateways, 34 using standard routing protocols across IPsec tunnels, can be a 35 straightforward operation. Using the routing information to choose 36 the proper path is also straightforward, when routing is 37 functionally separated from the IPsec gateway operation. One of the 38 most significant obstacles to widespread implementation of dynamic 39 routing in IPsec VPNs has been agreement on a way to exchange and 40 use the routing information. This document describes a simple and 41 secure method of exchanging dynamic routing information between 42 IPsec security gateways, using standard IPsec messages. This method 43 is currently in use in a large number of installations, and has been 44 demonstrated to be interoperable across several IPsec 45 implementations from different vendors. 47 Table of Contents 49 Status of this Memo................................................1 50 Abstract...........................................................1 51 1. Conventions used in this document...............................2 52 2. Overview........................................................2 53 3. Routing in IPsec...............................................4 54 3.1 IPsec background...............................................4 55 3.2 IPsec routing issues...........................................4 56 3.3 "Tunnel Link" Approach.........................................5 57 3.3.1 Tunnel Mode "Tunnel Link"....................................6 58 3.3.2 Transport Mode Proposal......................................7 59 3.3.3 Tunnel vs. Transport as a "Tunnel Link"......................7 60 3.3.4 Routing over a "Tunnel Link".................................8 61 3.4 Methods of Establishing a "Tunnel Link"........................9 62 3.4.1 Method 1 - Vendor ID compatibility...........................9 63 3.4.2 Method 2 - Notify Message or new IPsec message...............9 64 3.4.3 Method 3 - Transport Mode with IP-in-IP.....................10 65 4. Other considerations...........................................11 66 4.1 Interoperability Issues.......................................11 67 4.2 Scalability...................................................11 68 4.3 OSPF Routing over a "Tunnel Link".............................12 69 5. Security Considerations........................................12 70 6. Summary for Sub-IP Area........................................13 71 6.1 Summary.......................................................13 72 6.2 Where does it fit in the picture of the Sub-IP work?..........13 73 6.3 Why is it targeted at this Working Group?.....................13 74 6.4 Justification.................................................13 75 7. Document Change History........................................14 76 8. References.....................................................14 77 9. Acknowledgements...............................................15 78 10. Authors' Addresses............................................15 79 Full Copyright Statement..........................................15 81 1. Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 85 this document are to be interpreted as described in [RFC 2119]. 87 2. Overview 89 Dynamic exchange of routing information between the various sites of 90 a Virtual Private Network (VPN) can significantly simplify the 91 management of the VPN. Without dynamic routing, it is difficult to 92 configure a large number of routes correctly and in a timely manner. 94 It is even more difficult to set up load balancing and failover when 95 the configuration is static. IPsec offers tremendous promise as a 96 VPN technology, since it can securely connect sites over any IP 97 network, within a service provider's IP network or over the 98 Internet. 100 However, no specific method of accomplishing dynamic routing in an 101 interoperable manner has been defined within existing IPsec 102 standards. This document describes a method by which standard IPsec 103 mechanisms can support the secure exchange of dynamic routing 104 protocols over an IPsec tunnel, and use the routing information to 105 dynamically direct traffic. Most IP routing protocols can be 106 transported natively over standards-compliant IPsec implementations 107 using this method. 109 This method fits in the architecture for provider-provisioned 110 customer premises (CE)-based IPsec VPNs discussed in [CE-BASED]. 112 Three key elements are needed to support dynamic routing in an IPsec 113 VPN environment: 115 1) Agreement between each pair of connected VPN sites to participate 116 in a dynamic routing connection. This is usually accomplished by 117 configuring a dynamic routing protocol on the gateways, and linking 118 it to the IPsec Security Associations involved in the connection. 120 2) Creation of a secure link between each pair of connected VPN 121 sites. This is referred to as a "tunnel link" in this document. Any 122 traffic passing through the "tunnel link" is protected by IPsec. The 123 "tunnel link" will securely transmit any IP traffic sent over it, 124 including routing protocol exchanges. 126 3) Ability to use the "tunnel links" in a manner analogous to simple 127 link connections, and route the traffic between sites over them. 128 Route policy, packet filtering, and firewall capabilities can be 129 applied to the traffic before it is sent over the "tunnel links", 130 delivering overall functionality similar to the use of dedicated 131 encryptors on links between routers. 133 The implementation described in this document uses a transport mode 134 proposal in the Internet Key Exchange (IKE) Quick Mode [RFC-2409] 135 exchange to properly express the restrictions on the traffic in an 136 IPsec-compliant method. However, since the proposal also specifies 137 the use of IP-in-IP [RFC-2003] encapsulation, the gateways actually 138 send all inter-site traffic, including the routing information, in 139 packets that are exactly the same as a tunnel mode packet. It allows 140 the creation of a "tunnel link," which can carry all traffic, 141 including routing updates, within an IPsec-protected VPN tunnel. 143 Some of the perceived limitations of the direct transport of routing 144 protocols within IPsec tunnels are the result of limitations of 145 specific implementations, and not limitations of IPsec itself. In 146 particular, IPsec does not preclude the transport of multicast or 147 broadcast IP traffic. Thus OSPF [RFC-2328], which uses multicast, 148 can be carried over IPsec tunnels and can be used by the IPsec 149 gateways for dynamic routing. 151 3. Routing in IPsec 153 This section discusses the "routing problem" for IPsec, and 154 describes how "tunnel links" can transport normal routing protocols 155 as well as inter-site VPN traffic securely over IPsec. 157 3.1 IPsec background 159 The IP Security Architecture, defined in [RFC-2401], requires IPsec- 160 compliant hosts or gateways to formulate a security policy 161 regulating how they will communicate with other hosts and networks. 162 The standard defines a Security Policy Database (SPD), which much be 163 consulted for every inbound and outbound packet to decide whether 164 that packet can bypass IPsec, or whether the packet requires IPsec 165 processing, or perhaps that the packet must be dropped. 167 When IPsec processing is required, an appropriate IPsec security 168 association (SA) for the packet needs to be found. If a SA does not 169 currently exist, the Internet Key Exchange (IKE) is used to 170 dynamically establish a pair of new SAs (one in each direction). As 171 part of the IKE Quick Mode exchange defined in [RFC-2409] which 172 establishes new IPsec SAs, the IKE peer initiating the Quick Mode 173 exchange may send client identifiers which specify the traffic which 174 will be allowed through the new security associations. The allowable 175 traffic is specified in terms of source and destination addresses, 176 or networks and ranges of addresses, with optional protocol and 177 source and destination ports. 179 This background information is necessary to understand that an IPsec 180 SA, whether operating in tunnel or transport mode, is not normally a 181 "data pipe" through which any and all IP traffic may be sent. The 182 client identifiers determine what is and is not allowed. Moreover, 183 these identifiers are fixed at the time the SA is established. To 184 allow any other traffic to pass, a new SA pair needs to be 185 negotiated. 187 3.2 IPsec routing issues 189 Since the destination address of a packet (along with other 190 selectors) can determine which SA applies to a packet and thus which 191 tunnel the packet may pass through, it is difficult to apply dynamic 192 routing techniques to an IPsec VPN built with standard security 193 associations. If the SAs specify particular networks, then these 194 specifications must override any routing protocol decisions, to 195 comply with IPsec. 197 Support for dynamic routing between IPsec gateways must be added to 198 the IPsec scenario just described, to make configuration of multiple 199 IPsec VPN sites tractable, as opposed to the static routing - the 200 full specification of the local and remote networks - which seems to 201 be implied within IPsec. As described in [TOUCH], there are a 202 number of difficulties with dynamic routing while using standard 203 IPsec approaches, chief of which are: 204 - dynamic updating of SAs with each routing change is unwieldy, and 205 may lead to security issues 206 - the SA database does not by definition contain interface 207 information, and cannot adapt to changes. 209 Another discussion of issues constraining dynamic routing in IPsec 210 VPNs is presented in [WANG]. Although generally useful, it appears 211 to misidentify some implementation-specific issues as IPsec issues, 212 such as IPsec tunnel endpoint attachment and a lack of support for 213 multicast and broadcast traffic. 215 One method of supporting dynamic routing within IPsec would be to 216 negotiate one security association just to pass the routing protocol 217 in question, then once it is known what networks are available on 218 the other side, negotiate separate security associations for each 219 and every network on the fly, potentially dropping some as later 220 routing updates show changes to the configuration. 222 Even if this were done, there is no guarantee that any other 223 implementation would actually use the routing information to 224 establish the necessary dynamic security policy database entries, 225 since the IPsec specifications contain no requirement to support 226 such dynamic changes to security policy. Therefore, this scheme is 227 unlikely to lead to true interoperability, and the additional 228 complexity of managing multiple security associations (and the 229 dynamic policy entries necessary to support them) is a further 230 drawback to this scheme. 232 What is proposed in this document instead is the "tunnel link" 233 approach: one security association pair between the two gateways, 234 which will carry both the routing protocols themselves and all 235 subsequent traffic between the networks on both sides. This requires 236 that the gateway must use the dynamic routing information in 237 addition to the configured SA database entries for routing through 238 the "tunnel links." Of course, any other required security 239 restrictions must be applied by the routing functionality before 240 traffic is allowed to enter the "tunnel links." This approach 241 combines the proven encryption protection of IPsec with the 242 manageability and traffic control capabilities of current routing 243 technology. 245 3.3 "Tunnel Link" Approach 247 The first step to dynamic routing is to set up a bi-directional pair 248 of IPsec SAs between gateways that will allow ALL inter-site traffic 249 to pass through, with IPsec protection. Since this IPsec 250 "connection" can carry all IP traffic, including broadcast and 251 multicast traffic, it is in some ways similar to a link layer 252 connection, and is referred to here as a "tunnel link." A "tunnel 253 link" is a specific "VPN tunnel" [CE-BASED] which uses IPsec privacy 254 (encryption) services, but which does not typically use the IPsec 255 filtering mechanisms (selectors) for traffic; the filtering and 256 routing will be performed by other processes before the traffic is 257 sent through the "tunnel link." 259 A "tunnel link" can be constructed using either IPsec tunnel mode or 260 by using IP-in-IP encapsulation within IPsec transport mode. In 261 either case, the packets meet the protection requirements of tunnel 262 mode packets, as required by the IPsec Architecture [RFC-2401] for 263 traffic between IPsec gateways. 265 Note that modifications to RFC 2401 (RFC2401bis) were proposed by 266 the authors of RFC 2401 in the IPsec Working Group meeting at IETF 267 53. These modifications are expected to include recognition that IP- 268 in-IP encapsulation within transport mode can provide the same 269 protection to traffic between gateways as tunnel mode. However, 270 there is currently no published document other than the WG session 271 presentations as a reference. 273 3.3.1 Tunnel Mode "Tunnel Link" 275 Most standards-compliant IPsec gateway implementations can be 276 configured with interoperable "tunnel links" using tunnel mode. 278 A "tunnel link" can be established by negotiating a tunnel mode SA 279 as follows: 281 In the Quick Mode exchange, specify "wildcards" as client 282 identifiers. This means the Identification Payload [RFC-2407] is 283 set to ID_IPV4_ADDR_SUBNET (value 4) for ID Type, and the network 284 mask of the Identification Data field is set to all zeros 285 (wildcard). Although the IP address in the Identification Data field 286 is irrelevant using the wildcard netmask, 0.0.0.0 should be used for 287 clarity. 289 This might appear to be a good way to begin to solve the IPsec 290 routing issue. However, in practice it has proven to provide limited 291 interoperability among vendors for dynamic routing. This "wildcard" 292 method is typically used by IPsec gateways with no dynamic routing 293 capabilities, to establish a "default route" from a branch site to a 294 central hub site, or for simple site-to-site IPsec connections. An 295 IPsec gateway that is capable of dynamic routing could establish an 296 IPsec tunnel mode "tunnel link" with a non-routing-capable gateway, 297 but would be unable to exchange dynamic routes. This results in a 298 link where the IPsec connection is functional, but traffic cannot 299 flow in both directions due to the inability to exchange routes. One 300 side may see the connection as a default route, while the other 301 would receive no routing information and would send no traffic. 303 3.3.2 Transport Mode Proposal 305 In order to support dynamic routing unambiguously, another 306 alternative is ideal. The signaling method proposed in this document 307 is the use of a particular transport mode proposal. This is 308 discussed in detail in section (3.4.3). 310 It should be noted that [RFC-2401] states in section 4.1 that 311 security gateways must use tunnel mode SAs. In addition to the 312 encapsulation protection of tunnel mode, this is also due to the 313 need to avoid potential problems with fragmentation and reassembly 314 of IPsec packets, and in circumstances where multiple paths exist to 315 the same destination. Thus it is important that the packets in the 316 "tunnel link" be encapsulated and decapsulated in the same manner as 317 tunnel mode packets. A transport mode-based "tunnel link", using IP- 318 in-IP encapsulation can meet these functional requirements of RFC 319 2401. 321 IPsec gateways that are incapable of dynamic routing will have no 322 use for this particular transport mode proposal. Since there is 323 little likelihood that gateways which do not support dynamic routing 324 will be configured to accept this proposal, interoperability among 325 implementations is more straightforward than with the tunnel mode 326 approach. Interoperability between several leading vendors of IPsec 327 gateways has already been demonstrated using this approach. 329 3.3.3 Tunnel vs. Transport as a "Tunnel Link" 331 As discussed in [TOUCH], the transport mode approach offers a 332 cleaner and probably more secure method of separating routing from 333 IPsec processing. With the tunnel mode approach, in order for 334 dynamic routing to work in a hub site (with multiple "tunnel links" 335 to various branch sites, the "wildcard" selectors (which allow ANY 336 traffic to pass through ANY "tunnel link") must be explicitly 337 ignored, in favor of a routing process. This is in contrast to the 338 transport mode approach, where the selectors allow ONLY traffic that 339 has been IP-encapsulated and explicitly passed to the IPsec process. 341 Given the need to separate the routing from the IPsec processing, it 342 appears that the IPsec selectors will provide better security 343 against implementation or configuration errors if the transport mode 344 approach is used. Traffic which "leaks" past the routing process 345 with the tunnel mode approach may go anywhere; traffic which "leaks" 346 past the routing/encapsulation process in the transport mode 347 approach will go nowhere. 349 Further, as noted in [TOUCH] Section 4.6, "IPsec selectors under 350 IIPtran can express the same set of policies as conventional IPsec 351 tunnel mode," so the full range of IPsec selectors can be applied to 352 the inner IP packet. This is not possible with tunnel mode using a 353 wildcard selector. 355 It is not currently feasible for one IPsec gateway to determine if 356 another IPsec gateway can provide the capabilities for dynamic 357 routing over the "tunnel link," when it is constructed using a 358 tunnel mode proposal. Since a number of IPsec implementations can 359 provide a "tunnel link" over tunnel mode connections, but not 360 support dynamic routing over it, an approach should be used which 361 will avoid confusion. 363 In particular, it is more important to have one agreed-upon way to 364 support dynamic routing in IPsec than to support two methods. 365 Negotiation of IPsec parameters between two different 366 implementations will not work unless they both have implemented 367 dynamic routing over a common approach; and if they share a common 368 approach, there is no need for an alternative approach. 370 Given the interoperability limitations of dynamic routing in tunnel 371 mode "tunnel links", and the discussion of the advantages of the 372 transport mode approach above and in [TOUCH], we suggest that the 373 transport mode approach should become the standard method for 374 supporting dynamic routing over IPsec. 376 3.3.4 Routing over a "Tunnel Link" 378 The following discussion applies to any kind of "tunnel link." 380 It should be emphasized that routing information can be carried 381 through a "tunnel link." IPsec gateways can encapsulate normal 382 routing update messages and send them to each other through the 383 "tunnel link." RIP can be propagated with no special considerations. 384 OSPF can treat the "tunnel link" as an unnumbered point-to-point 385 network. BGP can also be implemented. 387 There may be a limitation in some IPsec implementations that does 388 not allow an IPsec tunnel to be recognized as an IP interface. For 389 such an implementation, routing protocols such as RIP and OSPF that 390 are dependent on IP interfaces cannot be defined directly on the 391 IPsec tunnel, and may not be able to send and receive routing 392 information in this way. This is not an IPsec issue, but is 393 implementation-specific. In these cases, additional virtual IP 394 interfaces may be required for terminating IP-in-IP or GRE tunnels, 395 which will use the IPsec transport mode SA. 397 A "tunnel link" essentially provides a connection for any IP traffic 398 between IPsec gateways. The gateways must have the ability to use 399 them for dynamic routing. The gateway implementation must coordinate 400 the application of routing updates with other security restrictions 401 expressed in IPsec or configured by other methods. A description of 402 these implementation details is beyond the scope of this document, 403 since it depends intimately on the internal architecture of each 404 IPsec gateway. However, interoperability of dynamic routing between 405 most IPsec gateway implementations that provide routing capabilities 406 should be feasible using the method described in this document. 408 3.4 Methods of Establishing a "Tunnel Link" 410 One crucial issue is how to express in IKE Quick Mode the desire to 411 establish a "tunnel link" security association which allows for 412 dynamic routing, while at the same time ensuring that various IPsec 413 gateway implementations can still interoperate with "static" (SA- 414 based) routing, and not cause confusion between the two (such as 415 another implementation trying to negotiate something which the 416 security gateway would interpret as being capable of dynamic 417 routing). 419 Three approaches are discussed below. The third method is the method 420 suggested for adoption. 422 3.4.1 Method 1 - Vendor ID compatibility 424 A specific IKE Vendor ID payload can be used on both sides in the 425 Phase I negotiation to ensure that both peers support this method, 426 and thus would be capable of allowing dynamic routing through a 427 tunnel. During Quick Mode, assuming compatible gateways on both 428 sides, send a Quick Mode proposal that is understood by both sides 429 to signal the creation of the tunnel link. 431 For example, a tunnel mode proposal could be sent without client 432 identifier payloads. Normally, negotiating tunnel mode security 433 associations without client identifiers implies that only the tunnel 434 endpoints (gateways) may communicate through the resulting security 435 association pair. However, when using this vendor-specific ID, this 436 use of Quick Mode client identifiers (or actually the lack of them) 437 would be interpreted as defining a "tunnel link." This approach 438 could be acceptable as a known proprietary solution. 440 The biggest problem with this method is the reliance on a Quick Mode 441 proposal that can easily be interpreted differently by another 442 implementation. Also, the use of the Vendor ID payload is 443 problematic, as it then means that either all implementations would 444 have to use the specific Vendor ID. It is far better to use a Quick 445 Mode proposal that will be unambiguous to all implementations, even 446 those that do not support dynamic routing. Method 3, described 447 below, solves these issues. 449 3.4.2 Method 2 - Notify Message or new IPsec message 451 An alternative method might use an IPsec Notify Message, a newly- 452 specified IPsec extension, or perhaps a new Encapsulation Mode value 453 to communicate the intent to set up the "tunnel link." This 454 approach is likely to be non-interoperable for some period, and has 455 not been explored in detail. 457 3.4.3 Method 3 - Transport Mode with IP-in-IP 459 An interoperable approach must allow the Quick Mode proposal to 460 express a request for a "tunnel link" connection with dynamic 461 routing, while limiting the possibility of misinterpretation by an 462 implementation that does not support dynamic routing. It uses a 463 transport mode proposal with client identifiers and protocol 464 identification to express the same capabilities as the tunnel mode 465 "tunnel link" discussed above. 467 A more general approach to this method is discussed in detail in 468 [TOUCH], and labeled "IIPtran." 470 We assume that the initial ISAKMP Security Association (SA) has 471 already been established in Phase 1 between the gateways. This 472 ISAKMP SA is used to protect the negotiations for Phase 2, in which 473 a Quick Mode negotiation establishes the IPsec SA. 475 This Quick Mode proposal should specify a transport mode SA, with 476 client identifiers consisting of the gateway addresses, and a 477 protocol value of 4, signifying IP-in-IP. 479 The traffic sent will actually be constructed exactly the same as 480 IPsec tunnel mode traffic, but the SA traffic restrictions will be 481 evaluated according to the proposal for transport mode. 483 Since transport mode identifiers are applied to the outermost IP 484 header, the syntax is correct for expressing the "restrictions" on 485 the traffic being passed. IPsec tunnel mode packets use the gateway 486 addresses as the source and destination addresses. IPsec tunnel mode 487 packets are constructed such that the "next payload" field of either 488 AH or ESP is always IP-in-IP (4), so the IPsec packets passed 489 through are consistent with the transport mode restrictions placed 490 by the client identifiers. 492 Essentially, this method places no restrictions on the inner IP 493 header, but it does specify, through its use of IP-in-IP as a 494 transport mode protocol, that there will always be an inner IP 495 header as there is in "normal" tunnel mode. 497 As noted in [TOUCH], although the packets themselves contain no 498 differentiation as to whether they are tunnel mode or are transport 499 mode carrying IP-in-IP, there are differences in the way that 500 incoming transport and tunnel mode decapsulation is handled. For the 501 method described in this document to work effectively, the receiver 502 must implement a processing rule for type 4 (IP-in-IP) packets so 503 that they will always be decapsulated upon receipt. That is, they 504 must be processed as in tunnel mode. This can be accomplished 505 either by explicitly configuring the IP-in-IP encapsulation as a 506 tunnel interface, or by other implementation-specific mechanisms. 508 4. Other considerations 510 4.1 Interoperability Issues 512 Implementations that use this method should provide the following 513 functionality: 514 a) be able to negotiate the Quick Mode proposal for the "tunnel 515 link" described in this document in section 3.4.3 516 b) be able to send, receive, and appropriately process the routing 517 messages over the "tunnel links" 518 c) be able to use the routing information to direct traffic to the 519 appropriate "tunnel link", using the routes which have been learned 520 d) be able to apply configured route policies to the learned routes 521 e) be able to apply packet filtering, and (optionally) firewall 522 capabilities to the traffic before it is sent over the "tunnel 523 link." 525 This method of establishing the "tunnel link" should be restricted 526 to this specific use. The only purpose for sending this proposal 527 should be to advertise the gateway's ability to support dynamic 528 routing. This Quick Mode proposal should be rejected by an 529 implementation that does not support dynamic routing in this method. 531 There is no current alternate interpretation of the client 532 identifiers with IP-in-IP that would cause confusion to 533 implementations that do not support dynamic routing, so it should be 534 safe to use even without any requirement to have cooperating Vendor 535 IDs or other signaling. 537 There may be a limitation in an IPsec implementation that does not 538 allow an IPsec tunnel to be recognized as an IP interface. For such 539 an implementation, routing protocols such as RIP and OSPF that are 540 dependent on IP interfaces cannot be defined directly on the IPsec 541 tunnel. An implementation of this type may not be able to use this 542 method for RIP and OSPF, but it can work with BGP. It may have to 543 use another layer of encapsulation, such as GRE [RFC-2784](which can 544 support RIP and OSPF), on top of the IPSec tunnel, or over a 545 transport mode connection. This introduces additional configuration 546 as well as additional packet header overhead, not just for the 547 routing packets, but also for all data that traverses the tunnel. 548 This is not an IPsec issue, but may depend on a specific 549 implementation. Methods of using GRE for this purpose are discussed 550 in [KHETAN]. 552 4.2 Scalability 554 The use of a single IPsec SA per "tunnel link," as described in this 555 document, can significantly increase the number of IPsec VPN 556 connections supported per gateway, compared to alternatives. Since 557 IPsec normally requires a separate IPsec SA per subnet or IP address 558 range, there can potentially be a large number of SAs needed to 559 express the normal routing of multiple subnets between two VPN 560 sites. For the hub sites of large VPNs, this can even drive 561 requirements to use multiple gateways to support all the 562 connections. Thus using a single SA per connection can simplify VPN 563 design as well as improve system performance. 565 One alternative approach to support dynamic routing which has been 566 proposed using GRE [KHETAN] requires maintaining both a GRE tunnel 567 and an IPsec SA per VPN connection, leading to higher overhead and 568 potentially lower performance than the method described in this 569 document. 571 4.3 OSPF Routing over a "Tunnel Link" 573 Since the IPsec gateways will in most cases not have their 574 interfaces in the same subnet, OSPF must be configured to treat the 575 "tunnel link" as an unnumbered point-to-point network. 577 5. Security Considerations 579 This document describes a method of dynamic routing in which the 580 gateway device can use standard routing functionality to perform 581 dynamic routing decisions. Packets are assigned to a specific 582 "tunnel link" SA based on the packet's destination address, using 583 routing information that has been dynamically learned. Each "tunnel 584 link" provides standard IPsec protection for all traffic. All 585 traffic carried in the "tunnel link" between the IPsec gateways is 586 encapsulated in a packet which is identical to a tunnel mode packet, 587 as required by the Security Architecture for IP [RFC-2401]. 589 The use of a "tunnel link" may be controversial at first glance, 590 because traffic control is performed by a routing function rather 591 than through detailed negotiation of multiple IPsec security 592 associations. However, it should be noted that the "tunnel link" in 593 this case actually expresses the desire of the VPN operator for a 594 connection providing trusted encryption and security across a public 595 network, while allowing manageable dynamic routing within the 596 protection afforded by IPsec. It does not violate the letter or the 597 spirit of IPsec. 599 It should be noted that alternative proposals for use of 600 encapsulation over IPsec such as [KHETAN] are actually equivalent in 601 terms of IPsec security, in that they use some routing functionality 602 to determine the desired path, then hide the characteristics of the 603 data within an encapsulated IP packet format, so that most IPsec 604 selectors of the internal packet are not visible. 606 Dynamic routing opens possibilities for misdirection of traffic, due 607 to transient conditions or intentional misconfiguration. Since all 608 routing information will be coming from other trusted VPN sites, the 609 security exposure from this source is equivalent to any private 610 network or VPN that exchanges routing information. The internal 611 routing functionality SHOULD provide support for routing policies to 612 manage the learned routes, as well as traffic filtering. 614 All VPN traffic crossing the public network between the IPsec 615 gateways will be protected by IPsec using the method described in 616 this document. Packets that are identical to tunnel mode are used, 617 although the creation of the "tunnel link" is signaled by a proposal 618 for a transport mode SA. Appropriate levels of encryption should be 619 chosen, commensurate with the level of confidentiality required. 621 6. Summary for Sub-IP Area 623 6.1 Summary 625 The PPVPN WG currently supports three types of VPNs: Provider 626 Provisioned Network Based Layer 3 VPNs, Provider Provisioned Network 627 Based Layer 2 VPNs and Provider Provisioned Customer-Edge Based 628 VPNs. This draft discusses the use of standard IPsec capabilities to 629 support routing for CE-based IPSec VPNs. 631 6.2 Where does it fit in the picture of the Sub-IP work? 633 This work fits in the PPVPN box. Although this work is based on 634 IPsec, it is an application of IPsec, and does not involve changes 635 to IPsec. Therefore it is not considered within the IPsec Working 636 Group. Exchange of dynamic routing information between CE-based VPN 637 devices provisioned by service providers is a key enabling 638 technology for allowing scalable IPsec VPN deployments. 640 6.3 Why is it targeted at this Working Group? 642 This document describes how standard IPsec mechanisms can support 643 the tunneling of IP multicast and broadcast packets, so that IPsec 644 VPN tunnels can support dynamic routing protocols over the tunnel. 646 Under the current PPVPN WG charter, Provider Provisioned CE-based 647 VPNs fits the scope of the WG, as stated from the following charter 648 extract: "This working group is responsible for defining and 649 specifying a limited number of sets of solutions for supporting 650 provider-provisioned virtual private networks (PPVPNs). The work 651 effort will include the development of a framework document, a 652 service requirements document and several individual technical 653 approach documents that group technologies together to specify 654 specific VPN service offerings. The framework will define the common 655 components and pieces that are needed to build and deploy a PPVPN. 656 Deployment scenarios will include provider-managed VPN components 657 located on customer premises." 659 6.4 Justification 660 This draft is justified since it targets the routing issue of CE- 661 based VPNs, which are identified as a specific type of PPVPNs both 662 in the WG charter and the general framework I-D. CE-based VPN has 663 specific characteristics and operational requirements, including 664 routing support. 666 7. Document Change History 668 Version -01: 669 - Added change history section 670 - Modified title to remove "signal," adjusted text to change 671 emphasis from the concept of signaling. We felt that there is not a 672 specific need to signal the ability to support routing protocols 673 since routing protocols are typically configured on the nodes, and 674 IPsec VPN tunnels should be considered similar to other links, not 675 requiring additional signaling for this purpose. 676 - Clarified "tunnel link" terminology with respect to "VPN tunnel", 677 to align with [CE-BASED]. 678 - Added mention of Steve Kent's plans for RFC2401bis. 679 - Updated references. 680 - Added section discussing tunnel mode vs. transport mode for 681 "tunnel links". 683 8. References 685 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [CE-BASED] De Clercq, J., Paridaens, O., Iyer, M., Krywaniuk, A., 688 and Wang, C., "An Architecture for Provider Provisioned CE-based 689 Virtual Private Networks using IPsec", draft-ietf-ppvpn-ce-based- 690 02.txt, work in progress, May 2002. 691 [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key Exchange 692 (IKE)", RFC 2409, November 1998. 693 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 694 October 1996. 695 [RFC-2328] Moy, J., "OSPF Version 2", RFC 2328, STD 54, April 1998. 696 [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for the 697 Internet Protocol", RFC 2401, November 1998. 698 [TOUCH] Touch, J., and Eggert, L., "Use of IPsec Transport Mode for 699 Virtual Networks," draft-touch-ipsec-vpn-04.txt, work in 700 progress, June 2002. 701 [WANG] Wang, C., Beadles, M., and Khetan, A., "Routing Support in 702 CE-based IPsec VPNs," draft-wang-cevpn-routing-00.txt, work in 703 progress, October 2001. 704 [RFC-2407] Piper, D., "The Internet IP Security Domain of 705 Interpretation for ISAKMP", RFC 2407, November 1998. 706 [RFC-2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and Traina, 707 P., "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 709 [KHETAN] Khetan, A., Wang, C., Beadles, M., French, L., and Vyncke, 710 E., "Use of GRE for routing support in IPsec VPNs", draft-khetan- 711 sp-greipsec-00.txt, work in progress, January 2002. 713 9. Acknowledgements 715 We would like to acknowledge the helpful comments and contributions 716 of the following individuals: Larry DiBurro, Haixiang He, Bob Lee, 717 Shawn Mamros (who implemented this approach), and Simon McCormack. 719 10. Authors' Addresses 721 Paul Knight Bryan Gleeson 722 Nortel Networks Tahoe Networks 723 600 Technology Park Drive 3052 Orchard Drive 724 Billerica, MA. 01821 USA San Jose, CA 95134 USA 725 paknight@nortelnetworks.com bryan@tahoenetworks.com 726 +1 (978) 288 6414 728 Full Copyright Statement 730 Copyright (C) The Internet Society (2001). All Rights Reserved. This 731 document and translations of it may be copied and furnished to 732 others, and derivative works that comment on or otherwise explain it 733 or assist in its implementation may be prepared, copied, published 734 and distributed, in whole or in part, without restriction of any 735 kind, provided that the above copyright notice and this paragraph 736 are included on all such copies and derivative works. However, this 737 document itself may not be modified in any way, such as by removing 738 the copyright notice or references to the Internet Society or other 739 Internet organizations, except as needed for the purpose of 740 developing Internet standards in which case the procedures for 741 copyrights defined in the Internet Standards process must be 742 followed, or as required to translate it into languages other than 743 English. 744 The limited permissions granted above are perpetual and will not be 745 revoked by the Internet Society or its successors or assigns.