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]