On Wed, Jun 17, 2020 at 05:07:48PM -0400, Paul Wouters wrote: > 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.
Just about the text i sent today on this thread. Still finalizing the -25 version of the actual draft. > > 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. The ACP tunnels are across link-local scope IPv6 addresses inside a LAN. Hence no issue. And for manual configured tunnel there is the GRE tunnel option. > 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. Where does in say in RFC7296 that you MUST implement tunnel mode and SHOULD/MAY implement transport mode ? RFC7296: | The USE_TRANSPORT_MODE notification MAY be included in a request | message that also includes an SA payload requesting a Child SA. It | requests that the Child SA use transport mode rather than tunnel mode | for the SA created. If the request is accepted, the response MUST | also include a notification of type USE_TRANSPORT_MODE. If the | responder declines the request, the Child SA will be established in | tunnel mode. If this is unacceptable to the initiator, the initiator | MUST delete the SA. The last two sentences read to me as if it is fine to only support transport but not tunnel mode, at least for the initiator: closing the connection ("deleting SA") if the initiator is only willing to do tansport mode, but not tunnel mode. What do you read from that ? > > 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. Sure, it was just clarification, but logically its hard to argue protocol violation based on attempting to distinguish unwilling and incapable. Sounds like a good court soap opera: DA: "Sir.IKEv2, Where you incapable or unwilling" ? IKEv2: "Incapable, it's not my fault" ! DA: "But i see your source code which makes you capable". IKEv2: "But the operator disabled it" DA: "You should not listen to what the operator says, you are an autonomous system" ;-)) But seriously: Whats the technical reasoning ? Just be sure to have an MTI ? Clearly for the use-case of automatic ACP secure channel, the transport mode option is the one with least packet header / MTU loss overhead. In 6.7.5 are the actual requirments and it does say for the ACP baseline profile "MUST transport", "MAY GRE". Give or take disagremement about whats technically best (which we should resolve), lets assume we do agree the technical goal is correct, if there really is clear text in IKEv2 thats violated (see above ask), we could still add a one line section making this an update to IKEv2 RFC for the specific case of automatic ACP link-local tunnels. I just find that unnecessary based on a) not finding the IKEv2 RFC requirements text, b) knowing how it is common implementation practice to choose an option like ACP is asking for. Cheers Toerless > Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
