On Thu, 7 Dec 2023, Michael Rossberg wrote:
I would actually like to refrain from writing 2 * 1.024 keys from the control
plane to the data plane, just because a single IKE SA rekeyed...
If you rekey the IKE SA, there is no change to the Child SA's. The new
IKE SA inherits the existing Child SAs. So no 2 * 1024 new keys.
May be I did not use the correct terms, but if I want to have PFS, I’d still
need reestablish all of these 2048 keys.
No. PFS means that if you are compromised now, your keys from the past
cannot be calculated. This assumes those keys are also no longer in
memory. A typical way of multiple child SA with PFS is:
T=00:00 Establish IKE SA with 1st Child SA (lifetime 1h for IKE SA, 8h for
Child SA)
T=00:01 Establish 2nd Child SA using DH (lifetime 8h)
T=01:00 Rekey IKE SA
T=02:00 Rekey IKE SA
[...]
T=08:00 Rekey Child SAs with DHs
What we are saying is do this:
T=00:00 Establish IKE SA with 1st Child SA (lifetime 1h for IKE SA, 8h for
Child SA)
T=00:01 Establish 2nd Child SA using DH (lifetime 8h)
T=01:00 Rekey IKE SA
T=02:00 Rekey IKE SA
[...]
T=07:00 Rekey IKE SA
T=08:00 Rekey all Child SAs without DH
T=08:01 Rekey IKE SA
At this point all these Child SAs gained PFS because the old IKE SA and
its KEYMAT are no longer in memory and a compromise now could not
recalculate the Child SAs anymore.
This may happen using
CREATE_CHILD_SA messages or reestablishing the IKE-SA altogether
(Reauthentication in strongSwan slang). With a 1000 peers, I’d had to
write 2 million keys instead of 2000 every reauth period and such operations
tend to be not uniformly distributed.
Re-authentication is not rekeying! See
https://datatracker.ietf.org/doc/html/rfc7296#section-2.8.3
IKEv2 does not have any special support for reauthentication.
Reauthentication is done by creating a new IKE SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify
payloads), creating new Child SAs within the new IKE SA (without
REKEY_SA Notify payloads), and finally deleting the old IKE SA (which
deletes the old Child SAs as well).
re-auth in your case causes 10k new child SAs (or 2x or 64x that if you
would do multi-sa of some kind).
However, if you do 10k+ Child SAs, you should not do a DH for each of
those ever. You should use:
T=00:00 Establish IKE SA with 1st Child SA (lifetime 1h for IKE SA, 8h for
Child SA)
T=00:01 Establish 10k Child SA WITHOUT using DH (lifetime 8h)
T=00:02 Rekey IKE SA
This costs 2 DH exchanged independent on the number of Child SAs, while
keeping PFS for all Child SAs.
I guess I'm insure how you would deal with QoS related issues when you
have two cores, but one uplink bandwidth. How would the cores not stomp on
each other? It seems you need to synchronise things on the client router
onto a single entity that determines which packet goes out first to keep
the stream complying with QoS settings.
Ensuring QoS policies is not the task of the IPsec encryption. In our case it
either happens using an external router or by using hardware offloads of
the black NIC. However, I also know cases where shaping does not happen
at all and DSCP fields are just mapped to different hardware queues.
As QoS is not critical from a confidentiality perspective, it is much easier
to realize in untrustworthy hardware (and without CPU coordination).
Whatever subsystem is doing this, if there are multiple CPUs it has to
know how many packets are in all CPUs network queues to coordinate
proper QoS, or else CPU 1 with a queue of priority traffic, and CPU 2
with a queue of bulk unimportant traffic would both send traffic?
Anyway, whether 2 or 64 Child SAs, I don't think it matters much,
because the number of Child SAs is unrelated to the number of DHs
you need to do.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
