On Thu, Aug 1, 2024 at 4:21 AM Valery Smyslov <smyslov.i...@gmail.com> wrote:
> Hi, > > I also have some comments on draft-pwouters-ipsecme-child-pfs-info. > > >From the Introduction I learned that the problem this draft is trying to > address is the > lack of knowledge at the time the initial Child SA is being created in > IKE_AUTH of what KE methods are > configured for subsequent rekeys of this Child SA. > Yes. > So, the main purpose is to allow manual troubleshooting of possible > configuration mismatches, right? > And to actually allow it to fail immediately instead of later during rekey. > The proposed solution is limited in its functionality: > - it doesn't support policies when some KE method are tied to particular > ENCR & PRF transforms > That assumes that you allow a different KE from the IKE KE for the child? That is questionable at best to begin with. - it doesn't support RFC9370 > It's tricky to understand what a child sa KE for rekey is in the case of multiple KEs anyway? Do you want to full multi Key Types protection for the child, you would have to redo the entire IKE SA chain anyway because you cannot do it for the Child SA ? > - there is no guarantee that the KE method included will be the same as > used > during actual rekey > It should be equal or "stronger" and if you want to avoid discussion what is weak or strong, it has to be the same. > > It also requires quite a lot of changes in the code - currently it is > assumed that crypto transforms > negotiation is done entirely within SA payload processing. With this > proposal we have also > look at this notify, which complicates code. > I think the complexity is rather limited. Also see above for some assumptions anway. In a way, it is almost mostly telling you "PFS is required or optional or forbidden". Or maybe a "without PFS is fine if you immediately rekey the IKE SA afterwards". > Given the complexity and serious limitations of the proposed solution and > assuming that > its main purpose is to allow manual troubleshooting of possible > configuration mismatches, > I wonder whether it would be more simple and reliable way to achieve this > to > just > have a button in the implementation's UI "Test Child SA rekey"? The > operator > would push this > button to immediately force a rekey once initial SA is established and > troubleshoot > should there are any errors. > I want something at the protocol level. Telling people to push buttons will not happen. They think "up" means success and at rekey time there will be an outage. That is the whole problem we are solving. Maybe instead of KE, it makes more sense to move this to indicate the above: - PFS for child mandatory - PFS for child forbidden - PFS for child optional - PFS for child requires prompt IKE rekey Would that address your concerns? Paul
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
