On Thu, Dec 07, 2023 at 06:47:35PM -0500, Paul Wouters wrote: > 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.
Has anyone implemented this yet? This concept sounds intriguing; however, I am afraid interoperating various combinations of PFS could become complex to configure as an admin. Often, we end up creating a new protocol instead of discussing implemenation details. I herd this idea before, a few times at IETF, and wonder if CFRG would agree what is written here. It might worth clarifing with crypto people may be write it down. > > 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 > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
