>>> The real question is whether the networks that don't transport ESP or >>> ESPinUDP block those packets on purpose or by accident. I don't think >>> we really have any good numbers on this. >>> If we are doing this as a "workaround" to break through the administrative >>> boundaries, than we are going to see TCP blocked as well on those >>> networks. And all we have gained is complexity. We'll end up playing the >>> game of TOR. >> The question for me is - what do we want to achieve. If the purpose >> is to be able to work in those environments, where UDP is blocked, >> while TCP isn't, then we will soon end up defining IKE and ESP >> over HTTP(S), because it is the most "penetrating" protocol right now. >> >> Do you have any real numbers of how often such environments where UDP is >> blocked, but TCP (not only TCP:80) is not appear in real life? Could you >> estimate a percentage? >> Whereas it would be nice to get such info- some of the reasons why the network is set that way could be orthogonal (or even due to misconfiguration).
Is there a threshold for which the use-case is generally acceptable? Even 1% in relation to "potential" total number of connections (especially w.r.t growth in global IoT and smartphone connections) is still a lot. >> So, I'm not yet convinced that it is a solution to essentially >> widespread problem, however if people run IKE over TCP anyway, then >> it is better to have some standard way to do it. The question - why >> do they do it and does it the only way to solve their problem. >> As I understand, this could be classified along with the other “middle-box” issues that generally hinder/degrade access to IKE/IPSec services. Therefore, I generally support solutions that get IKE/IPSEC use-case coverage closer to 100%. But do agree that the RX processing of incoming IKE/IPSec packets, particularly at the Kernel, needs to be looked at carefully. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
