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). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
