Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance

[Paul Wouters <[e-mail]>]

On Mon, 17 Oct 2022, Valery Smyslov wrote:

[leaving cache/linux implementation details to Steffen to answer]

> Another issue that is not clear from the draft -
> how per-CPU SAs are created. Consider the situation when
> an outgoing packet is handled by a CPU
> and there is no per-CPU Sa to handle it. Then, I assume,
> the fallback SA is used.

Yes.
> My question - in this
> case does this CPU additionally requests IKE
> to create a per-CPU SA for it?

Yes. In linux language, it would a per-CPU ACQUIRE to userland.

> If so, then
> what happens if the other side has indicated
> that no more per-CPU SAs is allowed -
> is it saved somewhere, so that future outgoing
> packets handled by CPUs with no per-CPU SA,
> don't trigger requests to create it anymore?

I think this is implementation specific. You could install an temporary
rule into the SPD that would give the fallback SA more priority than the
per-CPU policy installed, so it wouldn't generate ACQUIRES for a while.

Perhaps userland could also decide to terminate another per-CPU SA that
is idle. Although I think the advised policy is stated to install at
least one per-CPU SA per CPU (and allow a few more to catch any race
conditions and rekeys). Clearly, if for part of the connection, you are
using the fallback SA, you are running at suboptimal speed which is not
a situation you should remain in.

>> We don't require a fallback SA in the draft, we just recommend to have
>> one. So in that sense, once created, all SAs live their own live.
>
> Hmm, my impression from reading the draft is that it is not so:
>
> Section 3:
>
>   When negotiating CPU specific Child SAs, the first SA negotiated
>   either in an IKE_AUTH exchange or CREATE_CHILD_SA is called Fallback
>   SA.

Indeed. The idea is that no matter what, you can encrypt the packets and
send them, even if at sub-optimal speeds. We don't want packets to have
to wait another RTT for the per-CPU SA to establish. That would cause a
lot of issues (slow TCP retransmits, UDP application retransmits, etc).
Once the first SA is up, you have a working IPsec tunnel and no more
packets should be dropped or wait for SA's to establish.

>   The Fallback Child SA MUST NOT be deleted when idle, as
>   it is likely to be idle if enough per-CPU Child SAs are installed.
>
> I think that these BCP14 requirements make the fallback SA very special.

Yes it does. It ensures there is a fully working (albeit slow) IPsec
connection.

Paul