On Wed, 17 Jun 2020, Toerless Eckert wrote:
Given how you are focussing on this aspect, can i assume that you are happy with the everything else in the suggested text ?
I don't know yet. I have to re-read the last draft version.
Wrt to tunnel vs. transport mode: If you can, please propose specific text that would improve the quality of the doc wrt. to your point. I can only observe: a) I have not found the word "profile" in neither rfc4301 nor rfc5996, so i have no basis from which to argue what could or could not be called permissible for a "profile"
I don't think we have an official IETF definition of a profile, but it usually means a collection of protocol parameters that are normally negotiated. For an example IPsec profile, see: https://www.rfc-editor.org/rfc/rfc6380.html Another more recent one is the draft for the updated CNDSA profile: https://tools.ietf.org/html/draft-corcoran-cnsa-ipsec-profile-00
b) I have not seen MUST support transport and MUST support tunnel mode, so being "incapable" of either option will lead to closing the connection, and those implementatoins are i think compliant with the IPsec/IKEv2 RFCs.
Tunnel Mode is Mandatory To Implement. Transpode Mode is not.
b) All router implementations i know that can do tunnel and transport mode allow you to configure which option specifically to use and they too will close a connection is there is a mismatch. One could call that configuration "unwilling".
Yes. In IKEv1, one was allowed to require Tunnel OR Transport mode, but for IKEv2 it was a conscious decision to make transport mode something a responder could refuse, without breaking the IPsec connection. This was done specifically to move most scenarios (especially over the internet, especially when NAT is involved) to Tunnel Mode. Transport Mode can be used but really should only be used if there is no NAT. And those reasons are also why I now bring this up. I want to avoid a new RFC that requires Transport Mode. It is fine to recommend it, as long as the responder is still allowed to refuse this, and be ensured that tunnel mode will be used instead. A connection MUST NOT hard fail on not getting Transport Mode.
ACP draft does not even have a notion of "unwilling", just "incapable".
My comments were triggered based on the texts in this email thread. As I said, I still need to reread the latest draft version. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
