INTERNET-DRAFT Joe Touch and Lars Eggert draft-touch-ipsec-vpn-04.txt USC Information Sciences Institute June 24, 2002 Expires: December 24, 2002 Use of IPsec Transport Mode for Dynamic Routing 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 overlay packet. This document proposes an alternative where IP tunnel encapsulation occurs as a separate initial step, based on a routing lookup on the overlay packet. This is followed by IPsec transport mode processing on the resulting (tunneled) IP packet with an SA determined through an security association database (SAD) match on the tunnel header. The result is compatible with dynamic routing in the overlay. Expires: December 24, 2002 [Page 1] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 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 allowed between two end hosts only; tunnel mode is REQUIRED when at least one of the endpoints is a "security gateway" (intermediate system that implements IPsec functionality, e.g. a router.) 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 to next-hop forwarding, and requires additional restrictions (e.g. on SAD contents). This document discusses this deficiency, and proposes an alternative method that separates the act of IP tunnel encapsulation from IPsec processing. It also discusses the impact of this alternate use of IPsec on the IP security architecture, packet selectors, source address selection, and the Internet Key Exchange (IKE) protocol. An appendix addresses related issues with IP tunnel processing in IPsec, notably issues with IPsec encapsulation and decapsulation. The IPsec working group chair has indicated that some of the mechanisms described in detail in this document will likely be incorporated in a future revision of the IPsec architecture standard [1], pending documentation. This paper is thus submitted as an Informational RFC, to document and finalize the alternative use of IPsec transport mode in preparation of a future update to RFC 2401. This document assumes familiarity with [1], notably with terminology and numerous acronyms therein. 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 [10]. Expires: December 24, 2002 [Page 2] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 2. Background There are two modes of IPsec, transport mode and tunnel mode [1]. In transport mode, IPsec inserts a security protocol header into outgoing IP packets between the original IP header and the packet payload (Figure 1) [2][3]. The contents of the IPsec header depends mainly on the original packet header (Figure 1, arrow). Some payload information - e.g. transport layer headers - can also be involved, but that is not critical to this discussion. Original Outbound Packet Outbound Packet (IPsec Transport Mode) +-----------+---------+ +-----------+==============+---------+ | IP Header | Payload | | IP Header | IPsec Header | Payload | +-----------+---------+ +-----------+==============+---------+ | ^ | | +-------------+ SA Lookup Figure 1: Outbound Packet Construction under IPsec Transport Mode In 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 IP packet, which is then secured with IPsec. This has been described [1] as "a tunnel mode SA is essentially a [transport mode] SA applied to an IP tunnel" - however, there are significant differences between the two, and it is exactly the differences which are the focus of this document. Outbound Packet (IPsec Tunnel Mode) +==================+==============+-----------------+---------+ | Tunnel IP Header | IPsec Header | Orig. IP Header | Payload | +==================+==============+-----------------+---------+ ^ ^ | | | | +----------------+----------------+ IP Encapsulation SA Lookup Figure 2: Outbound Packet Construction under IPsec Tunnel Mode In IPsec tunnel mode, the original inner packet (its IP and possibly internal transport headers) determines the IPsec SA, which in turn Expires: December 24, 2002 [Page 3] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 includes encapsulation information, i.e. the source and destination addresses for the outer tunnel header (Figure 2, arrows). The encapsulation of an unsecured IPIP tunnel [4] is similar; it is in the subsequent IPsec encryption of that encapsulated packet that they differ: The outer tunnel header is determined by the original inner header (Figure 3) [4]. However, if a subsequent transport mode IPsec were performed on such a tunneled 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. Outbound Packet (IPIP Tunnel) +==================+-----------------+---------+ | Tunnel IP Header | Orig. IP Header | Payload | +==================+-----------------+---------+ ^ | | | +------------------+ IP Encapsulation Figure 3: Outbound Packet Construction for IPIP Tunnel Outbound Packet (IPIP Tunnel + IPsec Transport Mode) +==================+==============+-----------------+---------+ | Tunnel IP Header | IPsec Header | Orig. IP Header | Payload | +==================+==============+-----------------+---------+ ^ | ^ | | | | | | +---------------+ | | SA Lookup | | | +----------------------------------+ IP Encapsulation Figure 4: Outbound Packet Construction for IPIP Tunnel + IPsec Transport Mode Despite the difference in outbound processing at the source for these two alternatives, 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. Expires: December 24, 2002 [Page 4] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 3. IPsec for Dynamically Routed Overlay Networks Overlay networks, also known as VPNs when encrypted, 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 their virtual links [6]. This does not provide end-to-end security, but can provide an additional level of hop-by-hop 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. 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]. However, IPsec tunnel mode can be incompatible with dynamic routing [5]. Consider an overlay with virtual links secured through IPsec, as in Figure 5. Traffic arrives at gateway A from a variety of overlay hosts, on virtual link 1. There are two outgoing virtual links for this incoming traffic: out link 2 going to the overlay next-hop gateway B, and out link 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 Expires: December 24, 2002 [Page 5] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 In an overlay network, it is useful to have per-link SAs. Using a single SA for multiple links can compromise security. In this example, link 2 and link 3 have different SAs (Figure 5). The problem occurs when a packet from source X to destination Y arrives on link 1 at gateway A. Gateway A now needs to both forward and encrypt the packet when forwarding it in the overlay. The current IPsec gateway rules require that link 2 and link 3 be tunnel mode IPsec SAs, in which case the incoming packet and SAD alone determine the SA and tunnel header. However, gateway A cannot determine which SA to use without first determining the packet's next hop. Outgoing interface information, however, does NOT appear to be REQUIRED in the SAD, and gateway A cannot dynamically route this packet. Furthermore, the virtual links differ in their tunnel encapsulation headers; again, gateway A cannot know which encapsulation header to use until the next hop is determined, and neither route nor outgoing network interface are a REQUIRED part of the SAD. IPIP encapsulation originated with Mobile IP, but has since often been adopted when virtual topologies were required. Examples include overlay networks to support emerging protocols (IP Multicast, IPv6, and Mobile IP itself) as well as systems that provide private networks over the Internet (PPVPN, X-Bone). Most of these uses would benefit from IPsec to authenticate or encrypt their IP tunnels. However, under the current standard, they must use IPsec tunnel mode instead of IPIP tunnels, which requires implementation changes at the least, and may even be entirely unusable (when a mechanism depends on features of IPIP encapsulation that IPsec tunnel mode does not implement - Appendix A). The alternative proposed in Section 4 (IIPtran) builds on standards- compliant IPIP encapsulation and IPsec transport mode, and can thus add security to existing uses of IPIP encapsulation without modifications. 3.1 Issues with IPsec Tunnel Mode Supporting dynamic routing in the current IPsec framework, using IPsec tunnel mode SAs as overlay links, is difficult and non- intuitive. It depends on per-interface SADs, which are not required in the current standard, as well as additional restrictions on the contents of those per-interface SADs. Expires: December 24, 2002 [Page 6] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 Packet forwarding on most platforms is based on a forwarding table managed by a routing daemon that exchanges connectivity information with directly connected peers. Route entries in the forwarding table map destination IP addresses to one of the host's interfaces. In the case of an overlay network, routing lookups occur on virtual destination addresses of overlay packets. For the routing lookup on such a virtual destination address to succeed, routes to outbound virtual interfaces (tunnels) MUST exist in the forwarding table. When IPsec tunnel mode SAs are used to provide overlay links, the presence of a separate pseudo-interface for _each_ existing tunnel mode SA is REQUIRED. The pseudo-interface acts as the outbound interface of the virtual destination's route entry. Creating and maintaining these pseudo-interfaces in response to SAD changes requires a close integration of routing with IPsec. Many current IPsec implementations do not support this IPsec/routing integration. Instead, they use firewall-like pattern-matching on packets against the SAD. This operation 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 overlay 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 not REQUIRED. Machines participating in an overlay network are necessarily 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 multi-homed machines. 3.2 Dynamic Routing under the Current IPsec Framework With per-interface SADs, dynamic routing could work in an overlay network with the SA lookup described in Section 3.1. For an overlay packet, the respective outbound pseudo-interface is located based on its overlay destination IP. The SA lookup for the packet then occurs on the SAD associated with the pseudo-interface. However, this scheme requires additional restrictions to function. For tunnel 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 forwarding loops. Multiple tunnel mode SAs are prohibited, because dynamic routing algorithms construct topology information based on per-interface broadcasts. Merging Expires: December 24, 2002 [Page 7] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 different virtual links (tunnels) into a single pseudo-interface can cause routing events on one overlay link to incorrectly apply to other links sharing a pseudo-interface (for tunnel mode SAs with different encapsulation headers). Furthermore, IPsec transport mode SAs MUST only be attached to physical interfaces. Packet processing on many platforms depends on the property of each processing step only prepending (or removing) a single layer of encapsulation. Allowing IPsec tunnel mode SAs to operate on physical interfaces essentially adds two headers in a processing step, one of the key factors that breaks dynamic routing. The key restriction is that tunnel mode SAs MUST be restricted to pseudo-interfaces, and transport mode SAs MUST be restricted to regular interfaces. Thus, tunnel encapsulation essentially becomes a function of the interface, and not IPsec. The alternative solution proposed in Section 4 recognizes this property. It is consequently based on IPIP tunnels and (only) transport mode SAs, and does not restrict the contents of per-interfaces SADs. 3.3 Summary In summary, dynamic routing in the current IPsec frameworks depends on a tight integration between the SAD and routing table, where per- interface SADs exist, a pseudo interface is created and maintained for each tunnel mode SA, each per-interface SAD only holds a single tunnel mode SA, and transport mode SAs are restricted to physical interfaces. The proposed alternative (Section 4) suffers from none of these drawbacks. 4. Alternative Solution: IIPtran 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 encapsulation header (per- interface SADs), 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 can examine the inner packet headers) [5][6]. Thus, IIPtran can express the same set of Expires: December 24, 2002 [Page 8] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 security policies as IPsec tunnel mode through selectors on the inner IP header, but additionally can rely on the outer header, which tunnel mode cannot. The primary issues are 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 On receiving a packet, both IPsec tunnel mode and IIPtran decrypt or authenticate the packet using the same techniques. IPsec tunnel integrates IPIP decapsulation with IPsec policy checks, and can thus drop a packet even though it decapsulates successfully. IIPtran can do similar checks on the inner packet, as if it were a transport header, and drop the packet if it violates the same 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; once they are accepted during IPsec decapsulation, they are accepted. IIPtran REQUIRES that unwrapped packets be further processed, to validate whether they conform to their respective IPsec policy. 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. Note that IPsec tunnel mode and IIPtran are interoperable [5]. It could be 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 (or should be, see Appendix A). The difference is that the IP encapsulation done through IPsec tunnel mode is inconsistent with RFC 2003 [4]. IIPtran is consistent because it decouples IP encapsulation from IPsec processing (and simply uses existing RFC 2003 encapsulation mechanisms.) A major drawback of a combined approach (IPsec tunnel mode on Expires: December 24, 2002 [Page 9] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 inbound, IIPtran on outbound) is failure to support dynamic routing. Most routing algorithms depend on symmetric paths, where responses to routing queries are received over the same interface they went out on. In the combined approach, outbound packets leave via an IPIP tunnel device, but responses enter via an IPsec tunnel mode SA, causing problems. Because IIPtran and IPsec tunnel mode packets look identical on the wire, another decapsulation issue exists: When an IPsec'ed packet arrives which contains an IPIP inner packet, it is not possible to distinguish whether the packet 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 SA 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. Expires: December 24, 2002 [Page 10] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 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 manually-keyed SAs, for example). IKE negotiations between systems that use IIPtran and systems that use standard IPsec tunnel mode can 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. A major drawback of this combined approach, however, is lack of support for dynamic routing, as described in Section 3. 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, because IPsec selectors indirectly determine route selection through encapsulation. Thus, IPsec selectors allow routing decisions to be based on packet content (other than the IP destination address). Since IIPtran decouples routing from IPsec processing, it requires a content-based forwarding mechanism that can support all of the IPsec selectors for full conformance. On many platforms, existing firewall mechanisms can be Expires: December 24, 2002 [Page 11] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 used for that purpose. 4.5 Source Address Selection Many implementations do not represent IPsec tunnel mode SAs as network interfaces. This affects source address selection for VPN packets that originate on a security gateway and are destined for the overlay network. The requirements document for Internet hosts [11] specifies that the IP source address of an outbound packet should (1) for directly connected networks be derived from the corresponding interface, or (2) be derived from existing dynamic or static route entries to the destination, or finally (3) be derived from the interface attached to a default gateway. When IPsec tunnel mode SAs are not represented as interfaces, rules (1) and (2) will not return a usable source address for a given packet. Consequently, the IP address of the local interface connecting to a default gateway will be used as the source address for the overlay packet. Often, a default gateway for a host provides connectivity in the base network underlying the overlay. The outgoing packet will thus be transmitted from a source in the base network to a destination in the overlay network. This can result in numerous problems due to firewalls and admission control failures, and may even lead to security compromises, when the receiver uses the source address of the original packet when replying to a message. (Since the source address can lie in the base network, the replies may be transmitted in the clear.) To avoid these issues, all overlay traffic originating on security gateways MUST have application-specified source addresses, which restricts the set of applications that can be used in an overlay, or requires application modifications. The alternative solution suggested in this document (IIPtran) resolves these issues without application modifications, since IPIP tunnels MUST always be host interfaces. Thus, source address selection rules with IIPtran will always terminate with rule (1) or (2), and the problematic rule (3) will be avoided. 4.6 SA Lookup under IIPtran When looking up an SA for a given packet, IPsec allows selectors to match on the contents of its IP header _and_ transport headers. RFC Expires: December 24, 2002 [Page 12] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 2401 explicitly recognizes that the transport layer header may be nested several headers deep inside the packet, and allows a system to (quote) "chain through the packet headers checking the 'Protocol' or 'Next Header' field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque." With IIPtran, the SA lookup starts on the outer (tunnel) header, and selectors including port number information must thus traverse the inner IP header (and possibly other headers) before they can match on the transport headers. IIPtran thus REQUIRES that IP be a protocol on IPsec's list of known "extension headers". This recognizes that with IPIP encapsulation, IP in the base network is used as a link layer for an IP overlay network; or in other words, IP is used a a transport layer over IP. Recognizing IP as a valid transport layer over IP also allows selectors to match on the contents of the inner ("transport") IP header. Thus, IPsec selectors under IIPtran can express the same set of policies as conventional IPsec tunnel mode. 5. Security Considerations Security considerations are addressed in throughout this document, as they are a primary concern of alternate uses of IPsec. 6. Summary and Recommendations This document discussed issues when IPsec is used to secure the links of an overlay network to create a VPN. The current use of IPsec tunnel mode for overlay links requires tight integration between the routing table and per-interface SADs (which are not currently a REQUIRED component of IPsec), including restrictions on the contents of tunnel interface SADs. An alternative composition of a subset of IPsec (i.e. transport mode) together with existing standard IPIP encapsulation results in an interoperable, standards-conforming equivalent that is both simpler and more modular. Expires: December 24, 2002 [Page 13] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 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 and Anindo Banerjea. 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. Members of several IETF WGs (especially IPsec: Stephen Kent, PPVPN: Eric Vyncke, Paul Knight, Mobile IP) provided valuable input on the details of IPsec processing in earlier revisions of this document. Appendix A: Encapsulation/Decapsulation Issues There are inconsistencies between the IPIP encapsulation rules specified by IPsec [1] and those specified by Mobile IP [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 can 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, it is Expires: December 24, 2002 [Page 14] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 RECOMMENDED that IPsec IPIP encapsulation not permit the clearing of the outer DF flag. When the SA requires clearing the DF flag, 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 included in an update of RFC 2003. Another approach to closing the covert channel is to always set the DF flag in the outer header (whether or not it is set in the inner header). Setting the DF flag allows PMTU discovery to operate normally. The details of this approach are discussed in [4]. A.2 Decapsulation Issues As noted in Section 4.1, an IPsec'ed packet with a protocol field of type 4 (IP) is ambiguous. It indicates 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 a specific, unambiguous processing rule is added provided for processing type 4 packets (always decapsulate/never decapsulate). A.3 Appendix Summary IPsec's use of IPIP encapsulation conflicts with the IPIP standard [4], because some IP header fields can be exploited as a covert channel by an attacker. However, this security issue should be resolved in an update to RFC 2003, instead of specifying a non- standard conforming variant of IPIP encapsulation inside IPsec. References [1] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol," RFC 2401, November 1998. [2] Kent, S., Atkinson, R., "IP Authentication Header," RFC 2402, November 1998. Expires: December 24, 2002 [Page 15] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 [3] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)," RFC 2406, November 1998. [4] Perkins, C., "IP Encapsulation within IP," RFC 2003, October 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.isi.edu/touch/pubs/comnet2001/ [6] Touch, J., Hotz, S., "The X-Bone," Proc. Third Global Internet Conference at Globecom, Sydney, Australia, November 1998. [7] Mogul, J., Deering, S., "Path MTU Discovery," RFC 1191, November 1990. [8] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 2923, September 2000. [9] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [11] Braden, R. (Editor), "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. 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 Expires: December 24, 2002 [Page 16] Touch & Eggert IPsec Transport Mode for Dynamic Routing June 24, 2002 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 entitled "X-Bone" and number F30602-01-2-0529 entitled "DynaBone". 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: December 24, 2002 [Page 17]