[talking as individual and one of RFC7296 authors, not as WG chair]. Toerless Eckert writes: > On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote: > > The RFC states: > > > > 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.
At this point the responder already created an Child SA in tunnel mode, and when the initiator receives that message from the responder it will also create the Child SA in tunnel mode. Responder might already be sending traffic at this point. This means both initiator and responder MUST implement tunnel mode, as otherwise they cannot perform those actions. Meaning as the fallback from the transport mode is tunnel mode, all implementations MUST implement it even if it not explictly said in the RFC. > > If this is unacceptable to the initiator, the initiator > > MUST delete the SA. This thing happens after the Child SA is created. I.e., now the initiator will check whether the Child SA created was following its policy, and it is completely valid for the initiators policy to say that must use transport mode, and then it will delete the SA as it was not following its policy. It still means that the initiator implementation MUST implement tunnel mode, but it does not have to USE it if it does not feel like doing that. The MUST/SHOULD etc only give requirements for the implementors, i.e., what features MUST or SHOULD be implemented and what MAY be implemented. In the RFCs we cannot use those keywords to instruct adminstrators/users what they should use. Quite often, especially in the security considerations section, we try to give requirements to the users, but we need to be very carefull not to do that. We can give information to users saying "do not use low entrypy passwords as PSK as they are known to be unsafe", but we cannot say MUST NOT use low entropy passwords, as there is no easy for for implementor to enforce that. For every single MUST or SHOULD and especially MUST NOT or SHOULD NOT you are writing to the RFC, you should think how can you answer to question from the customer who says, "show me the lines in your implementation which implements this MUST or SHOULD". For MUST and SHOULDs, that is usully still quite easy, but when someone asks "Show me the lines of code where you implement: This notification MUST NOT BE sent by an entity that may be replicated".... (and yes, I have had incoming customer support case, where they asked for every single MUST/SHOULD/MUST NOT/SHOULD NOT where it was implemented in the source of our toolkit). > > But note that the responder has already installed the IPsec SA in tunnel > > mode. So if the initiator finds that unacceptable, it must send the > > delete. During all this time, connectivity between the nodes will be > > blocked. The intention here is that transport mode is optional and > > should not be mandated by other protocols. Otherwise, the IKEv1 > > style negoation of transport OR tunnel mode would have been kept. Also the delete notifications might get lost, and it might takes tens of seconds, or even minutes before the initiator can finally tell the responder that the Child SA that didn't follow its policy is deleted. > How about my mails ask that i read this text such that the initiator will > delete the SA (not only client SA) if transport mode is not supported > be responder. Aka: the last two sentences to me describe exactly the > case where the initiator can/want only support transport mode. Initiator and responder can delete whatever SAs they like whenever they like. That does not matter to the actual case here. The issue there is that if the responder does not want to do transport mode, then SA will be created in tunnel mode, and the initiator must be able to cope with tunnel mode ESP packets it is receiving from the responder. I.e., it needs to be able to implement tunnel mode as much it understands those packets and does something to them (dropping them is fine, as if his policy says he wants to get transport mode packets and do not allow tunnel mode packets, then it is fine to have policy dropping all tunnel mode packets). > Aka: i can not read your interpretation into this text. Anyways, this discussion is not really useful. If the other end does not support transport mode (as it is allowed to do by IKEv2, as transport mode is optional), there is nothing you can do to make it support transport mode, and deleting the Child SA will just cause initiator to try again few seconds later when it gets next packet to that direction, with exactly same bad result. It would be much better to simply say that SHOULD use transport mode, as it is more efficient for GRE, but if other end does not support transport mode, using tunnel mode still gets the connectivity, even when we are wasting few bytes. In IPsec we had so much issues in IKEv1 where every single option and feature knob needed to be exactly right to get any connectivity, that in IKEv2 we tried to get rid of exact negotiation things, instead we propose something, and we do have fallback to go if other end does not accept our proposel. Transport -> tunnel is one of those. IPcomp -> no IPcomp is another, traffic selector narrowing is third, getting rid of negotiated lifetimes for SAs was yet another one etc. The basic idea is that when you finish IKEv2 exchange you have "usable" child SA you can use to send and receive traffic. Whether it was exactly what you wanted is another thing, and whether you can accept that, is initiator choise, and if he cannot accept it, he can delete the SA and be without connectivity compared to non-optimal connectivity. Also as I have understood that your nodes are security gateways (not hosts, as they do forward packets from other nodes) the RFC4301 already says that they: b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management, or to provide security between two intermediate systems along a path. Meaning tunnel mode is mandatory to implement in those devices anyways. The use of tunnel mode is completely different matter then. > Please answer the other questions from my reply mail. > > > So I would recommend to follow the intention of RFC 7296 and not make > > up your own restrictions. > > Again, i had a lot of arguments in my email that i need to see answers > to so that we can make progress here. I do disagree with Paul that I think profiles can require certain optional features to be implemented and used from the base standard, if it makes sense in there. That does not mean that you can remove features from the base standards, so even if you do say you use GRE with transport mode, the IPsec implementations used still need to implement tunnel mode too, as that is part of the base standard, but of course you do not need to allow that to be configured, so detecting use of that might be difficult. So I think it is ok to say that SHOULD (or even MUST) implement transport mode for GRE, but it is not ok to say that tunnel mode would be OPTIONAL, as that would make it so that it cannot connect to the conforming IKEv2 implementations not supporting transport mode. We had similar discussion in the RFC7815 minimal IKEv2. That document really only covered the Shared key authentication even when the base IKEv2 do require also PKIX certificates and RSA signatures. It does use one of the mandatory to implement features of the IKEv2, thus it can talk to all conforming IKEv2 implementations, thus interoperability is there, but cannot do both of the required authentication methods, which does not cause problems as full implementations need to support both anyways. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec