Why are IPsec SAs unidirectional

Mon Feb 17 01:16:37 UTC 2020

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