On Wed, 16 Sep 2015, Yoav Nir wrote:
This draft is proposing both IKE and ESP over the TCP connection, so the
protocol will work in situations where UDP (even with fragmentation at the IKE
rather than IP layer) fails.
We’ve had something like this working with IKEv1 for over 10 years. Many
vendors have “SSL VPN” solutions that have pretty much the same performance,
scalability, and connectivity characteristics. There’s ample evidence that this
kind of solution works. And although the need is slowly diminishing (more and
more public networks allow IKE and IPsec to work), there are still many places
where we still need to tunnel everything over TCP.
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.
Also TCP VPN connections can be trivially forced to close by
sending a (spoofed) RST packet.
So, while I am sceptical, we do see a flourishing of non-interoperable
TLS based VPN's without proper specifiations that are succesful precisely
because it works in both bad and administratively restricted networks.
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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
