[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 03 04 05 06 07 rfc3884                                  
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]