HI Tobias, > Hi Paul, > > > 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. > > This should have nothing to do with the connection config. The notify > has no data associated with it. It's only about whether the two > **implementations** support handling KE methods in proposals during > IKE_AUTH. The actual proposals that are compared are still from the > configs selected during IKE_AUTH (based on the available identities).
Exactly! Regards, Valery. > Regards, > Tobias _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
