Why are IPsec SAs unidirectional

Sun Feb 16 21:50:12 UTC 2020

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 at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200216/4142ab06/attachment.html>