Hi William, > I like this idea. It sounds the right direction to me. > In addition to the processing described, if the KE methods negotiation failed > in > IKE_AUTH, i.e., the SA proposals from the initiator were all rejected by the > responder, the IKE handshakes should still success without creating the > initial Child > SA.
Yes, exactly. This is the situation that the draft originally aims to address - an early indication at the time the initial Child SA is being created that its subsequent rekeys will fail. With this proposal the initial Child SA won't be created in this case. > Then the two peers could negotiate by the CREATE_CHILD_SA exchange to > create the first Child SA. Right? They can, but this would not succeed until one of the peers adjusts its policy with regard to Child SA's KE methods. This is because the proposals in this CREATE_CHILD_SA will be exactly the same as in IKE_AUTH, thus the result must be the same. Regards, Valery. > Regards & Thanks！ > Wei PAN (潘伟) > > > -----Original Message----- > > From: Valery Smyslov <[email protected]> > > Sent: Monday, June 30, 2025 8:57 PM > > To: [email protected] > > Subject: [IPsec] Comments on draft-pwouters-ipsecme-child-pfs-info-01 > > > > Hi, > > > > I think that the problem that the draft addresses can be solved in more > > simple and elegant way. Just lift prohibition for KE transforms to > appear in > > the SA payload in IKE_AUTH. > > > > Rationale. Currently all the parameters of the initial Child SA are > > negotiated in the IKE_AUTH exchange except for KE methods. Section 1.2 > > of RFC 7296 > > says: > > > > Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr > > payloads. > > Thus, the SA payloads in the IKE_AUTH exchange cannot contain > > Transform Type 4 (Diffie-Hellman group) with any value other than > > NONE. Implementations SHOULD omit the whole transform > > substructure > > instead of sending value NONE. > > > > The only difference between negotiation of Child SA parameters in > > IKE_AUTH and in CREATE_CHILD_SA is that in the latter case KE method is > > negotiated too, so that the full set of needed parameters is negotiated. > > Thus, the solution - let negotiation in IKE_AUTH be the same as > > negotiation in CREATE_CHILD_SA - lift the prohibition for KE method > > transforms to appear there. But do not use the negotiated KE method(s) > > for computing session keys for initial Child SA - just check that > negotiation > > is successful, which means that you will not have problems with the > > following rekey(s). > > > > To maintain backward compatibility negotiate this feature in IKE_SA_INIT > > via exchange of a new notification. > > > > Initiator Responder > > ------------------------------------------------------------------- > > HDR, SAi1, KEi, Ni > > N(EARLY_CHILD_PFS_INFO) --> > > > > <-- HDR, SAr1, KEr, Nr, [CERTREQ], > > > > N(EARLY_CHILD_PFS_INFO) > > > > > > HDR, SK {IDi, [CERT,] [CERTREQ,] > > [IDr,] AUTH, SAi2_with_KE, > > TSi, TSr} --> > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > SAr2_with_KE, TSi, > > TSr} > > > > > > In my opinion this solution has the following advantages: > > > > 1. It allows full-fledged negotiation of KE methods identical to what > > CREATE_CHILD_SA allows with no restrictions on the policy > > (or these restrictions are the same as for CREATE_CHILD_SA). > > 2. It is easy to implement - note that you already have code for > handling > > SA payload > > in CREATE_CHILD_SA, which does all the work. > > 3. If it is used with optimized rekey, then the problem of initial > Child SA > > rekey will gone - > > just save the negotiated KE method(s) and use them in the following > > rekeys. > > > > Opinions? > > > > Regards, > > Valery. > > > > _______________________________________________ > > IPsec mailing list -- [email protected] > > To unsubscribe send an email to [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
