On Thu, Aug 1, 2024 at 10:04 AM Valery Smyslov <smyslov.i...@gmail.com> wrote:
> Hi Paul, > > > > 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. > Switching between those two for IPsec SA is questionable, as you would have to evaluate if the cryptographic strength has changed, because it should never be weaker. I feel no sympathy for this use case :) > > > - 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). > Right. > > 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. > "later he changed his policy", so that means tear down everything and restart everything. Again, I feel ni sympathy to support this use case :) > 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. > Right, hence my proposed suggestion later on to change it now. > 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. > But I wouldn't want this type of behaviour to become standardized and affect IoT cases. It is a bit odd to shave off a byte here and there and then add a full rekey to the mix. > 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 > This second bullet point MUST always be allowed or the first IPsec SA should not have been allowed. > 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. > We definitely too often debug rekey issues right now without this draft, so I would disagree with making it part of that draft. Let's hear what other people think should be conveyed and then see if we can come up with an updated list. Paul
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
