INTERNET-DRAFT Joe Touch and Lars Eggert draft-touch-ipsec-vpn-02.txt USC/ISI Nov. 21, 2001 Expires: May 21, 2002 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. This document proposes an alternative 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 compatible with dynamic routing in the overlay. Expires May 21, 2002 [Page 1] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 This document discusses this alternative and its impact on IPsec. It addresses issues raised with IPsec tunnel mode IP encapsulation and decapsulation (Appendix A), and interactions with the Internet Key Exchange (IKE). This document is a product of the X-Bone and DynaBone projects at USC/ISI [5][6]. Comments are solicited and should be addressed to the authors. 1. Introduction The IP security architecture, IPsec, consists of two modes, transport mode and tunnel mode [1]. Transport mode is recommended end-to-end only, and tunnel mode is recommended for so-called "bump in the stack" uses. A common use for the latter is to support overlay or virtual private networks (VPNs), where the links of an overlay are secured via IPsec. Tunnel mode IPsec complicates the use of dynamic routing in such virtual networks, by linking SA selection with next-hop forwarding. This document discusses this deficiency, and an alternative method that 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 and the Internet Key Exchange (IKE). An appendix also addresses related issues with IPIP processing in IPsec, notably issues with IPsec encapsulation and decapsulation. This document assumes familiarity with [1], notably with terminology and numerous acronyms therein. 2. 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 (Figure 1) [2][3]. The IPsec header is determined by the original packet, and security information is indexed by the packet header (Figure 1, arrow). (IPsec transport mode may look at transport headers, but that is not critical to this discussion). Expires May 21, 2002 [Page 2] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 Ipsec Transport Mode Original Packet: 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 (Figure 2). In essence, the original packet is placed as payload inside another IPsec'ed packet. 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 inner packet (primarily its IP header) determines the IPsec SA, which in turn determines the source and destination addresses in the outer tunnel header (Figure 2, arrows). For an IPIP tunnel, the situation is different: The outer tunnel header is determined by the original inner header (Figure 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 (Figure 4). Contrast this with Figure 2, in which the IPsec header is determined by the inner IP header. +-------+--------+************+ | Data | IP Hdr | tun IP Hdr | +-------+--------+************+ | ^ | | +----------+ Figure 3: IPIP tunnel Expires May 21, 2002 [Page 3] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 +---------+ | #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 mode and IPsec transport mode over an IPIP tunnel (IIPtran) can interoperate, given appropriate configurations. The next section describes why the difference is important. 3. 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 secure 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, e.g., to secure routing protocols. In all cases, using IPsec for this purpose in an overlay network secures only the links of the overlay. 3.1 IPsec and Dynamic Routing Using IPsec to secure overlay links conventionally requires the use of IPsec tunnel mode, because the communicating peers are gateway pairs, or a host and a gateway [1]. IPsec tunnel mode can be incompatible with dynamic routing [5]. Consider an overlay with IPsec'ed 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 Expires May 21, 2002 [Page 4] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 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. Multiple virtual links are represented by ellipses (...) in Figure 5. B ... / \ /#2 \ / \ X --...--> A D --...--> Y #1 \ / \#3 / \ / C ... Figure 5: Overlay with dynamic routing In an overlay network, 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 forward and encrypt it when transmitting it in the overlay. The current IPsec gateway rules require that link #2 and link #3 be tunnel mode IPsec, in which case, the incoming packet and security association database (SAD) alone determine the key and tunnel header. However, A cannot determine which key to use without first determining the packet's next hop; outgoing interface information does not appear to be required in the SAD. 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 next hop is determined, and neither route nor outgoing network interface are a required part of the SAD. 3.2 Existing Solutions In order to use dynamic routing with IPsec, either dynamic routing must update the SAD as it updates the forwarding table, or IPsec tunnel mode processing must be augmented to include outgoing network interfaces and/or routes as additional context, and use this context Expires May 21, 2002 [Page 5] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 to index the SAD. It is difficult to incorporate SA management with dynamic routing. The SAD would need to become an extension of the forwarding table. It would be necessary and difficult to synchronize changes to the forwarding table with changes to the SAD. This would require linking key management with dynamic routing in ways that encumber both systems. Alternately, IPsec could be augmented to include network interface information in the SAD. This has been the case in some implementations, where IPsec keying is a function bound to a virtual network interface. While this is feasible, it would need to be required to support dynamic routing in virtual networks. Such restrictions are typically not included in protocol specifications, as they too specifically regulate implementation details. 3.3 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 IPsec transport mode over IPIP tunnels (IIPtran) as well. 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 original header as desired (because transport mode may examine the inner packet headers) [5][6]. 4. 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, as well as related protocols, such as IKE. 4.1 Differences When sending a packet, IPsec tunnel mode may include unchanging portions of the original 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 Expires May 21, 2002 [Page 6] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 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 techniques. IPsec tunnel mode adds an additional check of the inner header (matching a specified value or range) and can thus, in one step, toss a packet even though it decapsulates 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 decapsulation, 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 information about which SAs were applied to a packet, for subsequent IPsec or firewall processing. It should be possible for these incoming packets to be IPIP decapsulated _only_ where an appropriate SA has been used, but as a separate step. However, we note that IPsec tunnel mode and IIPtran 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, notably because, given appropriate keys, there are no differences in the resulting packets on the wire, excepting as described in the appendix of this document [5]. There is an additional issue with decapsulation, however. When a IPsec'ed packet arrives which includes an IPIP inner packet, it is not possible to distinguish whether it was created using IPsec tunnel mode or IPsec transport mode of an IPIP encapsulated packet. In both cases, the protocol field of the outer header is IPsec (AH or ESP), and the "next header" field for the inner data is 4 (IP). IPsec requires that upon receiving a packet, the SPI is indexed in the SAD to determine whether the association is tunnel mode or transport mode. If the packet is tunnel mode, IPsec MUST decapsulate the packet at that point. If the packet is transport mode, IPsec MUST NOT decapsulate the packet, but rather pass the decrypted packet on to subsequent IP processing. This processing may include decapsulation by other means, including Mobile IP. Expires May 21, 2002 [Page 7] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 4.2 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-to-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-to-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 end-to- end use of IPsec either in an overlay or the base network; it only adds IPsec protection to secure overlay links. 4.3 IKE Interactions The Internet Key Exchange (IKE) [9] is a protocol to dynamically and securely negotiate IPsec keys between end systems. It is not a strictly required component of IPsec in the sense that two hosts can communicate using IPsec without having used IKE to negotiate keys (through pre-shared secrets, for example). IKE negotiations between systems that use IIPtran and systems that use standard IPsec tunnel mode may fail, because an IIPtran host will try to negotiate a transport mode SA to use over the IPIP tunnel, while a conventional hosts will try to negotiate a tunnel mode SA. IKE can currently only negotiate SA pairs where both elements of a pair are either both tunnel or transport mode SAs. One possible solution is to negotiate a tunnel mode SA for use with IIPtran, even though it will internally be applied as a transport mode SA against an IPIP tunnel. Since IIPtran senders and receivers fully comply with the IPsec tunnel mode specification and interoperate with conventional implementations, this restores interoperability. Expires May 21, 2002 [Page 8] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 4.4 SA Selectors & Dynamic Routing In the IPsec architecture, selectors determine which SAs are applied to packets. Selectors can inspect the source and destination IP address, transport layer protocol, source and destination ports, as well as some other information when choosing SAs. When selectors choose an IPsec tunnel mode SA for a packet, they implicitly determine next-hop forwarding for the packet as well, through encapsulation. By basing the forwarding decision on the packet payload (transport layer ports), IPsec implements a simple content-based routing mechanism. With IIPtran, next-hop forwarding is done outside IPsec. For full IPsec compliance, IIPtran requires a content-based forwarding mechanism that supports all IPsec selectors. On many systems, existing firewall mechanisms can be used for that purpose. 5. Security Considerations Security considerations are addressed in throughout this document, as they are a primary concern of alternate uses of IPsec. Acknowledgments The authors would like to thank the members of the X-Bone and DynaBone projects 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, as well as the comments of various members of both the IPsec and Mobile IP IETF Working Groups. The authors would also like to thank Jun-ichiro itojun Hagino and the KAME project for bringing IKE implications of this proposal to our attention, as well as implementing the mechanisms in this draft in the KAME IPv6/IPsec network stack. Appendix A: Encapsulation/Decapsulation Issues There are inconsistencies between the IPIP encapsulation rules specified by IPsec and those specified by Mobile IP [1][4]. The latter specification is standards track, and the IP protocol number Expires May 21, 2002 [Page 9] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 of 4 (payload of an IP packet of type 4) is assigned by IANA to RFC 2003 [4]. IPsec does not specify any limits on the types of IP packets which can be secured by transport mode, so the use of IPIP inside an IPsec transport packet may be confused with IPsec tunnel mode. A.1 Encapsulation Issues When an IP packet is encapsulated as payload inside another IP packet, some of the outer header fields can be newly written, and others are determined by the inner header [4]. Among these fields is the IP DF (don't fragment) flag. When the inner packet DF flag is clear, the outer packet MAY copy it or set it; however, when the inner DF flag is set, the outer header MUST copy it [4]. IPsec defines conflicting rules, where that flag, and other similar fields (TOS, etc.) may be copied, cleared or set as specified by an SA. IPsec must be able to control whether these fields are copied, to achieve security. Otherwise, they present a covert channel between the inner packet header and outer packet header. However, RFC 2003 requires that the outer fields not be cleared when the inner ones are set, to prevent MTU discovery 'black holes' [7][8]. To avoid a conflict between these rules, and to avoid security weaknesses associated with solely copying the fields, this document recommends that IPsec IPIP encapsulation not permit the clearing of the outer DF flag. When the SA requires cleared DF and the inner packet DF is set, it is proposed that IPsec drop that packet, rather than violate RFC 2003 processing rules. Similar rules are being developed for TOS and other similar IP header fields, to be presented in an update of this document. A.2 Decapsulation Issues As noted in "Differences" above, an IPsec'ed packet with a protocol field of type 4 (IP) is ambiguous. It may indicate either a tunnel mode IPsec packet, or a transport mode IPsec of an IPIP encapsulated packet. Incoming packet processing MUST check the SAD before determining whether to decapsulate IPsec packets with inner payload of protocol type 4. If the SAD indicates a tunnel mode association applies, IPsec MUST decapsulate the packet. If the SAD indicates that a transport mode association applies, IPsec MUST NOT decapsulate the packet. Note that the SAD must indicate one of these two options; ambiguous SAD entries ("ANY", or "TUNNEL or TRANSPORT") cannot be supported, unless Expires May 21, 2002 [Page 10] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 a specific, unambiguous processing rule is added provided for processing type 4 packets (always decapsulate/never decapsulate). 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," Computer Networks, July 2001, pp. 117-135. A previous version appeared in Proc. ICNP 2000, Osaka Japan, pp. 59-68. http://www/touch/pubs/comnet2001/ [6] Touch, J., Hotz, S., "The X-Bone," Proc. Third Global Internet Conference at Globecom, Sydney, Australia, Nov. 1998. [7] Mogul, J., Deering, S., "Path MTU Discovery," RFC 1191, Nov. 1990. [8] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 2923, Sept. 2000. [9] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, Nov. 1998. Expires May 21, 2002 [Page 11] Touch & Eggert IPsec Transport Mode for Virtual Nets Nov. 21, 2001 Author Information Joe Touch Lars Eggert Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, CA 90292-6601 USA Phone: +1 (310) 448-9151 Fax: +1 (310) 448-9300 URL: http://www.isi.edu/{touch,larse} Email: {touch,larse}@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 Research Laboratory, or the U.S. Government. Expires May 21, 2002 [Page 12]