Hi Valery, The draft doesn't prevent http encapsulation for the purpose of traversing web proxies for example, and this would be considered one "use-case" that would make use of TCP encapsulation. The draft do provide such flexibility.
The objective of this proposal is to provide a standardized method to allow the use of IPSec in environments which may not allow udp encapsulated IPSec traffic, and to avoid different implementations to address specific use cases. The client would select this method only as a last resort option, so performance issues should be mitigated. With this capability, the mobile device can enable wifi calling in a higher number of locations. It also allow the introduction of the wifi calling service without too much impact in some venues types. Thanks Samy. > On Sep 18, 2015, at 6:54 AM, Valery Smyslov <sva...@gmail.com> wrote: > > Hi Tommy, >> 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. >> I can see some networks which legitiably block or fail to transport UDP, >> for instance an airplane wifi with proxy server on board for DNS and >> HTTP. Here, the resources are very scarce. But also, the packet loss >> scenario would be bad, eg when doing voice UDP over IPsec in TCP via a >> proxy TLS server. I did not re-read the old or read the new draft yet, >> but turning a UDP protocol into TCP (or even TCP in TCP) has its issues. >> So people want to do this anyway, and if they do, we should at least try >> and avoid the same scattering that has happened with TLS VPN's and do >> it in one interoperable way for IKE and IPsec. And I would think getting >> the ESPinTCP will actually be the harder part to get properly supported >> inside the kernels. >> So I would reluctantly want to move forward with the idea, although I >> need to do more homework about the implementation details of both drafts. >> Paul > > I to agree with Paul here. > 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? > > 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. > > Regarding the draft. You should probably have mentioned that with IKE over > TCP responder looses its ability to remain stateless and that cookies become > useless and SHOULD NOT be used. > Regards, > Valery Smyslov. > > _______________________________________________ > 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
