10.5. Combining Security Associations

As mentioned above, it is sometimes useful to apply both AH and ESP to a VPN by combining multiple SAs into an SA bundle. In this section, we explore the ways in which we can combine AH and ESP and, more generally, how we can combine SAs to build complex VPNs.

The simplest situations combine AH and ESP in a single transport-mode VPN. This is called transport adjacency, and we illustrate the SAs involved and the encapsulation of the datagrams in Figure 10.7.

Figure 10.7. Transport Adjacency

[View full size image]

We use the same network diagram for each of the VPN configurations in this subsection. In some cases, such as Figure 10.7, parts of the network, such as the security gateways, play no part and may or may not be present.

Note that AH is applied after ESPthat is, AH is the "outer" protocol. This makes sense because we want to authenticate as much of the datagram as possible, including the ESP header.

The more general way of combining SAs to build VPNs is called iterated tunneling, which tunnels the result of a previous transport-mode VPN or a previous tunnel-mode VPN in another VPN. Let's examine some situations in which this makes sense.

Although RFC 2401 does not require that an implementation support it, we could imagine using iterated tunneling in the configuration of Figure 10.7. However, using iterated tunneling here provides no advantages over transport adjacency and requires one or two additional IP headers, depending on whether the outer SA tunnels a transport-mode SA or a tunnel-mode SA.

A more realistic example is shown in Figure 10.8: an end-to-end AH VPN in transport mode between H₁ and H₂. Between H₁ and GW₂, an ESP tunnel-mode VPN protects the privacy of H₁'s datagrams until they reach GW₂, which is presumably on the destination network.

Figure 10.8. Iterating Tunneling with a Shared Endpoint

[View full size image]

The IP headers in the encapsulation are labeled with their source (S) and destination (D) to help tie the two parts of the figure together.

We could have used tunnel mode for AH, but this would have added another IP header, with no advantage over using transport mode. The inner protocol could be ESP instead of AH, but there appears to be little utility in doing so, because an end-to-end ESP VPN would make the one between H₁ and GW₂ superfluous.

The two VPNs in Figure 10.8 share a common endpoint at H₁. Thus, H₁ must know about both VPNs and have an SA bundle that describes them. Our next configuration also has two VPNs, but they share no endpoints, as shown in Figure 10.9.

Figure 10.9. Iterated Tunneling with No Shared Endpoints

[View full size image]

In this case, both VPNs use ESP. This could easily happen because H₁ and H₂ might not be aware of the existence of the VPN between the security gateways. Of course, the VPNs could use either AH or ESP, depending on the security requirements they are meant to satisfy. It's also perfectly legal for the VPN between the two hosts to use tunnel mode, although as in the previous example, there is no utility in doing so.

There are many other wayssome legal, some illegalof nesting VPNs. The best way of deciding whether a proposed nesting is legal is to lay out the encapsulations as we have done here. If the encapsulations make sense, the nesting will probably work.

In particular, if the nesting doesn't have two or more of the VPNs sharing a common endpoint and if the encapsulation makes sense, the nesting will be legal.