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. On Sun, Feb 16, 2020 at 12:17 PM Bart Hermans <bart.hermans@os3.nl> wrote:
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.