Hello Tero and all, We discussed internally among the authors and it looks there exist 3 choices - to do PMTUD over IKE, or ESP or both. (Many reviewers have already pointed out these at various stages, just collating them here).
PMTUD over IKE is needed anyways for large IKE cert payloads, so if we do PMTUD over IKE, we could depend upon the same discovered MTU value for ESP paths as well as a guidance value. This seems to work for most of the cases, and there seems to be interest in the group towards this option. So this looks to be a good option overall, if we tackle IKEv2 window nuances effectively. However, one caveat with above approach is that there is an implicit assumption that paths for control and data traffic are same (i.e. IP based, 3 tupple paths). With SDWAN use cases (wherein paths could be orchestrated based on proto, port, QoS, App ID etc), would it be a precise assumption to make? How would we handle these cases when the paths are build for ESP and IKE differently? Thanks, Shibu. On Fri, Apr 13, 2018 at 1:48 PM, Tero Kivinen <kivi...@iki.fi> wrote: > Ron Bonica writes: > > In 99.9% of cases you are probably correct. If there is an ECMP > > between the encrypting node and the decrypting node, all ECMPs have > > the same PMTU. > > Is it 99.9%, or 99.9999%? > > > And because this is true in such a vast majority of cases, none of > > us have seen a situation where one ECMP has a larger PMTU than then > > next. > > If none has not yet been seen it is much closer to 100% than 99.9%. > Depending of course how many setups people have seen... > > > However, we still need to be prepared for that rare situation where > > one ECMP does have a greater PMTU that the next. Although black > > swans are rare, they bite very hard! > > There is also option to say that network is so broken that we fall > back to IPsec over TCP, and in that case both ESP and IKE packets go > inside same TCP stream and MTU discovery is done simlarly for both, so > things work. I.e., that might be acceptable solution for those rare > really broken cases. > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
