Hi Paul, I encourage you to read the new draft, as I believe it addresses many of your concerns. It covers the potential new vulnerabilities (RST), as well as how to frame the datagrams in a stream along with an explanation of performance concerns. It also makes it clear that TCP should only be used when absolutely necessary, not as a default.
In our own deployments around the world, there are a high number of networks that are blocking connections by “accident", not by policy. These include many hotel and restaurant networks. We are interested in allowing connections to work in these networks. If a network legitimately wants to block our traffic and is able to detect that we are using IPSec, then I am not interested in getting into an arms race to get around their firewalls. Some clients may have trouble putting ESP over TCP, as you mention, but we have been able to implement this protocol successfully for both clients and servers. This may not be a protocol that all clients end up supporting, but those that do need TCP encapsulation should do it in a standard fashion. As you mention, the critical point is that clients and servers will be implementing this functionality in the near future, and we need to avoid non-interoperable solutions. If we can standardize the way TCP encapsulation “should” work, then IKEv2 will be able to used in essentially all scenarios that support non-standard TLS VPN protocols. Thanks, Tommy > On Sep 17, 2015, at 10:05 AM, Paul Wouters <[email protected]> wrote: > > 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 > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=p3wIGO08_H-OJhunJTPABw&m=NS8d18flBXl5ifdG12-KKND7GHXI1pJTsHY3oN8YLqQ&s=QAyt5Max6LT-7yXfOOEqnhdsFfHCwuR1Y7YO-htB98A&e= > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
