RE: why the SAs are unidirectional

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

At this point, it just comes down to what you want to name things. In IPsec,
an SA is unidirectional object with a 32 bit id, so we're stuck with that.
Since IKE does all its operations on pairs of SAs, it is very easy to create
a "Bidirectional SA" abstraction that has two 33 bit ids.

In our case, we went one step further and created a "Protection Suite"
abstraction, which is composed of all the ESP, AH, and IPCOMP SAs in both
directions. The fact that the protection suite is sent on the wire as a
bunch of individual SAs doesn't make much difference, implementation wise,
except that it's perhaps not the optimal encoding.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: Radia Perlman - Boston Center for Networking
> [mailto:Radia.Perlman@Sun.COM]
> Sent: Monday, February 18, 2002 3:59 PM
> To: sommerfeld@east.sun.com; 867@nu.edu.pk;
> andrew.krywaniuk@alcatel.com
> Cc: ipsec@lists.tislabs.com
> Subject: RE: why the SAs are unidirectional
>
>
> >>"867" (is that really your name? :-) ) asked why Ipsec SAs
> unidirectional.
> >>Bill Sommerfeld and Andrew Krywaniuk pointed out that it is useful
> >>to have separate keys, SPIs and sequence numbers in the two
> directions.
>
> There's no reason why you can't create a bidirectional SA
> with different
> SPIs, sequence numbers, and keys in the two directions. For
> instance, SSL
> has different keys for the two directions. IKEv1 should have
> but didn't.
>
> You really wouldn't want to create a true unidirectional SA, since it
> is hard to tell if it's a black hole. So IPsec SAs get
> created in pairs, and
> sometimes it's awkward to match up what the proper SA in the
> other direction
> is in case you'd want to send an error message.
>
> Radia
>
>