Recently I did a dive into IPsec and the related RFCs describing the
techniques used to setup a site-to-site tunnel. The RFCs I've been
reading are quite clear. However, there's one thing I can't seem to put
my finger on. From what I know is that the phase 1 ISAKMP Security
Association (SA) is unidirectional. This tunnel is then used to setup
two unidirectional tunnels (https://tools.ietf.org/html/rfc4301 Section
4.1.).
Does someone know why these IPsec SAs are unidirectional? Usually the
RFC describes some reasoning behind certain design decisions. However, I
can't seem to find a justification other than "It's by design". On the
Internet however, I read that the two SA requirement is chosen from a
security perspective; If the key material of one of the SAs leaks, only
one way of the traffic can be inspected by a third party. The problem
with this reasoning is that I can't seem to find an additional source
claiming the same thing. Therefore, I'm not sure whether it's true.
I think there are a number of reasons. For example, anti-replay would be harder to implement on a bi- directional SA. Encryption and authentication algorithms may be asymmetric, so defining a bi-directional SA for those would be more complicated. For multicast, bi-directional also doesn’t make much sense, and there are potential cases where unicast could be purely unidirectional (though rare).
It’s not that you couldn’t define bi-directional SAs for those or other cases, but rather than make the definition of an SA more complicated to fit all of these different scenarios, simply do it the way it was done and define it as one-way, and if you need bi-directional traffic, use one each way.
I’m sure we have people much more familiar with the actual discussions that got us where we are on the list (probably some who participated in those discussions are here). They can give a definitive answer if they are so inclined.
My take on it:
* IP, on which IPSec is directly built, is not a bidirectional protocol. It is unidirection and fire-and-forget. There's no assumption made that the source address specified in a given packet is even reachable from the destination address (much to the chagrin of many network operators), though it's supposed to be the case that it is. Making SAs bidirectional would therefore represent something of a layering inversion which the IP suite has been surprisingly careful to avoid.
* While many protocols built on top of IP, including ISAKMP are bidirectional, not all are, so having unidirectional SAs is potentially useful especially in the case of e.g. multicast as another poster pointed out.
* ISAKMP is not the only way to key IPSec SAs. It's a fairly complex protocol and is separate from the base IPSec specifications. Someone could come up with another, possibly better way to do it. You can also key them manually. Again, projecting the nature of ISAKMP onto IPSec would be a layering violation and might inhibit future use cases of the latter.
* An IPSec SA itself is quite simple. Making it unidirectional is in-line with that notion and appears to have few consequences.
* An IPSec SPD is also unidirectional (one could argue that this is a mistake, but see all the above), and an SA follows directly from an SPD.
Bart asked,
Does someone know why these IPsec SAs are unidirectional? Usually the
RFC describes some reasoning behind certain design decisions. However, I
can’t seem to find a justification other than “It’s by design”. On the
Internet however, I read that the two SA requirement is chosen from a
security perspective; If the key material of one of the SAs leaks, only
one way of the traffic can be inspected by a third party. The problem
with this reasoning is that I can’t seem to find an additional source
claiming the same thing. Therefore, I’m not sure whether it’s true.
I like this question 
so I apologize for a lengthy response. Or, let’s give you a tl;dr version: for key separation and refresh, mainly for security considerations.
So:
-
The keys used in both directions should (preferably) be different, for security. You mentioned one reason, i.e., that the if one of them leaks, the other one will remain secure; I guess that’s true, although one may wonder about the scenarios in which only one of the two leaks, as they are used in same devices. A more relevant reason imho is that it may be easier to expose one of the two keys using cryptanalysis, e…g, since attacker can control the plaintext (chosen-plaintext) or can know the plaintext (known-plaintext). Yes, we all know that these are not the common attacks, still, IPsec is designed to defeat these too…
-
As Brandon mentioned, the SPIs in the two directions differ. No, that’s not a mistake. By keeping these different, we allow each party to choose the SPI of traffic sent to it (that’s how it works). This can be used for (1) efficiency - use predefined array of SPIs (think HW), (2) security - choose SPI randomly, defeating spoofed packets sent as part of DoS attack against IPsec tunnel (by off-path attacker).
-
And then there’s key management. When refreshing a key, or more precisely, changing a key due to exceeding max usage amount/period, we typically negotiate a new key and SPI. Once we got the `ack’ from the remote peer (with the new SPI), we can start using the new key, while our peer may still be using an old key to send traffic to us (in fact we have the flexibility of not changing both keys together, e.g., if changing based on amount of traffic).
BTW, I was actually around in the initial design, but I can’t claim to remember the process well enough to say these were exactly the reasons for this at the time; but these are the reasons I’m aware of (and I’ll love to learn if there are more or if any of these are incorrect).