RFC 3884
Use of IPsec Transport Mode for Dynamic Routing
RFC 3884: Use of IPsec Transport Mode for Dynamic Routing 🦋
Okay bestie, this one is from September 2004 and it's written by J. Touch (ISI), L. Eggert (NEC), and Y. Wang (ISI) 🫶. It's published in the Network Working Group and its category is Informational 🌸. It doesn't obsolete or update anything, since there are no Obsoletes or Updates lines in the header.
Status of This Memo ✨
So this memo gives information to the Internet community 💅. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈.
Copyright Notice 🎀
Copyright (C) The Internet Society (2004) 💜.
IESG Note 🙈
Okay, this one's important. 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 the authors call IIPtran ✨. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet 🧚. IPsec transport mode then 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 👑. It 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 . . . . . . . . . . . . . . . . . . . 251. Introduction 🌈
Okay so IPsec is made 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" (an intermediate system that implements IPsec functionality, e.g., a router.) 🚪
IPsec can be used to secure the links of a virtual network (VN), which creates 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 🧚. Compare that 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 lets this secure core be distributed, made up of trusted or privately-managed resources anywhere in the network 🦋.
This document is all about using 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, because IP routing depends 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 compare IIPtran to other proposals for dynamic routing inside VPNs 🔥. They focus on the impact each proposal has on the overall IPsec architecture, routing protocols, security policy enforcement, and the Internet Key Exchange (IKE) [9][10] 💅. There's also an appendix that covers IP tunnel processing issues in IPsec related to IPIP encapsulation and decapsulation 🌸.
This document assumes familiarity with other Internet standards [1][2], especially their terminology and the many acronyms in them 🍓.
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 then 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 📮. It was under IESG review from then until version 07 was approved for publication in June 2004 ⭐. During that time it got a big glow-up, substantively revised according to feedback from the IESG about 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 🌸. Like a real network, a virtual network is made of virtual hosts (packet sources and sinks) and virtual routers (packet transits), both of which can have a number of network interfaces 🦋. It also has 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 they're 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 doesn't need to match their role in a virtual network 💖. For example, base network hosts may act as VN routers or hosts, and base network routers may do the same 👑.
It's important to note that this definition of a VN is more general than some other definitions, where 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 it allows layered VNs (a VN inside a VN) 🌈.
A VN can find it useful to secure its virtual links [3][4], which results in a VPN 🔐. This isn't the same as end-to-end security, but it can be useful when end hosts don't support secure communication themselves 🫶. It can provide an additional level of hop-by-hop network security, which secures routing in the VPN and isolates 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 required use of IPsec tunnel mode can be incompatible with dynamic routing [3] 💀.
The next section gives a short overview of IPsec transport and tunnel mode processing, as far as it matters for understanding the problem scenarios that follow ✨. The sections after that dig into the routing problems in detail, based on a common example 🔥.
2.1. IPsec Overview
okay so 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 doing similar operations. This section gives a quick overview of the relevant processing steps for both modes 💅✨
In transport mode, IPsec slides 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 come from a "security association" (SA) lookup. That lookup uses the contents of the original packet header (Figure 1, arrow) as well as its payload (especially transport layer headers) to find an SA in the security association database (SAD) 🔍
Figure 1 looks like this:
Original Outbound Packet Outbound Packet (IPsec Transport Mode)
+-----------+---------+ +-----------+==============+---------+
| IP Header | Payload | | IP Header | IPsec Header | Payload |
+-----------+---------+ +-----------+==============+---------+
| ^
| |
+-------------+
SA LookupFigure 1: Outbound Packet Construction under IPsec Transport Mode
When a packet secured with IPsec transport mode comes in, a similar SA lookup happens based on the IP and IPsec headers. After that comes a verification step, once IPsec processing is done, 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) 🌸. Basically the original packet becomes the payload of another IP packet, and then IPsec secures that. This has been described [1] as "a tunnel mode SA is essentially a [transport mode] SA applied to an IP tunnel." However, there are big differences between the two, as the rest of this section explains 👑
In IPsec tunnel mode, the IP header of the original outbound packet, together with its payload (especially transport headers), determines the IPsec SA, same as transport mode. But a tunnel mode SA also holds encapsulation information, including the source and destination IP addresses for the outer tunnel IP header. That outer header is also based on the original outbound packet header and its payload (Figure 2, arrows) 💖
Figure 2 looks like this:
Outbound Packet (IPsec Tunnel Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ ^ | |
| | | |
| +--------------+ |
| SA Lookup |
| |
+---------------------------------+
IP EncapsulationFigure 2: Outbound Packet Construction under IPsec Tunnel Mode
When a packet secured with tunnel mode IPsec comes in, an SA lookup happens 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. Then comes 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
okay picture a VPN topology with virtual links set up by IPsec tunnel mode SAs, which is what you'd need to comply with [1] 🌈. This kind of hop-by-hop security can be useful, for example, for securing VN routing, and when legacy end systems don't 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. Those two determine the next hop IP address the packet should go to (additional header fields and inner headers can be used too, 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 (...) stand for multiple virtual links in Figure 3 ⭐
Figure 3 looks like this:
B ---...---
/ \
/ 3 \
/ \
X ---...--- A D ---...--- Y
1 2 \ /
\ 4 /
\ /
C ---...---Figure 3: Topology of a Virtual Network
Two problems pop up here. 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
okay so assume a packet from source X to destination Y shows up 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 daemon swaps connectivity info with directly connected peers by talking over 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 🌸
Here's the problem: 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 happens 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 gives the IP address of the next-hop gateway and an associated outbound interface. In the case of a VN, forwarding lookups happen 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. The other 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, which is closer to firewall matching than traditional IP forwarding lookups, and it's 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 is used. So this type of tunnel mode processing is 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's 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 so it can receive return traffic over the correct network. When a node participates in a virtual network, it's 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 happens 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 don't bind to a specific source IP address. Instead they let the host pick one for their traffic [7] 🍓 Rules for source address selection 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. As a result, 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 cause numerous problems, including applications that fail to operate at all, firewall and admission control failures, and it may even lead to compromised security 💀🔥 Consider two cases: one with IPsec tunnels configured with no wildcard tunnel addresses, and the other 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 ✨
okay so this section is where the solution finally shows up 🎀 It's called IIPtran, and it fixes the two problems we just went through. The big move is swapping IPsec tunnel mode for a combo of IPIP tunnel interfaces that do forwarding and source address selection (as per RFC 2003 [2]), and then running IPsec transport mode on the encapsulated packet 🦋
Now, the IPsec architecture [1] is pretty specific about when you use transport mode and when you use tunnel mode. Transport mode is for host-to-host traffic, and tunnel mode is for all the transit traffic 💅 So at first glance IIPtran looks like it's breaking the rules, because it uses transport mode for transit traffic. 💀
BUT (and this is the plot twist 🌈), for an IPIP tunnel between security gateways, the gateways are the ones sourcing or sinking the base network traffic while they're tunneling. They're basically acting like hosts in the base network. So transport mode is also appropriate for the encapsulated traffic, and if anything it's required, according to [1] ✨
So replacing IPsec tunnel mode with IPIP tunnel devices plus IPsec transport mode is actually consistent with the existing architecture 🫶 And it doesn't mess up end-to-end IPsec, whether that's inside a VPN or in the base network. It just adds IPsec protection to the secure virtual links. Main character energy for the architecture, no notes 👑
Next up, I'll give a quick overview of IPIP encapsulation and show how it teams up with IPsec transport mode processing. Then this section will go through how IIPtran handles each problem from above 💖
3.1. IIPtran Details
IIPtran uses IPIP tunnels (as defined in RFC 2003 [2]), followed by IPsec transport mode on the encapsulated packet 🧚
Okay, so RFC 2003 [2] is the one that actually specifies IPIP encapsulation, which means putting an IP packet as the payload inside another IP packet 📦 It was originally made for MobileIP, and it's been picked up a lot whenever people need virtual topologies. Examples include virtual (overlay) networks for newer protocols like IP Multicast, IPv6, and Mobile IP itself, plus systems that build private networks over the Internet (X-Bone [3] and PPVPN) 🌸
IPIP outbound packet processing, as laid out by RFC 2003 [2], tunnels an existing IP packet by sticking another IP header in front of it (Figure 4.) 🎀
Outbound Packet (IPIP Tunnel)
+==================+-----------------+---------+
| Tunnel IP Header | Orig. IP Header | Payload |
+==================+-----------------+---------+
^ |
| |
+------------------+
IPIP Encapsulation
Figure 4: Outbound Packet Construction for IPIP TunnelIIPtran runs this IPIP processing as step one, and then does 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 ModeHere's the key difference between Figure 2 and Figure 5 🫣 In the proposed solution, the IPsec header is built off the outer IP header. With IPsec tunnel mode processing, though, the IPsec header depends on what's in the inner IP header and payload (see Section 2.1).
BUT, and this is the part that makes it click 💜, the VPN packet on the wire (Figure 5) looks exactly the same as a VPN packet from IPsec tunnel mode processing (Figure 2). You literally can't tell them apart from the outside. The two methods interoperate too, as long as both ends are configured properly [3] ✨
A deeper dive into how IIPtran, IPsec tunnel mode, and the other proposed mechanisms differ is coming up in Section 4. For the rest of this section, we'll look at how IIPtran combines IPIP tunnel devices with IPsec transport mode to solve the problems from Section 2 🦋
3.2. Solving Problem 1: Forwarding Issues
So, Section 2.3 covered how IP forwarding over IPsec tunnel mode SAs breaks 💔 The reason is that tunnel mode SAs aren't required to be network interfaces. IIPtran uses RFC 2003 IPIP tunnels [2] to set up the topology of the virtual network. RFC 2003 [2] says IPIP tunnels can be routed to and can have configurable addresses. That means they can be referenced in a node's routing table (which supports static routing), and dynamic routing daemons can use them to talk about reachability locally 🧚
RFC 2003 [2] also dealt with putting an IPsec header between the two IP headers that come from IPIP encapsulation. IIPtran goes deeper on this setup and shows how it makes dynamic routing work in a virtual network 🌈
It's really important to note that RFC 2003 IPIP tunnels [2] already give you a complete virtual network that can handle static or dynamic routing 👑 Using IPIP tunnels with IPsec transport mode decouples IPsec processing from routing and forwarding. IIPtran only uses IPsec to secure the links of the VN (which is what makes it a VPN), because IPsec (rightly) doesn't have built-in support for routing and forwarding 🫶
3.3. Solving Problem 2: Source Address Selection
Section 2.4 gave the rundown on IP source address selection and how it depends on interfaces and routes 🎀
Using RFC 2003 IPIP tunnel devices [2] for VN links, instead of IPsec tunnel mode SAs, means the existing multihoming solutions for source address selection [1] can handle source address selection here too 💖 Like Section 2.4 explained, according to [1], the IP source address of an outbound packet is set by the outbound interface, and the outbound interface is set by the existing forwarding mechanism. Since IPIP tunnels are full-fledged interfaces with their own routes (as in Section 3.2 of [2]), the routes and address selection specified in [1] can work exactly as intended for VN links ✨
4. Comparison
The last few sections covered the problems with IPsec tunnel mode providing VPN links, and they proposed a solution 🌸 This section brings in a bunch of alternatives and compares them to IIPtran on things like the IPsec architecture, routing, and policy enforcement, among other stuff 💅
4.1. Other Proposed Solutions
This section gives a quick overview of several alternative proposals that all aim to support dynamic routing for IPsec-secured VNs 🦋 The next section then compares these proposals in detail.
Some of the alternatives also address the issues from above, but IIPtran alone also seriously simplifies and modularizes the IPsec architecture 👑
4.1.1. Alternative 1: IPsec with Interface SAs
In the first alternative, every IPsec tunnel mode SA has to act as a full-fledged network interface 🧚 This SA interface is the outbound interface of the virtual destination's forwarding table entry. IPsec updates the SA interface configuration dynamically whenever the SAD changes, for example because of IKE negotiation 🔥
This approach supports dynamic routing and the existing source address selection rules, but it needs extensions to the IPsec architecture that define tunnel mode SA interfaces and their management procedures 💀
It would mean re-describing all of RFC 2003 IPIP encapsulation [2], including tying tunnels to interfaces, inside IPsec. That defeats the modular architecture of the Internet, and it goes against the spec for type 4 IP in IP packets being uniquely defined by one Internet standard (it's already standardized by [2]) 🙈
This solution also means changing the IPsec spec to mandate an implementation detail, and that could be hard to reconcile with other IPsec designs, especially the BITS (bump-in-the-stack) alternative 😭 The current IPsec spec is ambiguous and does allow this implementation, but an implementation-independent design is the better choice ✨
4.1.2. Alternative 2: IPsec with Initial Forwarding Lookup
The second alternative adds an extra forwarding lookup before IPsec tunnel mode processing 🌈 This forwarding lookup returns a "virtual interface" identifier, which says how to route the packet [13]. There isn't much concrete documentation for this alternative yet, since it's proposed as an update pending to RFC 2401 [1], so two variants are assumed to be possible 🫶
In the first scenario, the extra forwarding lookup gives the outbound interface of the final encapsulated tunnel mode packet, which is usually a physical interface in the base network 🦋 The tunnel mode SA lookup after the forwarding lookup happens in the per-interface SAD for the matching virtual interface.
In the second scenario, the extra forwarding lookup returns an outbound tunnel SA interface 💅 This seems equivalent to the solution in Section 4.1.1, meaning all tunnel mode SAs have to be interfaces, so it isn't discussed separately below.
4.1.3. Alternative 3: IPsec with Integrated Forwarding
In the third alternative, the routing protocols and forwarding mechanisms get changed so they check both the routing tables and the SADs when making a forwarding decision 🧠 To keep IPsec processing from messing with routing, the forwarding table lookup has to come before the SAD lookup 🎀
This approach supports dynamic routing, but it needs changes to routing mechanisms so SAD contents get included in route exchanges 🌸 It's unclear how transport-layer selectors would affect this approach 🤔
4.2. Discussion
This section compares the three alternatives and IIPtran using a bunch of evaluation criteria, like support for VN forwarding or impact on the IPsec architecture 🔥 ✨
4.2.1. VN Routing Support and Complexity ✨
Okay bestie, this part checks whether the three alternatives and IIPtran can actually do VN routing, especially dynamic routing based on existing IP routing protocols 🦋
Both IIPtran (IPIP tunnels + transport mode) and alternative 1 (per-SA interfaces) make VN links into full-fledged devices. That means they can be referred to in the routing table and used for local communication by dynamic routing protocols 💅 They both support static and dynamic VN routing 🌸
However, the current IPsec architecture doesn't require tunnel mode SAs to act like interfaces. Some implementers picked alternative 1, but the specification doesn't mandate it 🙈 So alternative 1 needs extensions to the current IPsec architecture that define the exact behavior of tunnel mode SAs. The proposed solution doesn't need any of those changes to IPsec, because for tunnels, RFC 2003 already specifies those requirements [2]. Adding them again would be redundant, and it could even conflict with RFC 2003 [2] 😭
Alternative 3 supports dynamic VN routing, but it needs routing protocols and forwarding lookup mechanisms that act or synchronize based on SAD entries 🔥 That means substantial changes to routing software and forwarding mechanisms in every participating node, so they can interface with the internals of IPsec. It would mean revising a large number of current Internet standards, which is a lot, ngl 💀 It's also unclear how tunnel mode SAs that specify port selectors would operate under this scheme, since IP routing doesn't depend on transport-layer fields at all 🤔
Alternative 2 does not support dynamic VN routing 💔 The extra forwarding lookup before IPsec processing doesn't help, because IPsec tunnel mode SAs aren't represented as interfaces. That makes them invisible to IP routing protocols 👻
Then there's the forwarding lookup suggested for alternative 2, which isn't compatible with the weak ES model described in [1]. That model requires both an outbound interface indicator and the IP address of the next-hop gateway 📍 For example, multiple tunnels can use the same outgoing interface, and therefore the same SAD. The forwarding lookup would only return the interface. Without the next-hop gateway, the correct SAD entry can't be determined. And the next-hop gateway wouldn't help anyway, because the SAD isn't indexed by tunnel mode SA encapsulation destination IP address 🫠
Because alternative 2 fails to support VN routing, it won't be discussed in the rest of this section 🙅♀️
4.2.2. Impact on the IPsec Architecture 🧩
IIPtran recognizes that encapsulation is already a property of interface processing. So it relies on IPIP tunnel devices to handle the IPIP encapsulation for VN links 🎀 That means tunnel mode IPsec becomes unnecessary, and it can potentially be removed from the IPsec architecture, which would greatly simplify the specification 😍
Alternative 1 requires SAs to be represented as full-fledged interfaces for the purpose of routing. SAD changes must also dynamically update the configuration of these SA interfaces 🔄 So the IPsec architecture needs extensions that define how interfaces operate and how they interact with the forwarding table and routes 🛠️
Also, RFC 2401 [1] describes per-interface SADs as a component of IPsec. When tunnel mode SAs act as interfaces themselves, the function of per-interface SADs needs clarifying, as follows ✨
First, each tunnel interface SAD must contain exactly one IPsec tunnel mode SA. Transport mode SAs are prohibited here, because they wouldn't result in IP encapsulation. The encapsulation header is part of the tunnel mode SA, so a transport mode SA would not cause encapsulation, and that would lead to processing loops 🌀 Multiple tunnel mode SAs are prohibited too, because dynamic routing algorithms build topology information from 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 the other links sharing that 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 mean the SADs of SA interfaces contain only tunnel mode SAs, and the SADs of regular interfaces contain only transport mode SAs. So tunnel encapsulation essentially becomes a unique property of the interface, and not of IPsec 💖
IIPtran already recognizes this property. That's why it uses IPIP tunnels directly and combines them with transport mode processing. By eliminating tunnel mode, it removes the need for extra constraints on the contents of per-interface SAs 👑
4.2.3. Policy Enforcement and Selectors 🔍
When a packet comes in, both IPsec tunnel mode and IIPtran decrypt and/or authenticate it using the same techniques 🔐 IPsec tunnel mode decapsulates and decrypts the packet in a single step. After that, it does 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 the payload using firewall mechanisms, similar to IPsec tunnel mode processing 🧁
The main difference is this: IPsec tunnel mode doesn't need a separate step to validate packets. Once IPsec accepts them during the policy check during decapsulation, they're accepted, full stop 🙌 IIPtran needs extra processing on the decapsulated packets to check 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 which 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, as it was when it first entered a machine, using the saved processing context at any time during inbound processing 📦 IIPtran accepts incoming VN packets only if they arrived over a specific IPIP tunnel that was secured with IPsec transport mode. But that check happens as a separate step after IPIP decapsulation 🫶
Note that IPsec tunnel mode and IIPtran are interoperable [3]. Experiments have verified this, mostly 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 lets selectors match on the contents of the IP header and the transport headers. IIPtran using existing IPsec can't support transport header matches, because the SA lookup happens before decapsulation 🙃 A small extension to IPsec can fix this in a modular way ✨
RFC 2401 [1] explicitly recognizes that the transport layer header may be nested several headers deep inside the packet. It allows a system to "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. So selectors that include port number information have to traverse the inner IP header (and possibly other headers) before they can match on the transport headers 🧭 IIPtran therefore 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 isn't explicitly required, it's already implied 💜
Recognizing IP as a valid transport layer over IP also lets selectors match on the contents of the inner ("transport") IP header. So 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 how 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 so that dynamic routing works in a VN 🌟 So the limitation described in 4.2.3.1 (without the proposed extension) may not matter much in a VN scenario 💅
Consider a four-node VN with nodes A, B, C, and N (Figure 6). Imagine 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 aren't wildcards, the SA needs to be dynamically modified to let packets from N pass over the tunnels to B and C. That quickly becomes impractical as VPN sizes grow 😵💫
B
/
/
/
N ------ A
\
\
\
C
Figure 6: Topology of a Virtual NetworkSo IPsec selectors look 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 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, which results 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 in the former case, policies are limited by the expressiveness of IPsec's selectors 💖 slay, bestie 💖
4.2.4. IKE Impact ✨
Okay so the Internet Key Exchange (IKE) [9][10] is the protocol that lets end systems negotiate IPsec keys dynamically and securely 🔐. It's not a strictly required component of IPsec, though, bestie. Two hosts can totally talk over IPsec without IKE if they've been manually keyed, like with manually keyed SAs 💅. 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 any changes 🌸.
One possible approach for using IKE with IIPtran is to negotiate a tunnel mode SA and then treat it as a transport mode SA against an IPIP tunnel when talking to conventional peers 🎀. For policies that don't specify selectors based on transport-layer information, this establishes interoperability, and that's lowkey iconic 🦋.
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. Then an as of yet unspecified second protocol would negotiate security policy, and after that IKE would exchange keys for use with the policy 🧚.
Current IKE operation would become a modular composition of separate protocols, which is giving the same energy as 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 🔒
Security is threaded through this whole document, because it's a primary concern for every proposed use of IPsec 😭. Literally every design choice here is tied to it, so keep your eyes open.
The main goal of this document is to extend the use of IPsec to dynamically routed VPNs. That extension is supposed to increase the security of VPN infrastructures, and it's hoped that this happens while still using existing protocols 🛡️.
6. Summary and Recommendations 📝
Here's the recap bestie 💖. This document presents a mechanism that stays consistent with the current use of IPsec and supports dynamic routing inside a virtual network that uses IPsec to secure its links. It shows how current use of IPsec tunnel mode can fail to support dynamic VN routing (depending on the implementation), and it compares IIPtran with several alternatives 👑.
The big finding is that IIPtran, a composite 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 modular 🌈. Iconic, honestly ✨.
7. Acknowledgments 🫶
The authors want to thank the members of the X-Bone and DynaBone projects at USC/ISI for their contributions to the ideas behind this document 🍓. Shoutout to (current) Greg Finn and (past) Amy Hughes, Steve Hotz and Anindo Banerjea 💜.
The authors would also like to thank Jun-ichiro (itojun) Hagino and the KAME project. They brought the IKE implications of this proposal to attention and implemented the mechanisms in this document in the KAME IPv6/IPsec network stack 🔥. Members of several IETF WGs (especially IPsec: Stephen Kent, PPVPN: Eric Vyncke, Paul Knight, various members of MobileIP) gave valuable input on the details of IPsec processing in earlier revisions of this document 🙈.
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" 🎀.
8. References 📚
8.1. Normative References
[1] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[3] Touch, J., "Dynamic Internet overlay deployment and management
using the X-Bone", Computer Networks Vol. 36, No. 2-3, July
2001.
[4] Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual
Internet Architecture", ISI Technical Report ISI-TR-570,
Workshop on Future Directions in Network Architecture (FDNA)
2003, March 2003.
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[7] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[8] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
2107, February 1997.8.2. Informative References
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[10] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in
Progress, January 2004.
[11] Kent, S., "IP Authentication Header", Work in Progress,
February 2004.
[12] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in
progress, February 2004.
[13] Kent, S., "Personal Communication", November 2002.
[14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[15] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923,
September 2000.Appendix A. Encapsulation/Decapsulation Issues 🧁
There are inconsistencies between the IPIP encapsulation rules specified by IPsec [1] and those specified by MobileIP [2]. The latter specification is standards track, and the IP protocol number of 4 (payload of an IP packet of type 4) is uniquely specified by RFC 2003 according to IANA [2]. The use of IPIP inside an IPsec transport packet can be confused with IPsec tunnel mode, because IPsec doesn't specify any limits on the types of IP packets that transport mode can secure 😵.
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, while the inner header determines some others [2]. One of these fields is the DF (do not fragment) flag. When the inner packet DF flag is clear, the outer packet may copy it or set it. When the inner DF flag is set, though, the outer header must copy it [2]. 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 specifies that such fields must be controlled to achieve security. Otherwise, such fields could provide a covert channel between the inner packet header and outer packet header. However, RFC 2003 [2] requires that the outer fields not be cleared when the inner ones are set, to prevent MTU discovery "black holes" [14][15] 🕳️.
To avoid a conflict between these rules, and to avoid security weaknesses associated with solely copying the fields, it is 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 [2]. Similar rules are being developed for TOS and other similar IP header fields, to be included in an update of RFC 2003 [2] 🛠️.
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 [2] ✨.
A.2. Decapsulation Issues
Given identical keys, a packet created by IPIP tunnel encapsulation combined with IPsec transport mode and an IPsec tunnel mode packet look identical on the wire 👀. So when an IPsec'ed packet arrives that contains an IPIP inner packet, it isn't possible to tell whether it was created using IPsec tunnel mode or using 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 the SA matching a received packet to indicate whether to apply tunnel mode or transport mode 🔍.
Incoming packet processing must check the SAD before deciding whether to decapsulate IPsec packets with inner payload of protocol type 4. If the SAD indicates that 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. This requires that the SAD indicate one of these two options. Wildcard SAD entries ("ANY", or "TUNNEL or TRANSPORT") can't be supported 🚫.
A.3. Appendix Summary
IPsec's use of IPIP encapsulation conflicts with the IPIP standard [2]. This issue is already being resolved in an update to RFC 2003, rather than by specifying a non-standard conforming variant of IPIP encapsulation inside IPsec 🌸.
Authors' Addresses 💌
Joe Touch
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
US
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Lars Eggert
NEC Network Laboratories
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 90511 43
Fax: +49 6221 90511 55
EMail: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Yu-Shun Wang
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
US
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: yushunwa@isi.edu
URI: http://www.isi.edu/yushunwaFull Copyright Statement ©
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 📜.
This document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙏.
Intellectual Property 💜
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 ⚖️.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 📬.
Acknowledgement 🎀
Okay bestie, this is the last bit 🥹 and it's a little thank-you note. Funding for the RFC Editor function is currently provided by the Internet Society 🌸 So the people keeping the RFC series running are getting support from them right now. That's so sweet 💖
📦 where this page comes from
- ietf: rfc3884 2004-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms