Network Working Group J. Touch Request for Comments: 3884 ISI Category: Informational L. Eggert NEC Y. Wang ISI September 2004 Use of IPsec Transport Mode for Dynamic Routing Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). IESG Note This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it has not had IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
AbstractIPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing
inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Document History . . . . . . . . . . . . . . . . . . . . 3 2. Problem Description. . . . . . . . . . . . . . . . . . . . . . 4 2.1. IPsec Overview . . . . . . . . . . . . . . . . . . . . . 5 2.2. Forwarding Example . . . . . . . . . . . . . . . . . . . 6 2.3. Problem 1: Forwarding Issues . . . . . . . . . . . . . . 7 2.4. Problem 2: Source Address Selection . . . . . . . . . . 8 3. IIPtran: IPIP Tunnel Devices + IPsec Transport Mode . . . . . 9 3.1. IIPtran Details . . . . . . . . . . . . . . . . . . . . 10 3.2. Solving Problem 1: Forwarding Issues . . . . . . . . . . 11 3.3. Solving Problem 2: Source Address Selection . . . . . . 12 4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Other Proposed Solutions . . . . . . . . . . . . . . . . 12 4.1.1. Alternative 1: IPsec with Interface SAs. . . . . 13 4.1.2. Alternative 2: IPsec with Initial Forwarding Lookup. . . . . . . . . . . . . . . . 13 4.1.3. Alternative 3: IPsec with Integrated Forwarding . . . . . . . . . . . . . . . . . . . 14 4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. VN Routing Support and Complexity . . . . . . . 14 4.2.2. Impact on the IPsec Architecture . . . . . . . . 15 4.2.3. Policy Enforcement and Selectors . . . . . . . . 16 4.2.4. IKE Impact . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Summary and Recommendations . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 21 A. Encapsulation/Decapsulation Issues . . . . . . . . . . . . . . 22 A.1. Encapsulation Issues . . . . . . . . . . . . . . . . . . 22 A.2. Decapsulation Issues . . . . . . . . . . . . . . . . . . 23 A.3. Appendix Summary . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
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.) IPsec can be used to secure the links of a virtual network (VN), creating a secure VN. In a secure VN, trusted routers inside the network dynamically forward packets in the clear (internally), and exchange the packets on secure tunnels, where paths may traverse multiple tunnels. Contrast this to the conventional 'virtual private network' (VPN), which often assumes that paths tend to traverse one secure tunnel to resources in a secure core. A general secure VN allows this secure core to be distributed, composed of trusted or privately-managed resources anywhere in the network. This document addresses the use of IPsec to secure the links of a multihop, distributed VN. It describes how virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside the VN, due to the IP routing dependence on references to interfaces and next-hop IP addresses. This document proposes a solution called IIPtran that separates the step of IP tunnel encapsulation from IPsec processing. The solution combines a subset of the current IPsec architecture with other Internet standards to arrive at an interoperable equivalent that is both simpler and has a modular specification. Later sections of this document compare IIPtran to other proposals for dynamic routing inside VPNs, focusing on the impact the different proposals have on the overall IPsec architecture, routing protocols, security policy enforcement, and the Internet Key Exchange (IKE) . An appendix addresses IP tunnel processing issues in IPsec related to IPIP encapsulation and decapsulation. This document assumes familiarity with other Internet standards , notably with terminology and numerous acronyms therein.
IPsec and PPVPN WGs at the 53rd IETF in Minneapolis in March 2002. Version 04 of this draft was submitted for publication as an Informational RFC based on suggestions by the IPsec WG in June 2002, and was under IESG review from then until version 07 was approved for publication in June 2004. During that time, it was substantively revised according to feedback from the IESG regarding interactions with the IPsec specification (RFC 2401 ) and other protocols, with regard to security and compatibility issues. 3], resulting in a VPN. This is not equivalent to end-to-end security, but can be useful when end hosts do not support secure communication themselves. It can provide an additional level of hop-by-hop network security to secure routing in the VPN and isolate the traffic of different VPNs. The topology of an IPsec VPN commonly consists of IPsec tunnel mode virtual links, as required by the IPsec architecture when the communicating peers are gateway pairs, or a host and a gateway . However, this current required use of IPsec tunnel mode can be incompatible with dynamic routing .
The next section provides a short overview on IPsec transport and tunnel mode processing, as far as it is relevant for the understanding of the problem scenarios that follow. The following sections discuss routing problems in detail, based on a common example. 1]. Transport mode secures portions of the existing IP header and the payload data of the packet, and inserts an IPsec header between the IP header and the payload; tunnel mode adds an additional IP header before performing similar operations. This section gives a short overview of the relevant processing steps for both modes. In transport mode, IPsec inserts a security protocol header into outgoing IP packets between the original IP header and the packet payload (Figure 1) . The contents of the IPsec header are based on the result of a "security association" (SA) lookup that uses the contents of the original packet header (Figure 1, arrow) as well as its payload (especially transport layer headers) to locate an SA in the security association database (SAD). 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 When receiving packets secured with IPsec transport mode, a similar SA lookup occurs based on the IP and IPsec headers, followed by a verification step after IPsec processing that checks the contents of the packet and its payload against the respective SA. The verification step is similar to firewall processing. When using tunnel mode, IPsec prepends an IPsec header and an additional IP header to the outgoing IP packet (Figure 2). In essence, the original packet becomes the payload of another IP packet, which IPsec then secures. This has been described  as "a tunnel mode SA is essentially a [transport mode] SA applied to an IP tunnel." However, there are significant differences between the two, as described in the remainder of this section.
In IPsec tunnel mode, the IP header of the original outbound packet together with its payload (especially transport headers) determines the IPsec SA, as for transport mode. However, a tunnel mode SA also contains encapsulation information, including the source and destination IP addresses for the outer tunnel IP header, which is also based on the original outbound packet header and its payload (Figure 2, arrows). Outbound Packet (IPsec Tunnel Mode) +==================+==============+-----------------+---------+ | Tunnel IP Header | IPsec Header | Orig. IP Header | Payload | +==================+==============+-----------------+---------+ ^ ^ | | | | | | | +--------------+ | | SA Lookup | | | +---------------------------------+ IP Encapsulation Figure 2: Outbound Packet Construction under IPsec Tunnel Mode When receiving packets secured with tunnel mode IPsec, an SA lookup occurs based on the contents of the IPsec header and the outer IP header. Next, the packet is decrypted or authenticated based on its IPsec header and the SA, followed by a verification step that checks the contents of the original packet and its payload (especially the inner IP header and transport headers) against the respective SA. 1]. Such hop-by-hop security can be useful, for example, to secure VN routing, and when legacy end systems do not support end-to-end IPsec themselves. Virtual routers in a VN need to forward packets the same way regular Internet routers do: based on the destination IP address and the forwarding table. These two determine the next hop IP address the packet should be forwarded to (additional header fields and inner headers can be used, e.g., in policy routing.) In Figure 3, traffic arrives at gateway A on virtual link 1, having come from any of the virtual hosts upstream of that virtual link. There are two outgoing virtual links for this incoming traffic: out link 3 going to the VPN next-hop gateway B, and out link 4 going to the VPN next-hop gateway C.
For this example, assume the incoming traffic is from a single VPN source X, going to a single VPN destination Y. Ellipses (...) represent multiple virtual links in Figure 3. B ---...--- / \ / 3 \ / \ X ---...--- A D ---...--- Y 1 2 \ / \ 4 / \ / C ---...--- Figure 3: Topology of a Virtual Network Two problems arise; one is forwarding of VN traffic over IPsec tunnel mode links, the other is source address selection on VN end systems.
There are two common implementation scenarios for tunnel mode SAs: One is based on firewall-like packet matching operations where tunnel mode SAs are not virtual interfaces, another is tunnel-based, and treats a tunnel mode SA as a virtual interface. The current IPsec architecture does not mandate one or the other. Under the first approach, the presence of IPsec tunnel mode SAs is invisible to the IP forwarding mechanism. The lookup uses matching rules in the SA lookup process, closer to firewall matching than traditional IP forwarding lookups, and independent from existing IP forwarding tables. The SA lookup determines which virtual link the packet will be forwarded over, because the tunnel mode SA includes encapsulation information. This lookup and the subsequent tunnel mode processing both ignore the contents of the existing IP forwarding table, whether static or dynamic routing are used. This type of tunnel mode processing is thus incompatible with dynamically routed VPNs. The second approach - requiring tunnel mode SAs to be interfaces - can be compatible with dynamically routed VPNs (see Section 4) depending on how it is implemented; however, IIPtran (see Section 3) has the additional benefit of greatly simplifying the IPsec architecture and related specifications, and of being compatible with all IPsec specification compliant implementations. Figure 3), the source address must be the IP address of X's local end of tunnel 1. If host A, which has multiple interfaces inside the VN, sends to Y, the source address must be the IP address of the local end of either tunnel 3 or 4.
Most applications do not bind to a specific source IP address, and instead let the host pick one for their traffic . Rules for source address selection that depend heavily on the notions of interfaces and routes. According to , the IP source address of an outbound packet should: (1) for directly connected networks derive from the corresponding interface, or (2) derive from existing dynamic or static route entries to the destination, or finally (3) derive from the interface attached to a default gateway. Because IPsec tunnel mode SAs are not required to be interfaces, rules (1) and (2) may not return a usable source address for a given packet. Consequently, VN packets will use the IP address of the local interface connecting to a default gateway as their source address. Often, a default gateway for a host provides connectivity in the base network underlying the VN. The outgoing packet will thus have a source address in the base network, and a destination address in the VN. This can result in numerous problems, including applications that fail to operate at all, firewalls and admission control failures, and may even lead to compromised security. Consider two cases, one with IPsec tunnels configured with no wildcard tunnel addresses, the other using certain wildcards. In both cases, an application whose source address is set by RFC 1122  rules may send packets (e.g.) with the source address of that host's base network (via the default route) and a destination address of the remote tunnel endpoint. RFC 2003 ), followed by IPsec transport mode on the encapsulated packet. The IPsec architecture  defines the appropriate use of IPsec transport mode and IPsec tunnel mode (host-to-host communication for the former, and all transit communication for the latter). IIPtran appears to violate this requirement, because it uses IPsec transport mode for transit communication. However, for an IPIP tunnel between security gateways, the gateways themselves source or sink base network traffic when tunneling - they act as hosts in the base network. Thus, IPsec transport mode is also appropriate, if not required, for encapsulated traffic, according to .
As a result, replacing IPsec tunnel mode with IPIP tunnel devices and IPsec transport mode is consistent with the existing architecture. Furthermore, this does not compromise the end-to-end use of IPsec, either inside a VPN or in the base network; it only adds IPsec protection to secure virtual links. The next sections will give a short overview of IPIP encapsulation, and show it combines with IPsec transport mode processing. This section will then discuss how IIPtran addresses each of the problems identified above. RFC 2003 ), followed by IPsec transport mode on the encapsulated packet. RFC 2003  uniquely specifies IPIP encapsulation (placing an IP packet as payload inside another IP packet.) Originally developed for MobileIP, it has often been adopted when virtual topologies were required. Examples include virtual (overlay) networks to support emerging protocols such as IP Multicast, IPv6, and Mobile IP itself, as well as systems that provide private networks over the Internet (X-Bone  and PPVPN). IPIP outbound packet processing, as specified by RFC 2003 , tunnels an existing IP packet by prepending it with another IP header (Figure 4.) Outbound Packet (IPIP Tunnel) +==================+-----------------+---------+ | Tunnel IP Header | Orig. IP Header | Payload | +==================+-----------------+---------+ ^ | | | +------------------+ IPIP Encapsulation Figure 4: Outbound Packet Construction for IPIP Tunnel IIPtran performs this IPIP processing as a first step, followed by IPsec transport mode processing on the resulting IPIP packet (Figure 5.)
Outbound Packet (IPIP Tunnel + IPsec Transport Mode) +==================+==============+-----------------+---------+ | Tunnel IP Header | IPsec Header | Orig. IP Header | Payload | +==================+==============+-----------------+---------+ ^ | ^ | | | | | | +---------------+ | | SA Lookup | | | +----------------------------------+ IPIP Encapsulation Figure 5: Outbound Packet Construction for IPIP Tunnel with IPsec Transport Mode A key difference between Figure 2 and Figure 5 is that in the proposed solution, the IPsec header is based on the outer IP header, whereas under IPsec tunnel mode processing, the IPsec header depends on the contents of the inner IP header and payload (see Section 2.1). However, the resulting VPN packet (Figure 5) on the wire cannot be distinguished from a VPN packet generated by IPsec tunnel mode processing (Figure 2); and the two methods inter-operate, given appropriate configurations on both ends . A detailed discussion of the differences between IIPtran, IPsec tunnel mode, and other proposed mechanisms follows in Section 4. The remainder of this section will describe how IIPtran combines IPIP tunnel devices with IPsec transport mode to solve the problems identified in Section 2. Section 2.3 described how IP forwarding over IPsec tunnel mode SAs breaks, because tunnel mode SAs are not required to be network interfaces. IIPtran uses RFC 2003 IPIP tunnels  to establish the topology of the virtual network. RFC 2003  requires that IPIP tunnels can be routed to, and have configurable addresses. Thus, they can be references in node's routing table (supporting static routing), as well as used by dynamic routing daemons for local communication of reachability information. RFC 2003  addressed the issue of inserting an IPsec header between the two IP headers that are a result of IPIP encapsulation. IIPtran provides further details on this configuration, and demonstrates how it enables dynamic routing in a virtual network.
It is important to note that the RFC 2003 IPIP tunnels  already provide a complete virtual network that can support static or dynamic routing. The proposed solution of using IPIP tunnel with IPsec transport mode decouples IPsec processing from routing and forwarding. IIPtran's use of IPsec is limited to securing the links of the VN (creating a VPN), because IPsec (rightly) lacks internal support for routing and forwarding. Section 2.4 gave an overview of IP source address selection and its dependence on interfaces and routes. Using RFC 2003 IPIP tunnel devices  for VN links, instead of IPsec tunnel mode SAs, allows existing multihoming solutions for source address selection  to solve source address selection in this context as well. As indicated in Section 2.4, according to , the IP source address of an outbound packet is determined by the outbound interface, which is in turn determined by existing forwarding mechanism. Because IPIP tunnels are full-fledged interfaces with associated routes (as in Section 3.2 of ), the routes and address selection as specified in  can also operate as desired in the context of VN links.
RFC 2003 IPIP encapsulation , including the association of tunnels with interfaces, inside IPsec. This defeats the modular architecture of the Internet, and violates the specification of type 4 IP in IP packets as being uniquely defined by a single Internet standard (it is already standardized by ). This solution also requires augmenting the IPsec specification to mandate an implementation detail, one that may be difficult to resolve with other IPsec designs, notably the BITS (bump-in-the- stack) alternative. Although the current IPsec specification is ambiguous and allows this implementation, an implementation- independent design is preferable. 13]. Due to a lack of concrete documentation of this alternative at this time, proposed for an update pending to RFC 2401 , two variants are presumed possible: In the first scenario, the extra forwarding lookup indicates the outbound interface of the final encapsulated tunnel mode packet, i.e., usually a physical interface in the base network. The tunnel mode SA lookup following the forwarding lookup will occur in the per-interface SAD associated with the respective virtual interface. In the second scenario, the extra forwarding lookup returns an outbound tunnel SA interface. This solution seems to be equivalent to the one described above (Section 4.1.1), i.e., all tunnel mode SAs must be interfaces, and is not discussed separately below.
RFC 2003 already specifies those requirements . Furthermore, addition of those requirements would be redundant and potentially conflict with RFC 2003 . Alternative 3 supports dynamic VN routing, but requires modifying routing protocols and forwarding lookup mechanisms to act or synchronize based on SAD entries. This requires substantial changes to routing software and forwarding mechanisms in all participating nodes to interface to the internals of IPsec; this would require revising a large number of current Internet standards. It is also
not clear how tunnel mode SAs that specify port selectors would operate under this scheme, since IP routing has no dependence on transport-layer fields. Alternative 2 does not support dynamic VN routing. The additional forwarding lookup before IPsec processing is irrelevant, because IPsec tunnel mode SAs are not represented as interfaces, and thus invisible to IP routing protocols. Additionally, the forwarding lookup suggested for alternative 2 is not compatible with a weak ES model described in , which requires both an outbound interface indicator as well as the IP address of the next-hop gateway. For example, multiple tunnels can use the same outgoing interface and thus same SAD. The forwarding lookup would return only the interface; lacking the next-hop gateway, the correct SAD entry cannot be determined. Given the next-hop gateway would not help, because the SAD is not indexed by tunnel mode SA encapsulation destination IP address. Because alternative 2 fails to support VN routing, it will not be discussed in the remainder of this section. RFC 2401  describes per-interface SADs as a component of IPsec. When tunnel mode SAs themselves act as interfaces, the function of per-interface SADs needs clarification as follows: First, each tunnel interface SAD must contain exactly one IPsec tunnel mode SA. Transport mode SAs are prohibited, because they would not result in IP encapsulation (the encapsulation header is part of the tunnel mode SA, a transport mode SA would not cause encapsulation), and thus lead to processing loops. Multiple tunnel mode SAs are prohibited, because dynamic routing algorithms construct
topology information based on per-interface communication. Merging different virtual links (tunnels) into a single SA interface can cause routing events on one virtual link to apply incorrectly to other links sharing an SA interface. Second, only the SAD of physical interfaces may contain IPsec transport mode SAs; otherwise, the current issues with VN routing remain unsolved. In summary, these restrictions cause the SADs of SA interfaces to contain only tunnel mode SAs, and the SADs of regular interfaces to contain only transport mode SAs. Thus, tunnel encapsulation essentially becomes a unique property of the interface, and not IPsec. IIPtran already recognizes this property. Consequently, it uses IPIP tunnels directly, and combines them with transport mode processing. By eliminating the use of tunnel mode, it removes the need for additional constraints on the contents of per-interface SAs. RFC 2003 IPIP processing . At that point, IIPtran can support selector checks on both the header and its payload using firewall mechanisms, similar to IPsec tunnel mode processing. The primary difference between the two is that IPsec tunnel mode does not require a separate processing step for validating packets; once IPsec accepts them during the policy check during decapsulation, they are accepted. IIPtran requires additional processing on the decapsulated packets, to validate whether they conform to their respective IPsec policy. As noted in Section 5.2 of the IPsec architecture document , IPsec processing should retain information about what SAs matched a given 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. IIPtran accepts incoming VN packets only if they have arrived over a specific IPIP tunnel that was secured with IPsec transport mode, but as a separate step following IPIP decapsulation. Note that IPsec tunnel mode and IIPtran are interoperable . Experiments have verified this interoperability, notably because there are no differences in the resulting packets on the wire, given appropriate keys. RFC 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 known IPsec "extension header." This recognizes that with IPIP encapsulation, IP VNs use the base IP network as a link layer. Although this small extension to IPsec is not explicitly required, it is already implied. 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. Note that in both cases, these policy enforcement rules violate layering by looking at information other than the outermost header. This is consistent with IPsec's current use of port-based selectors. The next section discusses that selectors may not be useful for virtual networks.
Figure 6). Consider the case where N is either a new node joining an existing VPN, or an existing node that had been disconnected and was just rediscovered via dynamic routing. In this example, A has IPsec tunnel mode SAs to B and C. If the selectors for the virtual source and destination IP addresses for those SAs are not wildcards, the SA needs to be dynamically modified to permit packets from N to pass over the tunnels to B and C. This becomes quickly impractical as VPN sizes grow. B / / / N ------ A \ \ \ C Figure 6: Topology of a Virtual Network Thus, IPsec selectors appear much less useful in a VPN scenario than expected. A consequence might be that IIPtran - even without extensions to support the full expressiveness of tunnel mode SA selectors as described above - can still support the majority of VPN scenarios. One purpose of selectors matching on transport header content is policy routing. Different SAs can apply to different applications, resulting in different apparent virtual topologies. IIPtran supports policy routing in a more modular way, by having existing policy routing implementations forward traffic over multiple, parallel VNs. IIPtran supports arbitrary IP-based policy routing schemes, while policies are limited by the expressiveness of IPsec's selectors in the former case.
9] is a protocol to negotiate IPsec keys between end systems dynamically and securely. 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). Despite its name, IKE also acts as a tunnel management protocol (when IPsec tunnel mode SAs are configured), and negotiates security policies between the peers. Alternatives 1 and 3 use existing IKE without changes. One possible approach to use IKE with IIPtran is to negotiate a tunnel mode SA, and then treat it as a transport mode SA against an IPIP tunnel when communicating with conventional peers. For policies that do not specify selectors based on transport-layer information, this establishes interoperability. However, since IIPtran eliminates IPsec tunnel mode, it could also simplify IKE, by limiting it to its original purpose of key exchange. A new tunnel management protocol (e.g., ATMP ) would set up IPIP tunnels, use an as of yet unspecified second protocol to negotiate security policy, and then use IKE to exchange keys for use with the policy. Current IKE operation would become a modular composition of separate protocols, similar to how IIPtran modularizes IPsec by combining existing Internet standards. For example, a VPN link creation could follow these steps: (1) IKE negotiation in the base network to secure (2) a subsequent tunnel management exchange  in the base network, followed by (3) IKE exchanges over the established tunnel to create a secure VPN link.
 Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.  Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.  Touch, J., "Dynamic Internet overlay deployment and management using the X-Bone", Computer Networks Vol. 36, No. 2-3, July 2001.
 Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual Internet Architecture", ISI Technical Report ISI-TR-570, Workshop on Future Directions in Network Architecture (FDNA) 2003, March 2003.  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.  Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.  Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997.  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, January 2004.  Kent, S., "IP Authentication Header", Work in Progress, February 2004.  Kent, S., "IP Encapsulating Security Payload (ESP)", Work in progress, February 2004.  Kent, S., "Personal Communication", November 2002.  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.  Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
1] and those specified by MobileIP . The latter specification is standards track, and the IP protocol number of 4 (payload of an IP packet of type 4) is uniquely specified by RFC 2003 according to IANA . The use of IPIP inside an IPsec transport packet can be confused with IPsec tunnel mode, because IPsec does not specify any limits on the types of IP packets that transport mode can secure. 2].) Among these fields is the IP DF (do not 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 . IPsec defines conflicting rules, where that flag and other similar fields (TOS, etc.) may be copied, cleared, or set as specified by an SA. The IPsec specification indicates that such fields must be controlled, to achieve security. Otherwise, such fields could provide 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" . To avoid a conflict between these rules, and to avoid security weaknesses associated with solely copying the fields, it is 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 always to 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 .
http://www.isi.edu/touch Lars Eggert NEC Network Laboratories Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 EMail: email@example.com URI: http://www.netlab.nec.de/ Yu-Shun Wang USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 US Phone: +1 310 822 1511 Fax: +1 310 823 6714 EMail: firstname.lastname@example.org URI: http://www.isi.edu/yushunwa
Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.