Request for Comments: 3884 ISI
Category: Informational L. Eggert
NEC
Y. Wang
ISI
September 2004
Use of IPsec Transport Mode for Dynamic Routing
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
IESG Note
This document is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this document for
any purpose, and in particular notes that it has not had IETF review
for such things as security, congestion control or inappropriate
interaction with deployed protocols. The RFC Editor has chosen to
publish this document at its discretion. Readers of this document
should exercise caution in evaluating its value for implementation
and deployment.
Abstract
IPsec can secure the links of a multihop network to protect
communication between trusted components, e.g., for a secure virtual
network (VN), overlay, or virtual private network (VPN). Virtual
links established by IPsec tunnel mode can conflict with routing and
forwarding inside VNs because IP routing depends on references to
interfaces and next-hop IP addresses. The IPsec tunnel mode
specification is ambiguous on this issue, so even compliant
implementations cannot be trusted to avoid conflicts. An alternative
to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec
transport mode, which we call IIPtran. IPIP encapsulation occurs as
a separate initial step, as the result of a forwarding lookup of the
VN packet. IPsec transport mode processes the resulting (tunneled) IP
packet with an SA determined through a security association database
(SAD) match on the tunnel header. IIPtran supports dynamic routing
inside the VN without changes to the current IPsec architecture.
IIPtran demonstrates how to configure any compliant IPsec
implementation to avoid the aforementioned conflicts. IIPtran is
also compared to several alternative mechanisms for VN routing and
their respective impact on IPsec, routing, policy enforcement, and
interactions with the Internet Key Exchange (IKE).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document History . . . . . . . . . . . . . . . . . . . . 3
2. Problem Description. . . . . . . . . . . . . . . . . . . . . . 4
2.1. IPsec Overview . . . . . . . . . . . . . . . . . . . . . 5
2.2. Forwarding Example . . . . . . . . . . . . . . . . . . . 6
2.3. Problem 1: Forwarding Issues . . . . . . . . . . . . . . 7
2.4. Problem 2: Source Address Selection . . . . . . . . . . 8
3. IIPtran: IPIP Tunnel Devices + IPsec Transport Mode . . . . . 9
3.1. IIPtran Details . . . . . . . . . . . . . . . . . . . . 10
3.2. Solving Problem 1: Forwarding Issues . . . . . . . . . . 11
3.3. Solving Problem 2: Source Address Selection . . . . . . 12
4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Other Proposed Solutions . . . . . . . . . . . . . . . . 12
4.1.1. Alternative 1: IPsec with Interface SAs. . . . . 13
4.1.2. Alternative 2: IPsec with Initial
Forwarding Lookup. . . . . . . . . . . . . . . . 13
4.1.3. Alternative 3: IPsec with Integrated
Forwarding . . . . . . . . . . . . . . . . . . . 14
4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. VN Routing Support and Complexity . . . . . . . 14
4.2.2. Impact on the IPsec Architecture . . . . . . . . 15
4.2.3. Policy Enforcement and Selectors . . . . . . . . 16
4.2.4. IKE Impact . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Summary and Recommendations . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21
A. Encapsulation/Decapsulation Issues . . . . . . . . . . . . . . 22
A.1. Encapsulation Issues . . . . . . . . . . . . . . . . . . 22
A.2. Decapsulation Issues . . . . . . . . . . . . . . . . . . 23
A.3. Appendix Summary . . . . . . . . . . . . . . . . . . . . 23
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. 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.)
IPsec can be used to secure the links of a virtual network (VN),
creating a secure VN. In a secure VN, trusted routers inside the
network dynamically forward packets in the clear (internally), and
exchange the packets on secure tunnels, where paths may traverse
multiple tunnels. Contrast this to the conventional ’virtual private
network’ (VPN), which often assumes that paths tend to traverse one
secure tunnel to resources in a secure core. A general secure VN
allows this secure core to be distributed, composed of trusted or
privately-managed resources anywhere in the network.
This document addresses the use of IPsec to secure the links of a
multihop, distributed VN. It describes how virtual links established
by IPsec tunnel mode can conflict with routing and forwarding inside
the VN, due to the IP routing dependence on references to interfaces
and next-hop IP addresses.
This document proposes a solution called IIPtran that separates the
step of IP tunnel encapsulation from IPsec processing. The solution
combines a subset of the current IPsec architecture with other
Internet standards to arrive at an interoperable equivalent that is
both simpler and has a modular specification.
Later sections of this document compare IIPtran to other proposals
for dynamic routing inside VPNs, focusing on the impact the different
proposals have on the overall IPsec architecture, routing protocols,
security policy enforcement, and the Internet Key Exchange (IKE)
[9][10]. An appendix addresses IP tunnel processing issues in IPsec
related to IPIP encapsulation and decapsulation.
This document assumes familiarity with other Internet standards
[1][2], notably with terminology and numerous acronyms therein.
1.2. Document History
This document was first issued as an Internet Draft on March 10,
2000, entitled "Use of IPSEC Transport Mode for Virtual Networks,"
and was first presented in the IPsec WG at the 47th IETF in Adelaide
in March 2000. It was subsequently revised and presented to the
PPVPN WG at the 51st IETF in London in August 2001, to the IPsec WG
at the 52nd IETF in Salt Lake City in December 2001, and to both the
IPsec and PPVPN WGs at the 53rd IETF in Minneapolis in March 2002.
Version 04 of this draft was submitted for publication as an
Informational RFC based on suggestions by the IPsec WG in June 2002,
and was under IESG review from then until version 07 was approved for
publication in June 2004. During that time, it was substantively
revised according to feedback from the IESG regarding interactions
with the IPsec specification (RFC 2401 [1]) and other protocols, with
regard to security and compatibility issues.
2. Problem Description
Virtual networks connect subsets of resources of an underlying base
network, and present the result as a virtual network layer to upper-
layer protocols. Similar to a real network, virtual networks consist
of virtual hosts (packet sources and sinks) and virtual routers
(packet transits), both of which can have a number of network
interfaces, and links, which connect multiple network interfaces
together. Virtual links (also called tunnels, especially when
point-to-point) are one-hop links in the VN topology, but are either
direct links or paths (sequences of connected links) in the
underlying base network.
Base network hosts and routers can be part of multiple virtual
networks at the same time, and their role in the base network does
not need to coincide with their role in a virtual network (i.e., base
network hosts may act as VN routers or hosts, as may base network
routers).
It is important to note that this definition of a VN is more general
than some other definitions, where the VN participation of end
systems is limited. Some proposals only allow end systems to be part
of a single VN, or even only allow them to be part of the VN and not
the base network, substituting the VN for the Internet. The
definition above explicitly allows hosts and routers to participate
in multiple, parallel VNs, and allows layered VNs (VN inside VN).
It can be useful for a VN to secure its virtual links [3][4],
resulting in a VPN. This is not equivalent to end-to-end security,
but can be useful when end hosts do not support secure communication
themselves. It can provide an additional level of hop-by-hop network
security to secure routing in the VPN and isolate the traffic of
different VPNs.
The topology of an IPsec VPN commonly consists of IPsec tunnel mode
virtual links, as required by the IPsec architecture when the
communicating peers are gateway pairs, or a host and a gateway [1].
However, this current required use of IPsec tunnel mode can be
incompatible with dynamic routing [3].
The next section provides a short overview on IPsec transport and
tunnel mode processing, as far as it is relevant for the
understanding of the problem scenarios that follow. The following
sections discuss routing problems in detail, based on a common
example.
2.1. IPsec Overview
There are two modes of IPsec, transport mode and tunnel mode [1].
Transport mode secures portions of the existing IP header and the
payload data of the packet, and inserts an IPsec header between the
IP header and the payload; tunnel mode adds an additional IP header
before performing similar operations. This section gives a short
overview of the relevant processing steps for both modes.
In transport mode, IPsec inserts a security protocol header into
outgoing IP packets between the original IP header and the packet
payload (Figure 1) [5][6][11][12]. The contents of the IPsec header
are based on the result of a "security association" (SA) lookup that
uses the contents of the original packet header (Figure 1, arrow) as
well as its payload (especially transport layer headers) to locate an
SA in the security association database (SAD).
Original Outbound Packet Outbound Packet (IPsec Transport Mode)
+-----------+---------+ +-----------+==============+---------+
| IP Header | Payload | | IP Header | IPsec Header | Payload |
+-----------+---------+ +-----------+==============+---------+
| ^
| |
+-------------+
SA Lookup
Figure 1: Outbound Packet Construction under IPsec Transport Mode
When receiving packets secured with IPsec transport mode, a similar
SA lookup occurs based on the IP and IPsec headers, followed by a
verification step after IPsec processing that checks the contents of
the packet and its payload against the respective SA. The
verification step is similar to firewall processing.
When using tunnel mode, IPsec prepends an IPsec header and an
additional IP header to the outgoing IP packet (Figure 2). In
essence, the original packet becomes the payload of another IP
packet, which IPsec then secures. This has been described [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,
as described in the remainder of this section.
In IPsec tunnel mode, the IP header of the original outbound packet
together with its payload (especially transport headers) determines
the IPsec SA, as for transport mode. However, a tunnel mode SA also
contains encapsulation information, including the source and
destination IP addresses for the outer tunnel IP header, which is
also based on the original outbound packet header and its payload
(Figure 2, arrows).
Outbound Packet (IPsec Tunnel Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ ^ | |
| | | |
| +--------------+ |
| SA Lookup |
| |
+---------------------------------+
IP Encapsulation
Figure 2: Outbound Packet Construction under IPsec Tunnel Mode
When receiving packets secured with tunnel mode IPsec, an SA lookup
occurs based on the contents of the IPsec header and the outer IP
header. Next, the packet is decrypted or authenticated based on its
IPsec header and the SA, followed by a verification step that checks
the contents of the original packet and its payload (especially the
inner IP header and transport headers) against the respective SA.
2.2. Forwarding Example
Consider a VPN topology with virtual links established by IPsec
tunnel mode SAs, as would be required for compliance with [1]. Such
hop-by-hop security can be useful, for example, to secure VN routing,
and when legacy end systems do not support end-to-end IPsec
themselves.
Virtual routers in a VN need to forward packets the same way regular
Internet routers do: based on the destination IP address and the
forwarding table. These two determine the next hop IP address the
packet should be forwarded to (additional header fields and inner
headers can be used, e.g., in policy routing.)
In Figure 3, traffic arrives at gateway A on virtual link 1, having
come from any of the virtual hosts upstream of that virtual link.
There are two outgoing virtual links for this incoming traffic: out
link 3 going to the VPN next-hop gateway B, and out link 4 going to
the VPN next-hop gateway C.
For this example, assume the incoming traffic is from a single VPN
source X, going to a single VPN destination Y. Ellipses (...)
represent multiple virtual links in Figure 3.
B ---...---
/ \
/ 3 \
/ \
X ---...--- A D ---...--- Y
1 2 \ /
\ 4 /
\ /
C ---...---
Figure 3: Topology of a Virtual Network
Two problems arise; one is forwarding of VN traffic over IPsec tunnel
mode links, the other is source address selection on VN end systems.
2.3. Problem 1: Forwarding Issues
Assume a packet from source X to destination Y arrives on link 2 at
gateway A. Gateway A now needs to both forward and encrypt the packet
to make progress to the next hop gateway inside the VPN.
Dynamically routed gateways forward packets based on a forwarding
table managed by a routing daemon that exchanges connectivity
information with directly connected peers by communicating on its
local interfaces. Entries in the forwarding table map destination IP
addresses to the IP address of a next-hop gateway and an associated
outbound interface.
The problem is that an intermediate router needs to pick a next hop
gateway for a transit packet based on its destination IP address and
the contents of the forwarding table. However, the IPsec
architecture does not define if and how tunnel mode SAs are
represented in the forwarding table.
The problem occurs when A tries to decide how to forward the packet
X->Y. In a regular IP network, this decision depends on a forwarding
lookup on destination address Y, which indicates the IP address of
the next-hop gateway and an associated outbound interface. In the
case of a VN, forwarding lookups occur on virtual destination
addresses. For the forwarding lookup on such a virtual destination
address to succeed, routes through virtual interfaces (tunnels) must
exist in the forwarding table.
There are two common implementation scenarios for tunnel mode SAs:
One is based on firewall-like packet matching operations where tunnel
mode SAs are not virtual interfaces, another is tunnel-based, and
treats a tunnel mode SA as a virtual interface. The current IPsec
architecture does not mandate one or the other.
Under the first approach, the presence of IPsec tunnel mode SAs is
invisible to the IP forwarding mechanism. The lookup uses matching
rules in the SA lookup process, closer to firewall matching than
traditional IP forwarding lookups, and independent from existing IP
forwarding tables. The SA lookup determines which virtual link the
packet will be forwarded over, because the tunnel mode SA includes
encapsulation information. This lookup and the subsequent tunnel
mode processing both ignore the contents of the existing IP
forwarding table, whether static or dynamic routing are used. This
type of tunnel mode processing is thus incompatible with dynamically
routed VPNs.
The second approach - requiring tunnel mode SAs to be interfaces -
can be compatible with dynamically routed VPNs (see Section 4)
depending on how it is implemented; however, IIPtran (see Section 3)
has the additional benefit of greatly simplifying the IPsec
architecture and related specifications, and of being compatible with
all IPsec specification compliant implementations.
2.4. Problem 2: Source Address Selection
A second issue is source address selection at the source host. When
an application sends traffic to another host, the host must choose an
IP source address for the IP packets before transmission.
When an end system is connected to multiple networks, it must set the
source address properly to receive return traffic over the correct
network. When a node participates in a virtual network, it is always
connected to two networks, the base network and the VN (more if it
connects to at least two VNs.) The IPsec specification currently does
not define how tunnel mode SAs integrate with source address
selection.
For example, when communication occurs over a virtual network, the
source address must lie inside the VN. When X sends to Y (Figure 3),
the source address must be the IP address of X’s local end of tunnel
1. If host A, which has multiple interfaces inside the VN, sends to
Y, the source address must be the IP address of the local end of
either tunnel 3 or 4.
Most applications do not bind to a specific source IP address, and
instead let the host pick one for their traffic [7]. Rules for
source address selection that depend heavily on the notions of
interfaces and routes.
According to [7], the IP source address of an outbound packet should:
(1) for directly connected networks derive from the corresponding
interface, or (2) derive from existing dynamic or static route
entries to the destination, or finally (3) derive from the interface
attached to a default gateway.
Because IPsec tunnel mode SAs are not required to be interfaces,
rules (1) and (2) may not return a usable source address for a given
packet. Consequently, VN packets will use the IP address of the
local interface connecting to a default gateway as their source
address. Often, a default gateway for a host provides connectivity
in the base network underlying the VN. The outgoing packet will thus
have a source address in the base network, and a destination address
in the VN.
This can result in numerous problems, including applications that
fail to operate at all, firewalls and admission control failures, and
may even lead to compromised security. Consider two cases, one with
IPsec tunnels configured with no wildcard tunnel addresses, the other