One document matched: draft-touch-ipsec-vpn-00.txt
INTERNET-DRAFT Joe Touch and Lars Eggert
draft-touch-ipsec-vpn-00.txt USC/ISI
March 10, 2000
Expires: Sept. 10, 2000
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.
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
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.
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 |
+-------+ +--------+
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.
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;
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
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 [5].
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.
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," (work in progress) http://www.isi.edu/xbone
[6] Touch, J., Hotz, S., "The X-Bone," Proc. Third Global Internet
Conference at Globecom, Sydney, Australia, Nov. 1998.
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-823-6714
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
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 Resaerch Laboratory, or the
U.S. Government.
| PAFTECH AB 2003-2026 | 2026-04-22 05:47:03 |