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). Regards, Tobias _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
