Valery Smyslov writes: > > Both good points. So, it appears that we have the following choices: > > > > - leverage IKE for exchanging probes and acks (But risk sending probes and > > acks over a different path than > > encrypted data) > > - send probes and acks in-band. Try UDP probes first. If that doesn't work, > > try TCP probes. > > What about ICMP-only SAs (yeah, it's weird, but possible)? > > > Which do you think is better? > > Both don't look ideal. I slightly prefer the former, as it looks > simpler to implement (at least for me), but the issue with different > paths can outweigh all. One potential solution to this issue would > be to always use UDP encapsulation, but I'm not sure we may impose > such a requirement... Your opinion?
I would just use IKE packets, and ignore the cases where ESP and IKE get different routes which have different MTUs. I would expect that in most cases if there is something in the middle using different MTUs then the routes are not equal cost anymore, thus routing will use only one of the routes. Usually the issues with MTU comes with road warriors connecting from random locations around the world, and in most of the cases there will be NAT for IPv4 in the middle, which will move all traffic to UDP anyways. Do we have any real world examples where the ESP and IKE packets consistently take different routes, and those different routes have different MTUs? And does all ESP traffic follow always one route, and all IKE traffic follow another route, or is it more random or based on the SPI or something? I do not know enough to really say whether such cases exists or do not exists, but before we start to make complicated protocols to cope with cases which are very rare, I want to get more information. If those cases are very rare, I might still want to make sure IPsec works somehow, even if it is not as efficient as it could be (i.e., there might be extra fragmentation happening or finding proper MTU might take more time). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
