INTERNET-DRAFT Joe Touch and Lars Eggert
draft-touch-ipsec-vpn-01.txt USC/ISI
Nov. 24, 2000
Expires: May 24, 2001
Use of IPSEC Transport Mode for Virtual Networks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except for the right to
produce derivative works.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document addresses the use of IPSEC to secure the virtual links
of an overlay network. It addresses how IPSEC tunnel mode can
conflict with dynamic routing in an overlay, due to the dependence of
both the security association (SA) and the IP tunnel encapsulation
header on the header of the incoming packet. An alternative is
proposed, where IP tunnel encapsulation occurs as a separate initial
step, followed by IPSEC transport mode on the result. The tunnel
header is determined by the source header, and the SA is determined
by the tunnel header. The result is consistent with dynamic routing
in the overlay. This document discusses this alternative and its
impact on IPSEC, including issues with IPSEC's IP encapsulation and
decapsulation (Appendix A).
This document is a product of the X-Bone project at USC/ISI [5] [6].
Comments are solicited and should be addressed to the author.
Introduction
Expires May. 24, 2001 [Page 1]
Touch and Eggert IPSEC Transport Mode for VPNs Nov. 24, 2000
The IP security architecture, IPSEC, consists of two modes, transport
mode and tunnel mode. Transport mode is recommended end-to-end only,
and tunnel mode is recommended for so-called "bump in the stack"
uses. One such common use for the latter is to support overlay or
virtual networks (VPNs), where the links of an overlay are secured
via IPSEC. Tunnel-mode IPSEC complicates the use of dynamic routing
in virtual networks, by linking SA selection with route selection.
This document discusses this deficiency, and an alternative
architecture which separates the act of tunnel encapsulation from
IPSEC processing. It also discusses the impact of this alternate use
of IPSEC on the IP security architecture. An appendix also indicates
some issues with IPIP processing in IPSEC, notably issues with IPSEC
encapsulation and decapsulation processing.
This document assumes familiarity with [1], notably with terminology
and numerous acronyms therein.
Background
There are two modes of IPSEC, transport mode and tunnel mode [1]. In
transport mode, IPSEC augments outgoing IP packets with a security
protocol header (Fig. 1) [2] [3]. The IPSEC header determined by the
original packet, and security information indexed by the packet's
header (Fig. 1, arrow). (transport mode may look at transport
headers, but that is not critical to this discussion).
Original packet: IPSEC transport mode outgoing packet:
+-------+--------+ +-------+*******+--------+
| Data | IP Hdr | | Data | IPSEC | IP Hdr |
+-------+--------+ +-------+*******+--------+
^ |
| |
+-------+
FIGURE 1: IPSEC transport mode
Tunnel mode IPSEC augments outgoing IP packets with the same security
protocol header, but it is placed outside the original packet, and an
additional IP header is placed in front (Fig. 2). This has been
described as 'transport mode applied to an IP tunnel', however, there
are significant differences between the two.
+-------+--------+*******+************+
| Data | IP Hdr | IPSEC | tun IP Hdr |
+-------+--------+*******+************+
| ^ | ^
| #1 | | #2 |
+-------+ +--------+
Expires May. 24, 2001 [Page 2]
Touch and Eggert IPSEC Transport Mode for VPNs Nov. 24, 2000
FIGURE 2: IPSEC tunnel mode
In IPSEC tunnel mode, the original packet (primarily its IP header)
determines the IPSEC SA, which in turn determines the source and
destination addresses in the outer, tunnel header (Fig. 2, arrows).
In an IPIP tunnel, the tunnel header is determined by the inner
header (Fig 3.) [4]. If a subsequent transport mode IPSEC were
performed on the same packet, the IPSEC header would be computed
based on the outer, tunnel header (Fig. 4). Contrast this with Fig.
2, in which the IPSEC header is determined by the innder IP header.
+-------+--------+************+
| Data | IP Hdr | tun IP Hdr |
+-------+--------+************+
| ^
| |
+----------+
FIGURE 3: IPIP tunnel
+---------+
| #2 |
v |
+-------+--------+*******+************+
| Data | IP Hdr | IPSEC | tun IP Hdr |
+-------+--------+*******+************+
| ^
| #1 |
+------------------+
FIGURE 4: IPIP tunnel + transport mode IPSEC
Despite the difference in how the source determines when to use these
two modes, IPSEC tunnel and IPIP + IPSEC transport (IIPtran). The
two can interoperate, given appropriate configurations. The next
section describes why the difference is important.
Use of IPSEC in an Overlay
Overlay networks connect subsets of resources of an existing,
underlying network, and present the result as a virtual network layer
to upper-layer protocols. Overlays rely on tunnels to provide virtual
links where two resources are not directly connected in the
underlying network; these tunnels represent links in the overlay, but
are paths (sequences of connected links) in the existing, underlying
network.
Expires May. 24, 2001 [Page 3]
Touch and Eggert IPSEC Transport Mode for VPNs Nov. 24, 2000
It can be useful for overlay networks to provide IPSEC over these
virtual links [6]. This does not provide end-to-end security, but can
provide an additional level of network security, enabling gateways in
the overlay to prevent or slow down denial of service attacks. It can
also enable privacy on the multiple hops of a virtual link. In all
cases, IPSEC in an overlay network secures only the links of the
overlay.
IPSEC and Dynamic Routing
IPSEC requires that overlay links, links between gateways or links
between a host and a gateway, use tunnel-mode IPSEC. Tunnel-mode can
be incompatible with dynamic routing.
Consider an overlay with IPSEC'd virtual links, as in Figure 5.
Traffic arrives at gateway A from a variety of overlay hosts, on
virtual link #1. There are two outgoing links for this incoming
traffic: out #2 going to the overlay next-hop gateway B, and out #3
going to the overlay next-hop gateway C. For this example, assume
the incoming traffic is from a single overlay source X, going to a
single overlay destination Y. In this figure, multiple virtual links
are represented by elipses (...).
B ...
/ \
/#2 \
/ \
X --...--> A D --...--> Y
#1 \ /
\#3 /
\ /
C ...
FIGURE 4: Overlay with dynamic routing
In an overlay, it is useful to have per-link keys. Using a single key
for multiple links can compromise key security. In this case, link
#2 and link #3 have different keys, K2 and K3 respectively.
The problem occurs when a packet arrives on link #1 at A. The packet
is addressed from X to Y, and A needs to both route and encrypt it.
The current IPSEC gateway rules require that link #2 and link #3 be
tunnel-mode IPSEC, in which case, the incoming packet and security
database alone determine the key and tunnel header. However, A cannot
determine which key to use without first determining which route the
packet will take; outgoing interface does not appear to be required
in the security databases. As a result, A cannot know which key to
use. Furthermore, the virtual links differ in their tunnel headers;
Expires May. 24, 2001 [Page 4]
Touch and Eggert IPSEC Transport Mode for VPNs Nov. 24, 2000
again, A cannot know which tunnel header to use until the route is
determined, and neither route nor outgoing interface are a required
part of the IPSEC security database.
Existing Solutions
In order to use dynamic routing with IPSEC, either dynamic routing
must update the key database as it updates routes, or IPSEC tunnel
mode processing must be augmented to include outgoing interface
and/or route as additional context, and use this context to index the
key databases.
It is difficult to incorporate key management with dynamic routing.
The key database would need to become an extension of the routing
table. It would be necessary and difficult to synchronize changes to
the routing table with changes to the key database. This would
require linking key management with dynamic routing in ways that
encumber both systems.
Alternately, IPSEC key databases could be augmented to include
interface information in the security databases. This has been the
case in some implementations, where IPSEC keying is a function bound
to a virtual interface. While this is feasible, it would need to be
required to support dynamic routing in virtual networks. Such
interfaces are typically not required in protocol specifications, as
they too specifically require implementation details.
Alternative Solution
An alternate solution is to relax the IPSEC requirement that transit
traffic (gateway-gateway and host-gateway) use tunnel-mode IPSEC, and
to allow IIPtran. It is already recognized that IPSEC tunnel mode is
similar to IIPtran.
IIPtran processing allows a gateway to use outgoing interface
information to determine the tunnel header, and allows the IPSEC
header to either rely solely on the tunnel header, or on the tunnel
header and the inner header as desired (because transport mode may
examine the inner packet headers) [5] [6].
Issues
The primary issue is that of potential differences between the two
techniques for supporting IPSEC in overlays, interoperation of the
two, and the architectural impact on IPSEC.
Differences
Expires May. 24, 2001 [Page 5]
Touch and Eggert IPSEC Transport Mode for VPNs Nov. 24, 2000
On sending a packet, IPSEC tunnel mode may include unchanging
portions of the incoming packet's IP header and the data in its hash.
It is not clear whether IPSEC tunnel mode can also use the
information from the tunnel header it adds, but this is moot, since
it can incorporate it into the key when the key is computed. IIPtran
can examine the same portions of the header, and thus result in the
same hash.
On receiving a packet, both techniques decrypt or authenticate the
packet using the same technique. IPSEC tunnel mode can adds an
additional check of the inner header, that it matches a specified
value or range, thus, in one step, tossing the packet even though it
unwraps successfully.
Use of IPSEC transport mode in IIPtran can do similar checks of the
inner packet, as if it were a transport header, and drop the packet
if it violates a specified value or range.
The primary difference is in the subsequent processing of the
incoming packet. IPSEC tunnel mode does not require a separate rule
for accepting packets with the inner header; once they are accepted
during the unwrap phase, they are accepted. IIPtran requires that
unwrapped packets be further processed by an additional round, which
requires that incoming packets with these headers be accepted. As
noted in [1], IPSEC processing should retain SA use for subsequent
IPSEC or firewall processing. It should be possible for these
incoming packets to be IPIP decapsulated _only_ where the appropriate
SA has been used, but as a separate step.
However, we note that the two techniques are interoperable [5]. It
may be possible, if not preferable, to apply IIPtran processing for
outgoing packets, and IPSEC tunnel mode processing for incoming
packets. Experiments have verified that this is possible, notably
because, given appropriate keys, there are no differences in the
resulting packets on the wire, excepting as described in the appendix
of this document [5].
There is an additional issue with decapsulation, however. When a
IPSEC'd packet arrives which includes an IPIP inner packet, it is not
possible to distinguish whether it was created using IPSEC tunnel
mode or IPSEC transport mode of an IPIP encapsulated packet. In both
cases, the outer header is IPSEC, and the protocol type of the inner
data is 4 (IP). IPSEC requires that, upon receiving a packet, the SPI
is indexed in the SPD to determine whether the association is tunnel
mode or transport mode. If the packet is tunnel mode, IPSEC MUST
decapsulate the packet at that point. If the packet is transport
mode, IPSEC MUST NOT decapsulate the packet, but rather pass the
decrypted packet on to subsequent IP processing. This processing may
Expires May. 24, 2001 [Page 6]
Touch and Eggert IPSEC Transport Mode for VPNs Nov. 24, 2000
include decapsulation by other means, including Mobile IP.
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-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-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 E2E use
of IPSEC either in an overlay or the base network; it only adds IPSEC
protection to secure overlay links.
Security Considerations
Security considerations are addressed in throughout this document, as
they are a primary concern of alternate uses of IPSEC.
Acknowlegments
The authors would like to thank the members of the X-Bone project at
USC/ISI for their contributions to the ideas behind this draft,
notably (current) Greg Finn, Amy S. Hughes, Yu-Shun Wang, Alper
Demir, and Ankur Sheth, and (past) Steve Hotz and Anindo Banerjea, as
well as the comments of various members of both the IPSEC and Mobile
IP IETF Working Groups.
Appendix A: Encapsulation / decapsulation issues
There are inconsistencies between the IPIP rules specified by IPSEC
and those specified by Mobile IP [1] [4]. The latter specification is
standards track, and the IP protocol number of 4 (payload of an IP
packet of type 4) is assigned by IANA to RFC2003 [4]. IPSEC does not
specify any limits on the types of IP packets which can be secured by
transport mode, so the use of IPIP inside an IPSEC transport packet
may be confused with IPSEC tunnel mode.
Expires May. 24, 2001 [Page 7]
Touch and Eggert IPSEC Transport Mode for VPNs Nov. 24, 2000
Encapsulation issues
When an IP packet is encapsulated inside another IP header, some of
the outer header fields can be written as new, and others are
determined by the inner IP packet [4]. Among these are the IP DF
(don't fragment) bit. When the inner packet DF bit is clear, the
outer packet MAY copy it or set it to 1; however, when the inner DF
bit is set to 1, the outer header MUST copy that bit [4]. IPSEC
provides conflicting rules, where that field, and other similar
fields (TOS, etc.) may be copied, cleared or set as specified by the
SA.
IPSEC must be able to control whether these bits are copied or not to
achieve security, otherwise, they present a covert channel between
the inner packet header and outer packet header. However, the RFC2003
requires that the outer bit not be cleared when the inner is 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 bits, this document
recommends that IPSEC IPIP encapsulation not permit the clearing of
the outer DF bit. When the SA requires cleared DF and the inner
packet DF is set, it is proposed that IPSEC drop that packet, rather
than violate RFC2003 processing criteria. Similar rules are being
developed for TOS and other similar IP header bits, to be presented
in an update of this document.
Decapsulation issues
As noted in "Differences," on pg. 6 of this document, an IPSEC packet
with a data of type 4 is ambiguous. It may indicate either a tunnel-
mode IPSEC packet, or a transport-mode IPSEC of an IPIP encapsulated
packet.
Incoming packet processing MUST check the SPD before determining
whether to decapsulate IPSEC packets with inner payload of protocol
type 4. If the SPD indicates this is a tunnel-mode association, IPSEC
MUST decapsulate the packet. If the SPD indicates that this is a
transport mode association, IPSEC MUST NOT decapsulate the packet.
Note that the SPD must indicate one of these two options; ambiguous
SPD 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).
Expires May. 24, 2001 [Page 8]
Touch and Eggert IPSEC Transport Mode for VPNs Nov. 24, 2000
References
[1] Kent, S., Atkinson, R., "Security Architecture for the Internet
Protocol," RFC-2401, Nov. 1998.
[2] Kent, S., Atkinson, R., "IP Authentication Header," RFC-2402,
Nov. 1998.
[3] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
(ESP)," RFC-2406, Nov. 1998.
[4] Perkins, C., "IP Encapsulation within IP," RFC-2003, Oct. 1996.
[5] Touch, J., "Dynamic Internet Overlay Deployment and Management
Using the X-Bone," Proc. ICNP, pp. 59-68.
http://www.isi.edu/xbone
[6] Touch, J., Hotz, S., "The X-Bone," Proc. Third Global Internet
Conference at Globecom, Sydney, Australia, Nov. 1998.
[7] Mogul, J., Deering, S., "Path MTU Discovery," RFC-1191, Nov.
1990.
[8] Lahey, K., "TCP Problems with Path MTU Discovery," RFC-2923,
Sept. 2000.
Author's Address
Joe Touch
University of Southern California/Information Sciences Institute
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
Email: touch@isi.edu
Attribution and Disclaimer
Effort sponsored by the Defense Advanced Research Projects Agency (DARPA)
and Air Force Research Laboratory, Air Force Materiel Command, USAF, under
agreement number F30602-98-1-0200. The U.S. Government is authorized to
reproduce and distribute reprints for Governmental purposes not withstanding
any copyright annotation therein.
The views and conclusions contained herein are those of the authors and
Expires May. 24, 2001 [Page 9]
Touch and Eggert IPSEC Transport Mode for VPNs Nov. 24, 2000
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 May. 24, 2001 [Page 10]