using certain wildcards. In both cases, an application whose source
address is set by RFC 1122 [7] rules may send packets (e.g.) with the
source address of that host’s base network (via the default route)
and a destination address of the remote tunnel endpoint.
3. IIPtran: IPIP Tunnel Devices + IPsec Transport Mode
This section introduces a solution - called IIPtran - for the two
issues identified above. IIPtran replaces IPsec tunnel mode with a
combination of IPIP tunnel interfaces that support forwarding and
source address selection (as per RFC 2003 [2]), followed by IPsec
transport mode on the encapsulated packet.
The IPsec architecture [1] defines the appropriate use of IPsec
transport mode and IPsec tunnel mode (host-to-host communication for
the former, and all transit communication for the latter). IIPtran
appears to violate this requirement, because it uses IPsec transport
mode for transit communication.
However, for an IPIP tunnel between security gateways, the gateways
themselves source or sink base network traffic when tunneling - they
act as hosts in the base network. Thus, IPsec transport mode is also
appropriate, if not required, for encapsulated traffic, according to
[1].
As a result, replacing IPsec tunnel mode with IPIP tunnel devices and
IPsec transport mode is consistent with the existing architecture.
Furthermore, this does not compromise the end-to-end use of IPsec,
either inside a VPN or in the base network; it only adds IPsec
protection to secure virtual links.
The next sections will give a short overview of IPIP encapsulation,
and show it combines with IPsec transport mode processing. This
section will then discuss how IIPtran addresses each of the problems
identified above.
3.1. IIPtran Details
IIPtran uses IPIP tunnels (as defined in RFC 2003 [2]), followed by
IPsec transport mode on the encapsulated packet.
RFC 2003 [2] uniquely specifies IPIP encapsulation (placing an IP
packet as payload inside another IP packet.) Originally developed for
MobileIP, it has often been adopted when virtual topologies were
required. Examples include virtual (overlay) networks to support
emerging protocols such as IP Multicast, IPv6, and Mobile IP itself,
as well as systems that provide private networks over the Internet
(X-Bone [3] and PPVPN).
IPIP outbound packet processing, as specified by RFC 2003 [2],
tunnels an existing IP packet by prepending it with another IP header
(Figure 4.)
Outbound Packet (IPIP Tunnel)
+==================+-----------------+---------+
| Tunnel IP Header | Orig. IP Header | Payload |
+==================+-----------------+---------+
^ |
| |
+------------------+
IPIP Encapsulation
Figure 4: Outbound Packet Construction for IPIP Tunnel
IIPtran performs this IPIP processing as a first step, followed by
IPsec transport mode processing on the resulting IPIP packet (Figure
5.)
Outbound Packet (IPIP Tunnel + IPsec Transport Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ | ^ |
| | | |
| +---------------+ |
| SA Lookup |
| |
+----------------------------------+
IPIP Encapsulation
Figure 5: Outbound Packet Construction for IPIP Tunnel with IPsec
Transport Mode
A key difference between Figure 2 and Figure 5 is that in the
proposed solution, the IPsec header is based on the outer IP header,
whereas under IPsec tunnel mode processing, the IPsec header depends
on the contents of the inner IP header and payload (see Section 2.1).
However, the resulting VPN packet (Figure 5) on the wire cannot be
distinguished from a VPN packet generated by IPsec tunnel mode
processing (Figure 2); and the two methods inter-operate, given
appropriate configurations on both ends [3].
A detailed discussion of the differences between IIPtran, IPsec
tunnel mode, and other proposed mechanisms follows in Section 4. The
remainder of this section will describe how IIPtran combines IPIP
tunnel devices with IPsec transport mode to solve the problems
identified in Section 2.
3.2. Solving Problem 1: Forwarding Issues
Section 2.3 described how IP forwarding over IPsec tunnel mode SAs
breaks, because tunnel mode SAs are not required to be network
interfaces. IIPtran uses RFC 2003 IPIP tunnels [2] to establish the
topology of the virtual network. RFC 2003 [2] requires that IPIP
tunnels can be routed to, and have configurable addresses. Thus,
they can be references in node’s routing table (supporting static
routing), as well as used by dynamic routing daemons for local
communication of reachability information.
RFC 2003 [2] addressed the issue of inserting an IPsec header between
the two IP headers that are a result of IPIP encapsulation. IIPtran
provides further details on this configuration, and demonstrates how
it enables dynamic routing in a virtual network.
It is important to note that the RFC 2003 IPIP tunnels [2] already
provide a complete virtual network that can support static or dynamic
routing. The proposed solution of using IPIP tunnel with IPsec
transport mode decouples IPsec processing from routing and
forwarding. IIPtran’s use of IPsec is limited to securing the links
of the VN (creating a VPN), because IPsec (rightly) lacks internal
support for routing and forwarding.
3.3. Solving Problem 2: Source Address Selection
Section 2.4 gave an overview of IP source address selection and its
dependence on interfaces and routes.
Using RFC 2003 IPIP tunnel devices [2] for VN links, instead of IPsec
tunnel mode SAs, allows existing multihoming solutions for source
address selection [1] to solve source address selection in this
context as well. As indicated in Section 2.4, according to [1], the
IP source address of an outbound packet is determined by the outbound
interface, which is in turn determined by existing forwarding
mechanism. Because IPIP tunnels are full-fledged interfaces with
associated routes (as in Section 3.2 of [2]), the routes and address
selection as specified in [1] can also operate as desired in the
context of VN links.
4. Comparison
The previous sections described problems when IPsec tunnel mode
provides VPN links, and proposed a solution. This section introduces
a number of proposed alternatives, and compares their effect on the
IPsec architecture, routing, and policy enforcement, among others, to
IIPtran.
4.1. Other Proposed Solutions
This section gives a brief overview of a number of alternative
proposals that aim at establishing support for dynamic routing for
IPsec-secured VNs. The following section then compares these
proposals in detail.
Although some of the alternatives also address the issues identified
above, IIPtran alone also significantly simplifies and modularizes
the IPsec architecture.
4.1.1. Alternative 1: IPsec with Interface SAs
In the first alternative, each IPsec tunnel mode SA is required to
act as a full-fledged network interface. This SA interface acts as
the outbound interface of the virtual destination’s forwarding table
entry. IPsec dynamically updates the SA interface configuration in
response to SAD changes, e.g., caused by IKE negotiation.
This approach supports dynamic routing and existing source address
selection rules, but requires extensions to the IPsec architecture
that define tunnel mode SA interfaces and their associated management
procedures.
It would necessitate recapitulating the definition of the entirety of
RFC 2003 IPIP encapsulation [2], including the association of tunnels
with interfaces, inside IPsec. This defeats the modular architecture
of the Internet, and violates the specification of type 4 IP in IP
packets as being uniquely defined by a single Internet standard (it
is already standardized by [2]).
This solution also requires augmenting the IPsec specification to
mandate an implementation detail, one that may be difficult to
resolve with other IPsec designs, notably the BITS (bump-in-the-
stack) alternative. Although the current IPsec specification is
ambiguous and allows this implementation, an implementation-
independent design is preferable.
4.1.2. Alternative 2: IPsec with Initial Forwarding Lookup
A second alternative is the addition of an extra forwarding lookup
before IPsec tunnel mode processing. This forwarding lookup will
return a "virtual interface" identifier, which indicates how to route
the packet [13]. Due to a lack of concrete documentation of this
alternative at this time, proposed for an update pending to RFC 2401
[1], two variants are presumed possible:
In the first scenario, the extra forwarding lookup indicates the
outbound interface of the final encapsulated tunnel mode packet,
i.e., usually a physical interface in the base network. The tunnel
mode SA lookup following the forwarding lookup will occur in the
per-interface SAD associated with the respective virtual interface.
In the second scenario, the extra forwarding lookup returns an
outbound tunnel SA interface. This solution seems to be equivalent
to the one described above (Section 4.1.1), i.e., all tunnel mode SAs
must be interfaces, and is not discussed separately below.
4.1.3. Alternative 3: IPsec with Integrated Forwarding
In the third alternative, the routing protocols and forwarding
mechanisms are modified to consult both the routing tables and SADs
to make forwarding decision. To prevent IPsec processing from
interfering with routing, forwarding table lookup must precede SAD
lookup.
This approach supports dynamic routing, but requires changes to
routing mechanisms such that SAD contents are included in the route
exchanges. It is unclear how transport-layer selectors would affect
this approach.
4.2. Discussion
This section compares the three different alternatives and IIPtran
according to a number of evaluation criteria, such as support for VN
forwarding, or impact on the IPsec architecture.
4.2.1. VN Routing Support and Complexity
This section investigates whether the three alternatives and IIPtran
support VN routing, especially dynamic routing based on existing IP
routing protocols.
Both IIPtran (IPIP tunnels + transport mode) and alternative 1 (per-
SA interfaces) establish VN links as full-fledged devices that can be
referred to in the routing table, as well as used for local
communication by dynamic routing protocols. They both support static
and dynamic VN routing.
However, because the current IPsec architecture does not require
tunnel mode SAs to behave similarly to interfaces (some implementers
chose alternative 1, but it is not mandated by the specification),
alternative 1 requires extensions to the current IPsec architecture
that define the exact behavior of tunnel mode SAs. The proposed
solution does not require any such changes to IPsec, and for tunnels
RFC 2003 already specifies those requirements [2]. Furthermore,
addition of those requirements would be redundant and potentially
conflict with RFC 2003 [2].
Alternative 3 supports dynamic VN routing, but requires modifying
routing protocols and forwarding lookup mechanisms to act or
synchronize based on SAD entries. This requires substantial changes
to routing software and forwarding mechanisms in all participating
nodes to interface to the internals of IPsec; this would require
revising a large number of current Internet standards. It is also
not clear how tunnel mode SAs that specify port selectors would
operate under this scheme, since IP routing has no dependence on
transport-layer fields.
Alternative 2 does not support dynamic VN routing. The additional
forwarding lookup before IPsec processing is irrelevant, because
IPsec tunnel mode SAs are not represented as interfaces, and thus
invisible to IP routing protocols.
Additionally, the forwarding lookup suggested for alternative 2 is
not compatible with a weak ES model described in [1], which requires
both an outbound interface indicator as well as the IP address of the
next-hop gateway. For example, multiple tunnels can use the same
outgoing interface and thus same SAD. The forwarding lookup would
return only the interface; lacking the next-hop gateway, the correct
SAD entry cannot be determined. Given the next-hop gateway would not
help, because the SAD is not indexed by tunnel mode SA encapsulation
destination IP address.
Because alternative 2 fails to support VN routing, it will not be
discussed in the remainder of this section.
4.2.2. Impact on the IPsec Architecture
IIPtran recognizes that encapsulation is already a property of
interface processing, and thus relies on IPIP tunnel devices to
handle the IPIP encapsulation for VN links. Tunnel mode IPsec thus
becomes unnecessary and can potentially be removed from the IPsec
architecture, greatly simplifying the specification.
Alternative 1 requires SAs to be represented as full-fledged
interfaces, for the purpose of routing. SAD changes must furthermore
dynamically update the configuration of these SA interfaces. The
IPsec architecture thus needs extensions that define the operation of
interfaces and their interactions with the forwarding table and
routes.
Additionally, RFC 2401 [1] describes per-interface SADs as a
component of IPsec. When tunnel mode SAs themselves act as
interfaces, the function of per-interface SADs needs clarification as
follows:
First, each tunnel interface SAD must contain exactly one IPsec
tunnel mode SA. Transport mode SAs are prohibited, because they
would not result in IP encapsulation (the encapsulation header is
part of the tunnel mode SA, a transport mode SA would not cause
encapsulation), and thus lead to processing loops. Multiple tunnel
mode SAs are prohibited, because dynamic routing algorithms construct
topology information based on per-interface communication. Merging
different virtual links (tunnels) into a single SA interface can
cause routing events on one virtual link to apply incorrectly to
other links sharing an SA interface.
Second, only the SAD of physical interfaces may contain IPsec
transport mode SAs; otherwise, the current issues with VN routing
remain unsolved.
In summary, these restrictions cause the SADs of SA interfaces to
contain only tunnel mode SAs, and the SADs of regular interfaces to
contain only transport mode SAs. Thus, tunnel encapsulation
essentially becomes a unique property of the interface, and not
IPsec.
IIPtran already recognizes this property. Consequently, it uses IPIP
tunnels directly, and combines them with transport mode processing.
By eliminating the use of tunnel mode, it removes the need for
additional constraints on the contents of per-interface SAs.
4.2.3. Policy Enforcement and Selectors
On receiving a packet, both IPsec tunnel mode and IIPtran decrypt
and/or authenticate the packet with the same techniques. IPsec
tunnel mode decapsulates and decrypts the packet in a single step,
followed by a policy check of the inner packet and its payload
against the respective IPsec tunnel mode SA. IIPtran uses IPsec
transport mode to decrypt and verify the incoming packet, then passes
the decrypted IPIP packet on to RFC 2003 IPIP processing [2]. At
that point, IIPtran can support selector checks on both the header
and its payload using firewall mechanisms, similar to IPsec tunnel
mode processing.
The primary difference between the two is that IPsec tunnel mode does
not require a separate processing step for validating packets; once
IPsec accepts them during the policy check during decapsulation, they
are accepted. IIPtran requires additional processing on the
decapsulated packets, to validate whether they conform to their
respective IPsec policy.
As noted in Section 5.2 of the IPsec architecture document [1], IPsec
processing should retain information about what SAs matched a given
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. IIPtran accepts incoming VN packets only if they have
arrived over a specific IPIP tunnel that was secured with IPsec
transport mode, but as a separate step following IPIP decapsulation.
Note that IPsec tunnel mode and IIPtran are interoperable [3].
Experiments have verified this interoperability, notably because
there are no differences in the resulting packets on the wire, given
appropriate keys.
4.2.3.1. Selector Expressiveness
When looking up an SA for a given packet, IPsec allows selectors to
match on the contents of the IP header and transport headers.
IIPtran using existing IPsec cannot support transport header matches,
because SA lookup occurs before decapsulation. A small extension to
IPsec can address this issue in a modular way.
RFC 2401 [1] 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 known
IPsec "extension header." This recognizes that with IPIP
encapsulation, IP VNs use the base IP network as a link layer.
Although this small extension to IPsec is not explicitly required, it
is already implied.
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.
Note that in both cases, these policy enforcement rules violate
layering by looking at information other than the outermost header.
This is consistent with IPsec’s current use of port-based selectors.
The next section discusses that selectors may not be useful for
virtual networks.
4.2.3.2. Role of Selectors for VPNs
For secure VN links established via IPsec tunnel mode SAs, the
selectors for the inner (VN) source and destination IP addresses
often need to be wildcarded to support dynamic routing in a VN.
Thus, the limitation described in 4.2.3.1 (without the proposed
extension) may not be important in a VN scenario.
Consider a four-node VN with nodes A, B, C, and N (Figure 6).
Consider the case where N is either a new node joining an existing
VPN, or an existing node that had been disconnected and was just
rediscovered via dynamic routing.
In this example, A has IPsec tunnel mode SAs to B and C. If the
selectors for the virtual source and destination IP addresses for
those SAs are not wildcards, the SA needs to be dynamically modified
to permit packets from N to pass over the tunnels to B and C. This
becomes quickly impractical as VPN sizes grow.
B
/
/
/
N ------ A
\
\
\
C
Figure 6: Topology of a Virtual Network
Thus, IPsec selectors appear much less useful in a VPN scenario than
expected. A consequence might be that IIPtran - even without
extensions to support the full expressiveness of tunnel mode SA
selectors as described above - can still support the majority of VPN
scenarios.
One purpose of selectors matching on transport header content is
policy routing. Different SAs can apply to different applications,
resulting in different apparent virtual topologies. IIPtran supports
policy routing in a more modular way, by having existing policy
routing implementations forward traffic over multiple, parallel VNs.
IIPtran supports arbitrary IP-based policy routing schemes, while
policies are limited by the expressiveness of IPsec’s selectors in
the former case.
4.2.4. IKE Impact
The Internet Key Exchange (IKE) [9][10] is a protocol to negotiate
IPsec keys between end systems dynamically and securely. 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). Despite its name, IKE
also acts as a tunnel management protocol (when IPsec tunnel mode SAs
are configured), and negotiates security policies between the peers.
Alternatives 1 and 3 use existing IKE without changes.
One possible approach to use IKE with IIPtran is to negotiate a
tunnel mode SA, and then treat it as a transport mode SA against an
IPIP tunnel when communicating with conventional peers. For policies
that do not specify selectors based on transport-layer information,
this establishes interoperability.
However, since IIPtran eliminates IPsec tunnel mode, it could also
simplify IKE, by limiting it to its original purpose of key exchange.
A new tunnel management protocol (e.g., ATMP [8]) would set up IPIP
tunnels, use an as of yet unspecified second protocol to negotiate
security policy, and then use IKE to exchange keys for use with the
policy.
Current IKE operation would become a modular composition of separate
protocols, similar to how IIPtran modularizes IPsec by combining
existing Internet standards. For example, a VPN link creation could
follow these steps: (1) IKE negotiation in the base network to secure
(2) a subsequent tunnel management exchange [8] in the base network,
followed by (3) IKE exchanges over the established tunnel to create a
secure VPN link.
5. Security Considerations
This document addresses security considerations throughout, as they
are a primary concern of proposed uses of IPsec.
The primary purpose of this document is to extend the use of IPsec to
dynamically routed VPNs, which will extend the use of IPsec and, it
is hoped, increase the security of VPN infrastructures using existing
protocols.
6. Summary and Recommendations
This document presents a mechanism consistent with the current use of
IPsec which supports dynamic routing inside a virtual network that
uses IPsec to secure its links. It illustrates how current use of
IPsec tunnel mode can fail to support dynamic VN routing (depending
on the implementation), and compares IIPtran with several different