Provider Provisioned VPN Working Group Paul Knight Internet Draft Nortel Networks draft-knight-ppvpn-ipsec-dynroute-01.txt Expires: January 2003 Bryan Gleeson Tahoe Networks July 2002 A Method to Provide Dynamic Routing in IPsec VPNs Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Exchange of routing information between IPsec security gateways, using standard routing protocols across IPsec tunnels, can be a straightforward operation. Using the routing information to choose the proper path is also straightforward, when routing is functionally separated from the IPsec gateway operation. One of the most significant obstacles to widespread implementation of dynamic routing in IPsec VPNs has been agreement on a way to exchange and use the routing information. This document describes a simple and secure method of exchanging dynamic routing information between IPsec security gateways, using standard IPsec messages. This method is currently in use in a large number of installations, and has been demonstrated to be interoperable across several IPsec implementations from different vendors. Knight & Gleeson Expires January 2003 [Page 1] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Conventions used in this document...............................2 2. Overview........................................................2 3. Routing in IPsec...............................................4 3.1 IPsec background...............................................4 3.2 IPsec routing issues...........................................4 3.3 "Tunnel Link" Approach.........................................5 3.3.1 Tunnel Mode "Tunnel Link"....................................6 3.3.2 Transport Mode Proposal......................................7 3.3.3 Tunnel vs. Transport as a "Tunnel Link"......................7 3.3.4 Routing over a "Tunnel Link".................................8 3.4 Methods of Establishing a "Tunnel Link"........................9 3.4.1 Method 1 - Vendor ID compatibility...........................9 3.4.2 Method 2 - Notify Message or new IPsec message...............9 3.4.3 Method 3 - Transport Mode with IP-in-IP.....................10 4. Other considerations...........................................11 4.1 Interoperability Issues.......................................11 4.2 Scalability...................................................11 4.3 OSPF Routing over a "Tunnel Link".............................12 5. Security Considerations........................................12 6. Summary for Sub-IP Area........................................13 6.1 Summary.......................................................13 6.2 Where does it fit in the picture of the Sub-IP work?..........13 6.3 Why is it targeted at this Working Group?.....................13 6.4 Justification.................................................13 7. Document Change History........................................14 8. References.....................................................14 9. Acknowledgements...............................................15 10. Authors' Addresses............................................15 Full Copyright Statement..........................................15 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Overview Dynamic exchange of routing information between the various sites of a Virtual Private Network (VPN) can significantly simplify the management of the VPN. Without dynamic routing, it is difficult to configure a large number of routes correctly and in a timely manner. Knight & Gleeson Expires January 2003 [Page 2] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 It is even more difficult to set up load balancing and failover when the configuration is static. IPsec offers tremendous promise as a VPN technology, since it can securely connect sites over any IP network, within a service provider's IP network or over the Internet. However, no specific method of accomplishing dynamic routing in an interoperable manner has been defined within existing IPsec standards. This document describes a method by which standard IPsec mechanisms can support the secure exchange of dynamic routing protocols over an IPsec tunnel, and use the routing information to dynamically direct traffic. Most IP routing protocols can be transported natively over standards-compliant IPsec implementations using this method. This method fits in the architecture for provider-provisioned customer premises (CE)-based IPsec VPNs discussed in [CE-BASED]. Three key elements are needed to support dynamic routing in an IPsec VPN environment: 1) Agreement between each pair of connected VPN sites to participate in a dynamic routing connection. This is usually accomplished by configuring a dynamic routing protocol on the gateways, and linking it to the IPsec Security Associations involved in the connection. 2) Creation of a secure link between each pair of connected VPN sites. This is referred to as a "tunnel link" in this document. Any traffic passing through the "tunnel link" is protected by IPsec. The "tunnel link" will securely transmit any IP traffic sent over it, including routing protocol exchanges. 3) Ability to use the "tunnel links" in a manner analogous to simple link connections, and route the traffic between sites over them. Route policy, packet filtering, and firewall capabilities can be applied to the traffic before it is sent over the "tunnel links", delivering overall functionality similar to the use of dedicated encryptors on links between routers. The implementation described in this document uses a transport mode proposal in the Internet Key Exchange (IKE) Quick Mode [RFC-2409] exchange to properly express the restrictions on the traffic in an IPsec-compliant method. However, since the proposal also specifies the use of IP-in-IP [RFC-2003] encapsulation, the gateways actually send all inter-site traffic, including the routing information, in packets that are exactly the same as a tunnel mode packet. It allows the creation of a "tunnel link," which can carry all traffic, including routing updates, within an IPsec-protected VPN tunnel. Some of the perceived limitations of the direct transport of routing protocols within IPsec tunnels are the result of limitations of specific implementations, and not limitations of IPsec itself. In Knight & Gleeson Expires January 2003 [Page 3] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 particular, IPsec does not preclude the transport of multicast or broadcast IP traffic. Thus OSPF [RFC-2328], which uses multicast, can be carried over IPsec tunnels and can be used by the IPsec gateways for dynamic routing. 3. Routing in IPsec This section discusses the "routing problem" for IPsec, and describes how "tunnel links" can transport normal routing protocols as well as inter-site VPN traffic securely over IPsec. 3.1 IPsec background The IP Security Architecture, defined in [RFC-2401], requires IPsec- compliant hosts or gateways to formulate a security policy regulating how they will communicate with other hosts and networks. The standard defines a Security Policy Database (SPD), which much be consulted for every inbound and outbound packet to decide whether that packet can bypass IPsec, or whether the packet requires IPsec processing, or perhaps that the packet must be dropped. When IPsec processing is required, an appropriate IPsec security association (SA) for the packet needs to be found. If a SA does not currently exist, the Internet Key Exchange (IKE) is used to dynamically establish a pair of new SAs (one in each direction). As part of the IKE Quick Mode exchange defined in [RFC-2409] which establishes new IPsec SAs, the IKE peer initiating the Quick Mode exchange may send client identifiers which specify the traffic which will be allowed through the new security associations. The allowable traffic is specified in terms of source and destination addresses, or networks and ranges of addresses, with optional protocol and source and destination ports. This background information is necessary to understand that an IPsec SA, whether operating in tunnel or transport mode, is not normally a "data pipe" through which any and all IP traffic may be sent. The client identifiers determine what is and is not allowed. Moreover, these identifiers are fixed at the time the SA is established. To allow any other traffic to pass, a new SA pair needs to be negotiated. 3.2 IPsec routing issues Since the destination address of a packet (along with other selectors) can determine which SA applies to a packet and thus which tunnel the packet may pass through, it is difficult to apply dynamic routing techniques to an IPsec VPN built with standard security associations. If the SAs specify particular networks, then these specifications must override any routing protocol decisions, to comply with IPsec. Knight & Gleeson Expires January 2003 [Page 4] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 Support for dynamic routing between IPsec gateways must be added to the IPsec scenario just described, to make configuration of multiple IPsec VPN sites tractable, as opposed to the static routing - the full specification of the local and remote networks - which seems to be implied within IPsec. As described in [TOUCH], there are a number of difficulties with dynamic routing while using standard IPsec approaches, chief of which are: - dynamic updating of SAs with each routing change is unwieldy, and may lead to security issues - the SA database does not by definition contain interface information, and cannot adapt to changes. Another discussion of issues constraining dynamic routing in IPsec VPNs is presented in [WANG]. Although generally useful, it appears to misidentify some implementation-specific issues as IPsec issues, such as IPsec tunnel endpoint attachment and a lack of support for multicast and broadcast traffic. One method of supporting dynamic routing within IPsec would be to negotiate one security association just to pass the routing protocol in question, then once it is known what networks are available on the other side, negotiate separate security associations for each and every network on the fly, potentially dropping some as later routing updates show changes to the configuration. Even if this were done, there is no guarantee that any other implementation would actually use the routing information to establish the necessary dynamic security policy database entries, since the IPsec specifications contain no requirement to support such dynamic changes to security policy. Therefore, this scheme is unlikely to lead to true interoperability, and the additional complexity of managing multiple security associations (and the dynamic policy entries necessary to support them) is a further drawback to this scheme. What is proposed in this document instead is the "tunnel link" approach: one security association pair between the two gateways, which will carry both the routing protocols themselves and all subsequent traffic between the networks on both sides. This requires that the gateway must use the dynamic routing information in addition to the configured SA database entries for routing through the "tunnel links." Of course, any other required security restrictions must be applied by the routing functionality before traffic is allowed to enter the "tunnel links." This approach combines the proven encryption protection of IPsec with the manageability and traffic control capabilities of current routing technology. 3.3 "Tunnel Link" Approach The first step to dynamic routing is to set up a bi-directional pair of IPsec SAs between gateways that will allow ALL inter-site traffic Knight & Gleeson Expires January 2003 [Page 5] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 to pass through, with IPsec protection. Since this IPsec "connection" can carry all IP traffic, including broadcast and multicast traffic, it is in some ways similar to a link layer connection, and is referred to here as a "tunnel link." A "tunnel link" is a specific "VPN tunnel" [CE-BASED] which uses IPsec privacy (encryption) services, but which does not typically use the IPsec filtering mechanisms (selectors) for traffic; the filtering and routing will be performed by other processes before the traffic is sent through the "tunnel link." A "tunnel link" can be constructed using either IPsec tunnel mode or by using IP-in-IP encapsulation within IPsec transport mode. In either case, the packets meet the protection requirements of tunnel mode packets, as required by the IPsec Architecture [RFC-2401] for traffic between IPsec gateways. Note that modifications to RFC 2401 (RFC2401bis) were proposed by the authors of RFC 2401 in the IPsec Working Group meeting at IETF 53. These modifications are expected to include recognition that IP- in-IP encapsulation within transport mode can provide the same protection to traffic between gateways as tunnel mode. However, there is currently no published document other than the WG session presentations as a reference. 3.3.1 Tunnel Mode "Tunnel Link" Most standards-compliant IPsec gateway implementations can be configured with interoperable "tunnel links" using tunnel mode. A "tunnel link" can be established by negotiating a tunnel mode SA as follows: In the Quick Mode exchange, specify "wildcards" as client identifiers. This means the Identification Payload [RFC-2407] is set to ID_IPV4_ADDR_SUBNET (value 4) for ID Type, and the network mask of the Identification Data field is set to all zeros (wildcard). Although the IP address in the Identification Data field is irrelevant using the wildcard netmask, 0.0.0.0 should be used for clarity. This might appear to be a good way to begin to solve the IPsec routing issue. However, in practice it has proven to provide limited interoperability among vendors for dynamic routing. This "wildcard" method is typically used by IPsec gateways with no dynamic routing capabilities, to establish a "default route" from a branch site to a central hub site, or for simple site-to-site IPsec connections. An IPsec gateway that is capable of dynamic routing could establish an IPsec tunnel mode "tunnel link" with a non-routing-capable gateway, but would be unable to exchange dynamic routes. This results in a link where the IPsec connection is functional, but traffic cannot flow in both directions due to the inability to exchange routes. One Knight & Gleeson Expires January 2003 [Page 6] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 side may see the connection as a default route, while the other would receive no routing information and would send no traffic. 3.3.2 Transport Mode Proposal In order to support dynamic routing unambiguously, another alternative is ideal. The signaling method proposed in this document is the use of a particular transport mode proposal. This is discussed in detail in section (3.4.3). It should be noted that [RFC-2401] states in section 4.1 that security gateways must use tunnel mode SAs. In addition to the encapsulation protection of tunnel mode, this is also due to the need to avoid potential problems with fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths exist to the same destination. Thus it is important that the packets in the "tunnel link" be encapsulated and decapsulated in the same manner as tunnel mode packets. A transport mode-based "tunnel link", using IP- in-IP encapsulation can meet these functional requirements of RFC 2401. IPsec gateways that are incapable of dynamic routing will have no use for this particular transport mode proposal. Since there is little likelihood that gateways which do not support dynamic routing will be configured to accept this proposal, interoperability among implementations is more straightforward than with the tunnel mode approach. Interoperability between several leading vendors of IPsec gateways has already been demonstrated using this approach. 3.3.3 Tunnel vs. Transport as a "Tunnel Link" As discussed in [TOUCH], the transport mode approach offers a cleaner and probably more secure method of separating routing from IPsec processing. With the tunnel mode approach, in order for dynamic routing to work in a hub site (with multiple "tunnel links" to various branch sites, the "wildcard" selectors (which allow ANY traffic to pass through ANY "tunnel link") must be explicitly ignored, in favor of a routing process. This is in contrast to the transport mode approach, where the selectors allow ONLY traffic that has been IP-encapsulated and explicitly passed to the IPsec process. Given the need to separate the routing from the IPsec processing, it appears that the IPsec selectors will provide better security against implementation or configuration errors if the transport mode approach is used. Traffic which "leaks" past the routing process with the tunnel mode approach may go anywhere; traffic which "leaks" past the routing/encapsulation process in the transport mode approach will go nowhere. Further, as noted in [TOUCH] Section 4.6, "IPsec selectors under IIPtran can express the same set of policies as conventional IPsec Knight & Gleeson Expires January 2003 [Page 7] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 tunnel mode," so the full range of IPsec selectors can be applied to the inner IP packet. This is not possible with tunnel mode using a wildcard selector. It is not currently feasible for one IPsec gateway to determine if another IPsec gateway can provide the capabilities for dynamic routing over the "tunnel link," when it is constructed using a tunnel mode proposal. Since a number of IPsec implementations can provide a "tunnel link" over tunnel mode connections, but not support dynamic routing over it, an approach should be used which will avoid confusion. In particular, it is more important to have one agreed-upon way to support dynamic routing in IPsec than to support two methods. Negotiation of IPsec parameters between two different implementations will not work unless they both have implemented dynamic routing over a common approach; and if they share a common approach, there is no need for an alternative approach. Given the interoperability limitations of dynamic routing in tunnel mode "tunnel links", and the discussion of the advantages of the transport mode approach above and in [TOUCH], we suggest that the transport mode approach should become the standard method for supporting dynamic routing over IPsec. 3.3.4 Routing over a "Tunnel Link" The following discussion applies to any kind of "tunnel link." It should be emphasized that routing information can be carried through a "tunnel link." IPsec gateways can encapsulate normal routing update messages and send them to each other through the "tunnel link." RIP can be propagated with no special considerations. OSPF can treat the "tunnel link" as an unnumbered point-to-point network. BGP can also be implemented. There may be a limitation in some IPsec implementations that does not allow an IPsec tunnel to be recognized as an IP interface. For such an implementation, routing protocols such as RIP and OSPF that are dependent on IP interfaces cannot be defined directly on the IPsec tunnel, and may not be able to send and receive routing information in this way. This is not an IPsec issue, but is implementation-specific. In these cases, additional virtual IP interfaces may be required for terminating IP-in-IP or GRE tunnels, which will use the IPsec transport mode SA. A "tunnel link" essentially provides a connection for any IP traffic between IPsec gateways. The gateways must have the ability to use them for dynamic routing. The gateway implementation must coordinate the application of routing updates with other security restrictions expressed in IPsec or configured by other methods. A description of these implementation details is beyond the scope of this document, Knight & Gleeson Expires January 2003 [Page 8] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 since it depends intimately on the internal architecture of each IPsec gateway. However, interoperability of dynamic routing between most IPsec gateway implementations that provide routing capabilities should be feasible using the method described in this document. 3.4 Methods of Establishing a "Tunnel Link" One crucial issue is how to express in IKE Quick Mode the desire to establish a "tunnel link" security association which allows for dynamic routing, while at the same time ensuring that various IPsec gateway implementations can still interoperate with "static" (SA- based) routing, and not cause confusion between the two (such as another implementation trying to negotiate something which the security gateway would interpret as being capable of dynamic routing). Three approaches are discussed below. The third method is the method suggested for adoption. 3.4.1 Method 1 - Vendor ID compatibility A specific IKE Vendor ID payload can be used on both sides in the Phase I negotiation to ensure that both peers support this method, and thus would be capable of allowing dynamic routing through a tunnel. During Quick Mode, assuming compatible gateways on both sides, send a Quick Mode proposal that is understood by both sides to signal the creation of the tunnel link. For example, a tunnel mode proposal could be sent without client identifier payloads. Normally, negotiating tunnel mode security associations without client identifiers implies that only the tunnel endpoints (gateways) may communicate through the resulting security association pair. However, when using this vendor-specific ID, this use of Quick Mode client identifiers (or actually the lack of them) would be interpreted as defining a "tunnel link." This approach could be acceptable as a known proprietary solution. The biggest problem with this method is the reliance on a Quick Mode proposal that can easily be interpreted differently by another implementation. Also, the use of the Vendor ID payload is problematic, as it then means that either all implementations would have to use the specific Vendor ID. It is far better to use a Quick Mode proposal that will be unambiguous to all implementations, even those that do not support dynamic routing. Method 3, described below, solves these issues. 3.4.2 Method 2 - Notify Message or new IPsec message An alternative method might use an IPsec Notify Message, a newly- specified IPsec extension, or perhaps a new Encapsulation Mode value to communicate the intent to set up the "tunnel link." This Knight & Gleeson Expires January 2003 [Page 9] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 approach is likely to be non-interoperable for some period, and has not been explored in detail. 3.4.3 Method 3 - Transport Mode with IP-in-IP An interoperable approach must allow the Quick Mode proposal to express a request for a "tunnel link" connection with dynamic routing, while limiting the possibility of misinterpretation by an implementation that does not support dynamic routing. It uses a transport mode proposal with client identifiers and protocol identification to express the same capabilities as the tunnel mode "tunnel link" discussed above. A more general approach to this method is discussed in detail in [TOUCH], and labeled "IIPtran." We assume that the initial ISAKMP Security Association (SA) has already been established in Phase 1 between the gateways. This ISAKMP SA is used to protect the negotiations for Phase 2, in which a Quick Mode negotiation establishes the IPsec SA. This Quick Mode proposal should specify a transport mode SA, with client identifiers consisting of the gateway addresses, and a protocol value of 4, signifying IP-in-IP. The traffic sent will actually be constructed exactly the same as IPsec tunnel mode traffic, but the SA traffic restrictions will be evaluated according to the proposal for transport mode. Since transport mode identifiers are applied to the outermost IP header, the syntax is correct for expressing the "restrictions" on the traffic being passed. IPsec tunnel mode packets use the gateway addresses as the source and destination addresses. IPsec tunnel mode packets are constructed such that the "next payload" field of either AH or ESP is always IP-in-IP (4), so the IPsec packets passed through are consistent with the transport mode restrictions placed by the client identifiers. Essentially, this method places no restrictions on the inner IP header, but it does specify, through its use of IP-in-IP as a transport mode protocol, that there will always be an inner IP header as there is in "normal" tunnel mode. As noted in [TOUCH], although the packets themselves contain no differentiation as to whether they are tunnel mode or are transport mode carrying IP-in-IP, there are differences in the way that incoming transport and tunnel mode decapsulation is handled. For the method described in this document to work effectively, the receiver must implement a processing rule for type 4 (IP-in-IP) packets so that they will always be decapsulated upon receipt. That is, they must be processed as in tunnel mode. This can be accomplished Knight & Gleeson Expires January 2003 [Page 10] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 either by explicitly configuring the IP-in-IP encapsulation as a tunnel interface, or by other implementation-specific mechanisms. 4. Other considerations 4.1 Interoperability Issues Implementations that use this method should provide the following functionality: a) be able to negotiate the Quick Mode proposal for the "tunnel link" described in this document in section 3.4.3 b) be able to send, receive, and appropriately process the routing messages over the "tunnel links" c) be able to use the routing information to direct traffic to the appropriate "tunnel link", using the routes which have been learned d) be able to apply configured route policies to the learned routes e) be able to apply packet filtering, and (optionally) firewall capabilities to the traffic before it is sent over the "tunnel link." This method of establishing the "tunnel link" should be restricted to this specific use. The only purpose for sending this proposal should be to advertise the gateway's ability to support dynamic routing. This Quick Mode proposal should be rejected by an implementation that does not support dynamic routing in this method. There is no current alternate interpretation of the client identifiers with IP-in-IP that would cause confusion to implementations that do not support dynamic routing, so it should be safe to use even without any requirement to have cooperating Vendor IDs or other signaling. There may be a limitation in an IPsec implementation that does not allow an IPsec tunnel to be recognized as an IP interface. For such an implementation, routing protocols such as RIP and OSPF that are dependent on IP interfaces cannot be defined directly on the IPsec tunnel. An implementation of this type may not be able to use this method for RIP and OSPF, but it can work with BGP. It may have to use another layer of encapsulation, such as GRE [RFC-2784](which can support RIP and OSPF), on top of the IPSec tunnel, or over a transport mode connection. This introduces additional configuration as well as additional packet header overhead, not just for the routing packets, but also for all data that traverses the tunnel. This is not an IPsec issue, but may depend on a specific implementation. Methods of using GRE for this purpose are discussed in [KHETAN]. 4.2 Scalability The use of a single IPsec SA per "tunnel link," as described in this document, can significantly increase the number of IPsec VPN connections supported per gateway, compared to alternatives. Since Knight & Gleeson Expires January 2003 [Page 11] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 IPsec normally requires a separate IPsec SA per subnet or IP address range, there can potentially be a large number of SAs needed to express the normal routing of multiple subnets between two VPN sites. For the hub sites of large VPNs, this can even drive requirements to use multiple gateways to support all the connections. Thus using a single SA per connection can simplify VPN design as well as improve system performance. One alternative approach to support dynamic routing which has been proposed using GRE [KHETAN] requires maintaining both a GRE tunnel and an IPsec SA per VPN connection, leading to higher overhead and potentially lower performance than the method described in this document. 4.3 OSPF Routing over a "Tunnel Link" Since the IPsec gateways will in most cases not have their interfaces in the same subnet, OSPF must be configured to treat the "tunnel link" as an unnumbered point-to-point network. 5. Security Considerations This document describes a method of dynamic routing in which the gateway device can use standard routing functionality to perform dynamic routing decisions. Packets are assigned to a specific "tunnel link" SA based on the packet's destination address, using routing information that has been dynamically learned. Each "tunnel link" provides standard IPsec protection for all traffic. All traffic carried in the "tunnel link" between the IPsec gateways is encapsulated in a packet which is identical to a tunnel mode packet, as required by the Security Architecture for IP [RFC-2401]. The use of a "tunnel link" may be controversial at first glance, because traffic control is performed by a routing function rather than through detailed negotiation of multiple IPsec security associations. However, it should be noted that the "tunnel link" in this case actually expresses the desire of the VPN operator for a connection providing trusted encryption and security across a public network, while allowing manageable dynamic routing within the protection afforded by IPsec. It does not violate the letter or the spirit of IPsec. It should be noted that alternative proposals for use of encapsulation over IPsec such as [KHETAN] are actually equivalent in terms of IPsec security, in that they use some routing functionality to determine the desired path, then hide the characteristics of the data within an encapsulated IP packet format, so that most IPsec selectors of the internal packet are not visible. Dynamic routing opens possibilities for misdirection of traffic, due to transient conditions or intentional misconfiguration. Since all routing information will be coming from other trusted VPN sites, the Knight & Gleeson Expires January 2003 [Page 12] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 security exposure from this source is equivalent to any private network or VPN that exchanges routing information. The internal routing functionality SHOULD provide support for routing policies to manage the learned routes, as well as traffic filtering. All VPN traffic crossing the public network between the IPsec gateways will be protected by IPsec using the method described in this document. Packets that are identical to tunnel mode are used, although the creation of the "tunnel link" is signaled by a proposal for a transport mode SA. Appropriate levels of encryption should be chosen, commensurate with the level of confidentiality required. 6. Summary for Sub-IP Area 6.1 Summary The PPVPN WG currently supports three types of VPNs: Provider Provisioned Network Based Layer 3 VPNs, Provider Provisioned Network Based Layer 2 VPNs and Provider Provisioned Customer-Edge Based VPNs. This draft discusses the use of standard IPsec capabilities to support routing for CE-based IPSec VPNs. 6.2 Where does it fit in the picture of the Sub-IP work? This work fits in the PPVPN box. Although this work is based on IPsec, it is an application of IPsec, and does not involve changes to IPsec. Therefore it is not considered within the IPsec Working Group. Exchange of dynamic routing information between CE-based VPN devices provisioned by service providers is a key enabling technology for allowing scalable IPsec VPN deployments. 6.3 Why is it targeted at this Working Group? This document describes how standard IPsec mechanisms can support the tunneling of IP multicast and broadcast packets, so that IPsec VPN tunnels can support dynamic routing protocols over the tunnel. Under the current PPVPN WG charter, Provider Provisioned CE-based VPNs fits the scope of the WG, as stated from the following charter extract: "This working group is responsible for defining and specifying a limited number of sets of solutions for supporting provider-provisioned virtual private networks (PPVPNs). The work effort will include the development of a framework document, a service requirements document and several individual technical approach documents that group technologies together to specify specific VPN service offerings. The framework will define the common components and pieces that are needed to build and deploy a PPVPN. Deployment scenarios will include provider-managed VPN components located on customer premises." 6.4 Justification Knight & Gleeson Expires January 2003 [Page 13] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 This draft is justified since it targets the routing issue of CE- based VPNs, which are identified as a specific type of PPVPNs both in the WG charter and the general framework I-D. CE-based VPN has specific characteristics and operational requirements, including routing support. 7. Document Change History Version -01: - Added change history section - Modified title to remove "signal," adjusted text to change emphasis from the concept of signaling. We felt that there is not a specific need to signal the ability to support routing protocols since routing protocols are typically configured on the nodes, and IPsec VPN tunnels should be considered similar to other links, not requiring additional signaling for this purpose. - Clarified "tunnel link" terminology with respect to "VPN tunnel", to align with [CE-BASED]. - Added mention of Steve Kent's plans for RFC2401bis. - Updated references. - Added section discussing tunnel mode vs. transport mode for "tunnel links". 8. References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [CE-BASED] De Clercq, J., Paridaens, O., Iyer, M., Krywaniuk, A., and Wang, C., "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", draft-ietf-ppvpn-ce-based- 02.txt, work in progress, May 2002. [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC-2328] Moy, J., "OSPF Version 2", RFC 2328, STD 54, April 1998. [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [TOUCH] Touch, J., and Eggert, L., "Use of IPsec Transport Mode for Virtual Networks," draft-touch-ipsec-vpn-04.txt, work in progress, June 2002. [WANG] Wang, C., Beadles, M., and Khetan, A., "Routing Support in CE-based IPsec VPNs," draft-wang-cevpn-routing-00.txt, work in progress, October 2001. [RFC-2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC-2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and Traina, P., "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. Knight & Gleeson Expires January 2003 [Page 14] draft-knight-ppvpn-ipsec-dynroute-01.txt July 2002 [KHETAN] Khetan, A., Wang, C., Beadles, M., French, L., and Vyncke, E., "Use of GRE for routing support in IPsec VPNs", draft-khetan- sp-greipsec-00.txt, work in progress, January 2002. 9. Acknowledgements We would like to acknowledge the helpful comments and contributions of the following individuals: Larry DiBurro, Haixiang He, Bob Lee, Shawn Mamros (who implemented this approach), and Simon McCormack. 10. Authors' Addresses Paul Knight Bryan Gleeson Nortel Networks Tahoe Networks 600 Technology Park Drive 3052 Orchard Drive Billerica, MA. 01821 USA San Jose, CA 95134 USA paknight@nortelnetworks.com bryan@tahoenetworks.com +1 (978) 288 6414 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Knight & Gleeson Expires January 2003 [Page 15]