THanks, Tero, inline On Thu, Jun 18, 2020 at 09:03:23PM +0300, Tero Kivinen wrote: > [talking as individual and one of RFC7296 authors, not as WG chair].
Is there some new IETF liability insurance that make us say this ? Ok: i am also only talking as an individual and ACP draft author and not was 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. [deleted question i wanted to ask here as you answer it below.] Sounds as if IKEv2 is effectively not built to allow optimizing the classical transport option case. For example using IPsec for transport connections of protocols, such as IGPs, BGP or the like. I did write the doc for how to use IPsec transport mode with RFC4601 PIM, alas, security was never widely used for such signaling, so RFC7761 completely removed it. But if somebody ever wanted to write a good profile for such use cases, they would run into this tunnel over transport issue. > > > 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. I guess it is left up to the implementer to figure out that implementing support for tunnel mode in IKEv2 doesn't mean that it does have to actually implement support for it in the forwarding plane / ESP. > 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".... Yeah, and it gets more tricky with the distinction of MUST in IKEv2 which may or may not be read to be inclusive to actual forwarding plane / ESP requirements. > (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). I ould like to imagine it is satisfying to be such a large customer that you can not only answer but also make your vendor answer those questions, but in my experience those customers than also had to write long reports about the ansers ;-) I would love to see "protocol implementation compliance specification" or whatever you might call it, but i have given up asking for it in the IETF itself, and given ho i work for a vendor it is of course masochism ;-) > > > 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. Ok. > > 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. Well, i find your, Yoav and Pauls explanation very helpful. May i dare to say: Also because of the lack of similar explanations in the RFCs. > 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. Well in the case of ACP we're fine with the way IKEv2 works, the MUST is on tunnel mode without GRE (just IP in IP), and the MAY is on GRE with transport and prefer that when available. I primarily wanted to make sure we have enough of a basis written to know what could be negotiated. Older router may likely prefer and fsaster implement GRE, hence its useful. But there is not a lot of need IMHO to have a lot of profile requirements because most connections will be between routers from the same vendor and they can extend the profile as they wish. > 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. Understood. Thats also why i am worried and maybe have written more than necessary requirements to ensure interop into ACP. And given how the main use of IPsec are VPN across IPv4 with all the NAT crap, it is quite useful to start with that as the first negotiation result. > 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. Options Galore > 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. Yepp. The 4301 text describing limitations of transport mode does of course not cover the case where transport mode is used in conjunction with another tunneling protocol like GRE. > > 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. Yepp. Paul and i only got into this argument because i was surprised to learn about the IKEv2 details given my divergent experience from practice and the (sorry) not very explanatory IKEv2 rfc text. Luckily no conflict with the requirements in the ACP doc from what i can tell. > 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. Thanks again for all the insight Toerless > -- > kivi...@iki.fi -- --- t...@cs.fau.de _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
