INTERNET-DRAFT Joe Touch and Lars Eggert draft-touch-ipsec-vpn-00.txt USC/ISI March 10, 2000 Expires: Sept. 10, 2000 Use of IPSEC Transport Mode for Virtual Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except for the right to produce derivative works. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document addresses the use of IPSEC to secure the virtual links of an overlay network. It addresses how IPSEC tunnel mode can conflict with dynamic routing in an overlay, due to the dependence of both the security association (SA) and the IP tunnel encapsulation header on the header of the incoming packet. An alternative is proposed, where IP tunnel encapsulation occurs as a separate initial step, followed by IPSEC transport mode on the result. The tunnel header is determined by the source header, and the SA is determined by the tunnel header. The result is consistent with dynamic routing in the overlay. This document discusses this alternative, and its impact on IPSEC. This document is a product of the X-Bone project at USC/ISI [5] [6]. Comments are solicited and should be addressed to the author. Introduction The IP security architecture, IPSEC, consists of two modes, transport mode and tunnel mode. Transport mode is recommended end-to-end only, and tunnel mode is recommended for so-called "bump in the stack" uses. One such common use for the latter is to support overlay or virtual networks (VPNs), where the links of an overlay are secured via IPSEC. Tunnel-mode IPSEC complicates the use of dynamic routing in virtual networks, by linking SA selection with route selection. This document discusses this deficiency, and an alternative architecture which separates the act of tunnel encapsulation from IPSEC processing. It also discusses the impact of this alternate use of IPSEC on the IP security architecture. This document assumes familiarity with [1], notably with terminology and numerous acronyms therein. Background There are two modes of IPSEC, transport mode and tunnel mode [1]. In transport mode, IPSEC augments outgoing IP packets with a security protocol header (Fig. 1) [2] [3]. The IPSEC header determined by the original packet, and security information indexed by the packet's header (Fig. 1, arrow). (transport mode may look at transport headers, but that is not critical to this discussion). Original packet: IPSEC transport mode outgoing packet: +-------+--------+ +-------+*******+--------+ | Data | IP Hdr | | Data | IPSEC | IP Hdr | +-------+--------+ +-------+*******+--------+ ^ | | | +-------+ FIGURE 1: IPSEC transport mode Tunnel mode IPSEC augments outgoing IP packets with the same security protocol header, but it is placed outside the original packet, and an additional IP header is placed in front (Fig. 2). This has been described as 'transport mode applied to an IP tunnel', however, there are significant differences between the two. +-------+--------+*******+************+ | Data | IP Hdr | IPSEC | tun IP Hdr | +-------+--------+*******+************+ | ^ | ^ | #1 | | #2 | +-------+ +--------+ FIGURE 2: IPSEC tunnel mode In IPSEC tunnel mode, the original packet (primarily its IP header) determines the IPSEC SA, which in turn determines the source and destination addresses in the outer, tunnel header (Fig. 2, arrows). In an IPIP tunnel, the tunnel header is determined by the inner header (Fig 3.) [4]. If a subsequent transport mode IPSEC were performed on the same packet, the IPSEC header would be computed based on the outer, tunnel header (Fig. 4). Contrast this with Fig. 2, in which the IPSEC header is determined by the innder IP header. +-------+--------+************+ | Data | IP Hdr | tun IP Hdr | +-------+--------+************+ | ^ | | +----------+ FIGURE 3: IPIP tunnel +---------+ | #2 | v | +-------+--------+*******+************+ | Data | IP Hdr | IPSEC | tun IP Hdr | +-------+--------+*******+************+ | ^ | #1 | +------------------+ FIGURE 4: IPIP tunnel + transport mode IPSEC Despite the difference in how the source determines when to use these two modes, IPSEC tunnel and IPIP + IPSEC transport (IIPtran). The two can interoperate, given appropriate configurations. The next section describes why the difference is important. Use of IPSEC in an Overlay Overlay networks connect subsets of resources of an existing, underlying network, and present the result as a virtual network layer to upper-layer protocols. Overlays rely on tunnels to provide virtual links where two resources are not directly connected in the underlying network; these tunnels represent links in the overlay, but are paths (sequences of connected links) in the existing, underlying network. It can be useful for overlay networks to provide IPSEC over these virtual links [6]. This does not provide end-to-end security, but can provide an additional level of network security, enabling gateways in the overlay to prevent or slow down denial of service attacks. It can also enable privacy on the multiple hops of a virtual link. In all cases, IPSEC in an overlay network secures only the links of the overlay. IPSEC and Dynamic Routing IPSEC requires that overlay links, links between gateways or links between a host and a gateway, use tunnel-mode IPSEC. Tunnel-mode can be incompatible with dynamic routing. Consider an overlay with IPSEC'd virtual links, as in Figure 5. Traffic arrives at gateway A from a variety of overlay hosts, on virtual link #1. There are two outgoing links for this incoming traffic: out #2 going to the overlay next-hop gateway B, and out #3 going to the overlay next-hop gateway C. For this example, assume the incoming traffic is from a single overlay source X, going to a single overlay destination Y. In this figure, multiple virtual links are represented by elipses (...). B ... / \ /#2 \ / \ X --...--> A D --...--> Y #1 \ / \#3 / \ / C ... FIGURE 4: Overlay with dynamic routing In an overlay, it is useful to have per-link keys. Using a single key for multiple links can compromise key security. In this case, link #2 and link #3 have different keys, K2 and K3 respectively. The problem occurs when a packet arrives on link #1 at A. The packet is addressed from X to Y, and A needs to both route and encrypt it. The current IPSEC gateway rules require that link #2 and link #3 be tunnel-mode IPSEC, in which case, the incoming packet and security database alone determine the key and tunnel header. However, A cannot determine which key to use without first determining which route the packet will take; outgoing interface does not appear to be required in the security databases. As a result, A cannot know which key to use. Furthermore, the virtual links differ in their tunnel headers; again, A cannot know which tunnel header to use until the route is determined, and neither route nor outgoing interface are a required part of the IPSEC security database. Existing Solutions In order to use dynamic routing with IPSEC, either dynamic routing must update the key database as it updates routes, or IPSEC tunnel mode processing must be augmented to include outgoing interface and/or route as additional context, and use this context to index the key databases. It is difficult to incorporate key management with dynamic routing. The key database would need to become an extension of the routing table. It would be necessary and difficult to synchronize changes to the routing table with changes to the key database. This would require linking key management with dynamic routing in ways that encumber both systems. Alternately, IPSEC key databases could be augmented to include interface information in the security databases. This has been the case in some implementations, where IPSEC keying is a function bound to a virtual interface. While this is feasible, it would need to be required to support dynamic routing in virtual networks. Such interfaces are typically not required in protocol specifications, as they too specifically require implementation details. Alternative Solution An alternate solution is to relax the IPSEC requirement that transit traffic (gateway-gateway and host-gateway) use tunnel-mode IPSEC, and to allow IIPtran. It is already recognized that IPSEC tunnel mode is similar to IIPtran. IIPtran processing allows a gateway to use outgoing interface information to determine the tunnel header, and allows the IPSEC header to either rely solely on the tunnel header, or on the tunnel header and the inner header as desired (because transport mode may examine the inner packet headers) [5] [6]. Issues The primary issue is that of potential differences between the two techniques for supporting IPSEC in overlays, interoperation of the two, and the architectural impact on IPSEC. Differences On sending a packet, IPSEC tunnel mode may include unchanging portions of the incoming packet's IP header and the data in its hash. It is not clear whether IPSEC tunnel mode can also use the information from the tunnel header it adds, but this is moot, since it can incorporate it into the key when the key is computed. IIPtran can examine the same portions of the header, and thus result in the same hash. On receiving a packet, both techniques decrypt or authenticate the packet using the same technique. IPSEC tunnel mode can adds an additional check of the inner header, that it matches a specified value or range, thus, in one step, tossing the packet even though it unwraps successfully. Use of IPSEC transport mode in IIPtran can do similar checks of the inner packet, as if it were a transport header, and drop the packet if it violates a specified value or range. The primary difference is in the subsequent processing of the incoming packet. IPSEC tunnel mode does not require a separate rule for accepting packets with the inner header; once they are accepted during the unwrap phase, they are accepted. IIPtran requires that unwrapped packets be further processed by an additional round, which requires that incoming packets with these headers be accepted. As noted in [1], IPSEC processing should retain SA use for subsequent IPSEC or firewall processing. It should be possible for these incoming packets to be IPIP decapsulated _only_ where the appropriate SA has been used, but as a separate step. However, we note that the two techniques are interoperable [5]. It may be possible, if not preferable, to apply IIPtran processing for outgoing packets, and IPSEC tunnel mode processing for incoming packets. Experiments have verified that this is possible [5]. Architectural Impact The IP Security Architecture document defines the appropriate use of IPSEC transport mode and IPSEC tunnel mode; the former is to be used only for host-host communication, and the latter for all transit communication [1]. The use of IIPtran appears to violate this architecture, because it uses IPSEC transport mode for transit communication. An overlay uses components in the underlying network as both hosts and gateways, not necessarily exclusively. An overlay link can, and perhaps should, be considered an application to the underlying network. As such, it is host-host communication, where the components are considered hosts in the underlying network. One function of these hosts is to act as gateways in the overlay network; these overlay gateways are not visible to the underlying network. As a result, this alternate use of IPSEC is consistent with the existing architecture. It furthermore does not compromise the E2E use of IPSEC either in an overlay or the base network; it only adds IPSEC protection to secure overlay links. Security Considerations Security considerations are addressed in throughout this document, as they are a primary concern of alternate uses of IPSEC. Acknowlegments The authors would like to thank the members of the X-Bone project at USC/ISI for their contributions to the ideas behind this draft, notably (current) Greg Finn, Amy S. Hughes, Yu-Shun Wang, Alper Demir, and Ankur Sheth, and (past) Steve Hotz and Anindo Banerjea. References [1] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol," RFC-2401, Nov. 1998. [2] Kent, S., Atkinson, R., "IP Authentication Header," RFC-2402, Nov. 1998. [3] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)," RFC-2406, Nov. 1998. [4] Perkins, C., "IP Encapsulation within IP," RFC-2003, Oct. 1996. [5] Touch, J., "Dynamic Internet Overlay Deployment and Management Using the X-Bone," (work in progress) http://www.isi.edu/xbone [6] Touch, J., Hotz, S., "The X-Bone," Proc. Third Global Internet Conference at Globecom, Sydney, Australia, Nov. 1998. Author's Address Joe Touch University of Southern California/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6601 USA Phone: +1 310-448-9151 Fax: +1 310-823-6714 URL: http://www.isi.edu/touch Email: touch@isi.edu Attribution and Disclaimer Effort sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-98-1-0200. The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes not withstanding any copyright annotation therein. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Defense Advanced Research Projects Agency (DARPA), the Air Force Resaerch Laboratory, or the U.S. Government.