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). -- Amir On Sun, Feb 16, 2020 at 5:30 PM Brandon Martin <lists.nanog@monmotha.net> wrote:
On 2/15/20 1:17 PM, Bart Hermans wrote:
Does someone know why these IPsec SAs are unidirectional?
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. -- Brandon Martin