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

[Tero Kivinen <[e-mail]>]

Paul Ponchon \(pponchon\) writes:
> > > Using different real child SA’s was needed to ensure the
> > > cryptographic security properties.
> 
> Is this requirement only based on not reusing the same IV on different cores
> or is there an additional factor I missed?

IV space and replay counter are the problem. It is just so much easier
to use different Child SAs per CPU and than trying to solve the IV
space problem.

On the G-IKEv2 we had to solve the splitting IV space to separate
senders, and that causes all kind of issues, and we have to disable
replay protection on those SAs.

Getting replay protection working on the Child SA that is shared by
multiple CPUs is much harder than creating separate Child SA for each
CPU. 

> > This is something that is really a important. The keymat between the
> > CPUs can't be same, but we could in theory create a new key hierarchy
> > that generates keys for each sub Child SAs for each CPU, but I think
> > that will just complicate things more, and having real Child SAs for
> > each cpu is the correct solution.
> 
> We're are currently facing some scalability issues with using
> multiple Child SAs and we think it is possible to reuse the same
> keymat on all the per cpu SAs.

There must be something wrong in your implementation. There should be
no scaling difference for each cpu in cases where there is one Child
SA per cpu with different keymat than cases where there is one Child
SA per cpu with same keymat than some other cpu has.

Or more likely the problem is its much harder to scale to make them
share keymat, as in that case each of the cpu needs to talk to all
other cpus to make sure they do not reuse the replay counter, or IV
space, and keep track of number of bytes transmitted etc.

If your Child SA is local to your cpu all those issues are localized
and there should not be any scaling issues.

There will be scaling issues when generating those Child SA through
IKEv2, but IKEv2 should be able to create hundreds of Child SAs per
second when using proper window size and not doing PFS on the Child
SAs.

If you are not implementing proper window size on IKEv2 then you are
limited to your RTT, i.e., if your RTT is 50 ms, then you can create
dozen or so Child SA per second, as you need to wait each Child SA
packet before you can start new one.

All this is again not stable state scaling issue, all IKEv2 issues are
issues that should not affect stable state at all.

> For this to work and respect the uniqueness of the IV, some
> mechanism would be needed. But that can be implemented without
> per-packet locks for most ciphers (e.g., by splitting the IV space,
> or making bulk IV allocations). And we would also ensure that the
> keymat is used in a FIPS compliant manner.

I remember when we had discussion of the Implicit IV (RFC8750) people
were saying that it is not clear whether the IV generation must be
inside the fips boundary or not, and if so we are not allowed to bring
external data (sequence number) and generate IV from that as that
would violate the FIPS boundaries, meaning the FIPS boundary would
grow larger, and more of the implemenation needs to be FIPS certified,
not just the actual crypto.

If we are doing similar things here, same thing might happen, meaning
suddenly we need to start FIPS certifying the actual bulk IV
allocation process or something like that and that would mean much
larger boundary for FIPS certification. 

> Would there be any other concerns in reusing the same keymat between
> multiple SAs ?

Not really, but I do not also see any reason why there would be a need
to share KEYMAT between multiple SAs.

If the issues in the IKEv2 Child SA generation are overwhelming then
we can simply use the IKEv2 KEYMAT to create new per Child SA KEYMATs
for each CPU in the cryptographically safe way (i.e., make IKEv2
extension to do that).
-- 
[e-mail]