Hi Paul, > I tried to formulate and solve the issues discussed at the previous > meeting. There was no clear outcome (based on rereading the minutes) > so please check the changes and let the authors know if you disagree.
Thanks for the updates. Some notes: * maybe clarify that IPCOMP_SUPPORTED is only sent and a MUST if IPComp was negotiated in the original Child SA. RFC 7296 explicitly states "These payloads MUST NOT occur in messages that do not contain SA payloads." with regards to IPCOMP_SUPPORTED. Is there any clarification required on that? * maybe add "incompatible proposal" as a reason for initiating a regular Child SA rekeying of the first SA (if the KE method used for IKE is not in the Child SA proposal). However, I'd honestly prefer if that was just the standardized behavior for the Child SA created with IKE_AUTH as we really don't know what KE methods the responder has in its Child SA proposal. So just blindly assuming the IKE's KE methods will be accepted seems risky (in particular if multiple key exchanges were involved in creating the IKE SA). That IKE SA's first KE method can still be preferred in the Child SA rekeying request if it's in the initiator's proposal (i.e. use it for the KE payload and list it as first method in the SA payload). But if there is a mismatch, it seems easier to recover during a regular rekeying than blindly trying the IKE KE method, receiving an INVALID_KE_PAYLOAD and then having to initiate a regular rekeying all over anyway (if that's even an option, the draft currently doesn't explicitly say). * I'm still wondering why the critical bit has to be set for the OPTIMIZED_REKEY notify. It's a regular Notify payload, so it MUST be understood by all IKEv2 implementations and setting the bit is basically redundant (the critical bit only concerns the payload type, not the contents such as the notify message type - it's also only allowed to be set in requests so making it an unconditional MUST like that violates RFC 7296 anyway). Regards, Tobias _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
