Hi Paul,
On Thu, Aug 1, 2024 at 4:21 AM Valery Smyslov < <mailto:smyslov.i...@gmail.com> 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. I meant that the policy may be: - use AES-GCM with P256 or - use Chacha20 with X25519 but do not mix them up any other way. This policy is impossible to express with the proposed notify. - 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 ? No. RFC9370 allows using multiple key exchanges in CREATE_CHILD_SA, including rekeys (with the help of the new IKE_FOLLOWUP_KE exchange). - 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. Imagine the situation: during IKE_AUTH you propose X25519 and Ed448 and your peer didn’t mind, but later he changed his policy to only allow Ed448 (which is stronger, so it is OK). When you propose X25519 during actual rekey some hours later it will fail. 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". This is not what the draft proposes now. 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. You may eliminate additional button. Just make so, that when users establishes a connection (e.g. presses “Connect” button) always perform an immediate rekey of Child SA and indicate “up” onle when it succeeds. This is seamless for user and the penalty is not big. 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? That would be much better. But I would limit it to 2 flags: - no PFS is OK - using the same KE(s) as used for IKE SA is OK sent by each peer (no negotiation, just announcement). If no common flags exchanged, then the peers have to perform full CREATE_CHILD_SA with possible troubleshooting. And I still think that this functionality is most useful for draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt and thus should live there and not in a separate draft. Regards, Valery. Paul
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
