INTERNET-DRAFT Joe Touch and Lars Eggert draft-touch-ipsec-vpn-03.txt USC/ISI Mar. 1, 2002 Expires: Sep. 1, 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 Sep. 1, 2002 [Page 1] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 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 Sep. 1, 2002 [Page 2] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 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 Sep. 1, 2002 [Page 3] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 +---------+ | #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 Sep. 1, 2002 [Page 4] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 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 Supporting dynamic routing in the current IPsec framework (i.e. with IPsec tunnel mode SAs) is difficult and non-intuitive. Packet forwarding on most platforms is based on a forwarding table, which is Expires Sep. 1, 2002 [Page 5] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 managed by a routing daemon that exchanges connectivity information with peers over a host's network links. Route entries map a destination IP address to one of the host's interfaces. In the case of an overlay network, routing lookups occur on virtual destination addressed of overlay packets. For the routing lookup on such a virtual destination address to succeed, a route to an outbound virtual interface (tunnel) must exist in the forwarding table. When IPsec tunnel mode SAs are used to provide overlay links, this _requires_ the presence of a separate pseudo-interface for _each_ existing tunnel mode SA. The pseudo-interface acts as the outbound interface of the virtual destination's route entry. Creating and maintaining these pseudo-interfaces requires a close integration of routing with IPsec. Many current IPsec implementations do not support this IPsec/routing integration. Instead, they pattern match an outgoing packet against the SAD in a combined, firewall-like operation that is independent from routing (and usually happens earlier during outbound processing). To enable dynamic routing, an SA must be located through a routing lookup on the IP destination address, which identifies an outbound interface, and then based on the SPI and security protocol ID in the respective per-interface SAD. Per-interface SADs are already suggested for multi-homed machines in [1] (but nor required). Machines participating in an overlay network are automatically multi-homed: They have at least one physical network interface and at least one virtual tunnel interface into the overlay. Per-interface SADs should be required for all multi-homed machines. With per-interface SADs, dynamic routing could work in an overlay network with the SA lookup described above. For an overlay packet, the respective outbound pseudo interface is located based on its destination IP. The SA lookup for the packet then occurs on the SAD associated with the pseudo interface. For pseudo-interfaces, the contents of per-interface SADs are limited: Each such SAD must contain exactly one IPsec tunnel mode SA. Transport mode SAs are prohibited, because they would not cause encapsulation, and so lead to routing loops. Multiple tunnel mode SAs are prohibited, because dynamic routing algorithms construct topology information that is based on per-interface broadcasts. Merging different virtual links (tunnels) onto the same pseudo interface would cause bogus routing failures for all SAs sharing a pseudo interface, should dynamic routing detect a link failure for one of them. Expires Sep. 1, 2002 [Page 6] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 Likewise, the system must guarantee that IPsec transport mode SAs are only ever attached to physical interfaces. Allowing tunnel mode SAs into the SADs of physical interfaces was the key factor that broke dynamic routing. The solution described in this section is based on the observation that current packet processing on many platforms depends on the property that each processing step only prepends or removes a single layer of encapsulation. Allowing IPsec tunnel mode SAs to operate on physical interfaces in essence adds two layers in a single iteration, causing breakage. The remainder of this document will discuss a simpler, alternative solution. The solution discussed above requires separation between transport mode and tunnel mode SAs to function. Tunnel encapsulation must be limited to pseudo-interfaces. Thus, encapsulation is essentially a function of the interface, and not IPsec. The alternative solution below recognizes this property, and is consequently based on IP-in-IP tunnels and (only) transport mode SAs. 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. Expires Sep. 1, 2002 [Page 7] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 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 approaches 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. To allow for complex accept policies, it should be possible to reconstruct the format of the original packet at the time it first entered a machine based on saved processing context at any time during inbound processing. This allows incoming IIPtran packets to be IPIP decapsulated _only_ where an appropriate SA has been used, but as a separate step during IPIP decapsulation _after_ IPsec transport mode inbound processing. 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 Expires Sep. 1, 2002 [Page 8] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 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. 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 Expires Sep. 1, 2002 [Page 9] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 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. 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, and (past) Steve Hotz, Anindo Banerjea, Alper Demir, and Ankur Sheth. 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. Several members of the IPsec and Mobile IP IETF Working Groups, especially Stephen Kent, provided valuable input on the details of IPsec processig in earlier revisions of this document. Expires Sep. 1, 2002 [Page 10] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 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 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 Expires Sep. 1, 2002 [Page 11] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 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 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 Sep. 1, 2002 [Page 12] Touch & Eggert IPsec Transport Mode for Virtual Nets Mar. 1, 2002 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 agreements number F30602-98-1-0200 and F30602-01-2-0529. 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 Sep. 1, 2002 [Page 13]