Dynamic Routing and IPsec in Virtual Networks

The X-Bone supports IPsec in the overlay using transport-mode IPsec, rather than tunnel-mode IPsec, as would be expected in an overlay. The combination of transport mode IPsec and an IPIP link tunnel allows the X-Bone to support dynamic routing over IPsec'ed links, which requires extraordinary coordination of key databases and routing tables if done in conventional (tunnel-mode) IPsec overlays.

Dynamic routing in an overlay network can interfere with the traditional use of IPsec to secure overlay links. IPsec authenticates or encrypts links in an X-Bone overlay. IPsec can interfere with forwarding decisions in overlay routers, however.

Consider a packet P entering router A, destined ultimately for host Z. There are two possible paths to Z, one through B, the other through C. The B path begins with an overlay link keyed with K1; the C path, with K2. Per-link keys are required for robustness, to avoid needlessly compromising keys.

In an implementation where IPsec processing precedes forwarding decisions, Router A must decide which key to use (K1 or K2) before it has decided which path to take (via B or via C). Some of the forwarding decisions (i.e., routing table) must then be represented in the IPsec rule base, so that packets destined for Z are tagged to use K1. The IPsec rules must reflect the current routing table, imposing configuration and synchronization effort on the routing protocol implementation. Current routing protocols do not support synchronous IPsec rule updates.

IPsec relies on policy databases to determine key usage and requires that keying precedes forwarding. This is not consistent with the use of per-hop keys and dynamic routing protocols. An alternative to binding keys to rules is to bind keys to virtual interfaces, as in the NIST Linux implementation. Keys are bound to links by conventional routing rules, rather than policy-based rules in a separate key database. This allows the key decision to come after forwarding. A forwards via B by using virtual interface V1; everything from V1 is encrypted with K1, then sent to B.

The X-Bone takes advantage of this scheme, even in systems that bind keys to IPsec rule bases. In the X-Bone, tunneling is decoupled from keying, and tunneling is always performed first.

In the example, V1 performs the link-layer encapsulation, and K1 would add the link key. This allows the IPsec rules to remain static, as in "encrypt everything wrapped in this overlay link header." Dynamic routing algorithms update the routing table, and determine which virtual interface, and, by consequence, which key. The X-Bone is the only known overlay system that integrates both IPsec support and dynamic routing.

This example highlights the issue of lost context: When an encapsulated packet is received, it is unwrapped, and forwarded by the router or demultiplexed to endpoint connections in the host. Forwarding and demultiplexing decisions do not depend on the state of the additional encapsulation headers; this state is discarded as it is removed, so is not available anyway. This means that the interior packet addresses must be globally unique, unless host kernel and router firmware modifications are made to support retaining this state. Uniqueness is per-component. Addresses can be reused on overlays that do not share components, i.e., that participate in both overlays. Routers that provide tunneling only (i.e., intermediate on the tunnel path) do not count as part of an overlay.