Hi Paul,
On Mon, Jul 7, 2025 at 2:48 PM Antony Antony < <mailto:[email protected]>
[email protected]> wrote:
If this payload is sent in IKE_SA_INIT, it would apply to all subsequent
CHILD_SAs, potentially restricting flexibility. I wonder whether placing it
in CREATE_CHILD_SA or IKE_AUTH would be more appropriate, to allow
per-CHILD_SA PFS negotiation.
I remember the use case Valery used to mention if the SA is short lived no
need for pfs.
>
> Initiator Responder
> -------------------------------------------------------------------
> HDR, SAi1, KEi, Ni
> N(EARLY_CHILD_PFS_INFO) -->
>
> <-- HDR, SAr1, KEr, Nr, [CERTREQ],
> N(EARLY_CHILD_PFS_INFO)
what is in the payload EARLY_CHILD_PFS_INFO is it single value or list?
I propse a list.
You actually raise an important issue. Since some common (eg Windows) OS do not
support IDr,
putting the payload in IKE_SA_INIT won't work. There is a fair chance that the
responder does not
yet know which configuration to match up with the IKE_SA_INIT, so it does not
know which of its
connection configurations will apply.
Antony’s interpretation of my proposal was wrong (my fault) J
These notifications _only_ negotiate the support for the pfs-info
extension, they do not negotiate compatible (A)KE methods, and
they contain no data. The real negotiation of (A)KE methods for Child
SAs
take place in IKE_AUTH, when responder does already have
all the information about peer’s identity.
The (A)KE methods are negotiated via SA payload in IKE_AUTH,
as well as other Child SA parameters.
Regards,
Valery.
I like this one better than the previous proposals.
I am beginning to feel much the other way :)
Paul
_______________________________________________
IPsec mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
