Antony Antony writes: > > 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 have not heard any implementation actually implementing that protocol, but on the other hand you could also similate it by setting IKE SA rekey timer low, and having a logic that IKE SA will NOT be rekeyed if there has not been any traffic in it since last rekey. I mean if you have IKE SA which does not have any traffic, there is no point of rekeying it ever, so having such logic would be useful. So I think there is no point of rekeying IKE SA at times T=02:00, T=03:00,..., T=07:00 as there is nothing changing in the state of IKE SA. Then at the time T=08:00 all the Child SAs gets rekeyed, and after that next time there is check for whether IKE SA should be rekeyed, it would notice that it has not been rekeyed for 7 hours which is much longer than the lifetime of 1 hour, and there has been Create Child SA exchanges on IKE SA, thus there is point to rekey it. The perceived value of the different IPsec implementations is what kind of implementation details they pick to when implementing certain things. We do give quite a lot of good advice what should be done to get good implementation in IPsec RFCs, but there is still lots of implementations who do to even implement them and then complain that the performance is bad. In addition to those listed there are even more things you can do depending on your hardware, and that is what makes some implementations better than others. Listing those in the RFC might not help, as those kind of implementation tricks only works on certain architectures or hardwares (i.e., they are not general purpose tricks). For me, it seems lots of the discussion we have here are already something that we solved twenty years ago in our implementations (sometimes only for some specific clients as they had different requirements and/or different hardware) without modifying the base protocol. I always prefer if we can solve the issue without protocol changes, by just making the implementation better... > 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. That depends which definition of PFS is used. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
