Subject: [IPsec] WG Interest in TCP Encapsulation

From: Tommy Pauly <[email-masked]>
Date: Tue, 15 Sep 2015 16:30:09 -0700

Hello,

I wanted to get a sense of WG interest in working on a standard for running IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks that currently block UDP traffic.

Here’s the link to the draft:
https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-00 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpauly-2Dipsecme-2Dtcp-2Dencaps-2D00&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=p3wIGO08_H-OJhunJTPABw&m=YU3nOZToRdXNNjQ3fAzaZFdnwRLcK4y3uWwnHWtbY-U&s=EfG7Pdn-bIObEeQ216ZKhaJApVAA__0qkL7NeZ-AUMY&e=>

Abstract:
This document describes a method to transport IKEv2 and IPSec packets
   over a TCP connection for traversing network middleboxes that may
   block IKEv2 negotiation over UDP.  This method, referred to as TCP
   encapsulation, involves sending all packets for tunnel establishment
   as well as tunneled packets over a TCP connection.

For clients that rely heavily on IKEv2, such as phones that use IKEv2 to to route VoIP calls over Wi-Fi back to carrier networks, working in such networks in critical.

Please respond with your comments!

Thanks,
Tommy Pauly
Apple

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Sep 2015 05:01:14 +0300

Tommy Pauly writes:
> I wanted to get a sense of WG interest in working on a standard for running
> IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks that
> currently block UDP traffic.

Before we made the UDP framentation document, our original plan was to
run IKEv2 over TCP, just because that would solve this problem.

During this process we then found out that WG wanted to standardize
UDP fragmentation instead of IKEv2 over TCP.

Is there really happend something that changes that?

The old informal poll can be found from 

http://marc.info/?t=136326093500003&r=1&w=1

So how does your draft relate to the earlier ike over tcp draft? 

http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ike-tcp/
-- 
[email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 15 Sep 2015 20:20:48 -0700

Hello Tero,

I have read the previous draft for using TCP to avoid fragmentation problems, and I believe that the new TCP-encapsulation draft is aimed at solving a different use case with a different approach.

The current standard for IKEv2 fragmentation is definitely the right thing to do to avoid problems with networks that treat large UDP packets badly, causing IKEv2 tunnel establishment problems. The new spec is very specifically targeted at networks that block all UDP traffic, to be used as a fallback mechanism only.

Here’s a quick point-by-point comparison:

draft-ietf-ipsecme-ike-tcp-01 (old draft)
1. Negotiated with an IKEv2 Notify payload.
2. IKE messages can use UDP or TCP within a single SA
3. Supports IKE packets only.
4. TLS/firewall traversal/ESP-in-TCP are non-goals. This draft was meant to be used always, and putting all traffic over TCP or TLS had too high overhead.

draft-pauly-ipsecme-tcp-encaps-00 (new draft)
1. Non-negotiated, but pre-configured. Since the use case assumes that all UDP is blocked, a connection must try over TCP without prior communication if UDP gets no response.
2. All packets for a given IKE SA must use either UDP or TCP, with the exception of migration over MOBIKE.
3. Encapsulates IKE and ESP packets, since the tunnel must also go over TCP on a UDP-unfriendly network.
4. TLS and firewall traversal is the goal. This draft is meant to be used only as a last resort, and details many performance considerations to explain why the tunnel will work sufficiently, but is not ideal.

I agree with the decision previously to go with IKEv2 fragmentation rather than TCP. However, shipping clients still have serious problems on networks that do block UDP traffic. There may always be some middle boxes that do enough inspection and want to block IKE/IPSec traffic, even over TCP and TLS, but the majority of cases in which IKEv2 cannot be used will be, in our experience, solved by moving the connection to TCP/TLS when needed.

Other standards bodies, such as 3GPP, have published documents stating that clients should do this for IWLAN, without giving specifics on how the framing should be handled, or how it impacts the IKEv2 protocol. See: http://www.etsi.org/deliver/etsi_ts/133400_133499/133402/12.05.00_60/ts_133402v120500p.pdf

If IKEv2 servers start implementing support for TCP encapsulation based on these documents, we may end up with diverging implementations, or implementations that are not compatible with MOBIKE, etc. We believe that a standard is needed to define how implementations should handle this.

Thanks,
Tommy

> On Sep 15, 2015, at 7:01 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Tommy Pauly writes:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__marc.info_-3Ft-3D136326093500003-26r-3D1-26w-3D1&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=p3wIGO08_H-OJhunJTPABw&m=YwqtMpmTqLSFY01PopC4Ane63G1nyZ04LeAcZPn94us&s=uizqLw8LM5bxVJAGGXyM2XfMCL4pT-B5pYfWxblhIEU&e= 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dipsecme-2Dike-2Dtcp_&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=p3wIGO08_H-OJhunJTPABw&m=YwqtMpmTqLSFY01PopC4Ane63G1nyZ04LeAcZPn94us&s=o7KJL1YNdcjmDXh8Nc2klEkemDtBi8TQ98-hMj-1q6k&e= 
> -- 
> [email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Sep 2015 15:45:52 +0300

> On Sep 16, 2015, at 5:01 AM, Tero Kivinen <[email-masked]> wrote:
> 
> Tommy Pauly writes:

Hi, Tero

At the time that we (at my suggestion) dropped the work on IKE over TCP it was because of a conclusion we had reached:

In all the cases where IKE over TCP solves your connectivity issues but IKE fragmentation doesn’t, the IPsec would fail.

At the time, the WG was not in favor of running the IPsec over that TCP connection, so there seemed to be little point.

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.

It it hasn’t been clear, I am in favor of adopting this draft.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Sep 2015 13:05:39 -0400 (EDT)

> 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.…

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

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 17 Sep 2015 11:27:18 -0700

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-masked]> wrote:
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> 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=

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 18 Sep 2015 16:54:08 +0300

Hi Tommy, 

> need to do more homework about the implementation details of both drafts.

I tend 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.

---

From: Samy Touati <[email-masked]>
Date: Fri, 18 Sep 2015 18:28:16 +0000

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 <[email-masked]> wrote:
> 
> Hi Tommy, 
> I  to agree with Paul here. 
> 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?
> 
> 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.
> 
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 18 Sep 2015 16:44:42 -0700

Hi Valery,

As Samy mentioned, this draft does allow for the traffic to looks like HTTPS traffic (using TLS over port 443), but doesn’t require it. It is about defining a standard way to add framing to IKEv2 and ESP when put over a TCP-based stream; the applications of this may vary in different networks in the future.

You asked about how widespread this issue is. I cannot provide exact numbers here, but on a global scale, I would estimate that around 10% of networks that mobile customers may be using will block UDP traffic, but allow traffic encapsulated as we define in the draft. These are most common in hotels, restaurants, and other public networks.  This is certainly not the majority of networks, but it is still very significant to users. These failures also account for essentially all of the IKEv2 connection failures that we have measured. When IKEv2 over WiFi is used as your only way to send or receive phone calls, or a device is required by policy to use IKEv2 for all its networking connections, being on a network that blocks this traffic means having an unusable device. Because scenarios like this are becoming more common, we are seeing a push to make IKEv2 compatible with these networks. 

The primary goal of the draft is to define a standard way of framing so we don’t end up with a different approach from each vendor, as we saw in TLS VPNs. The problem is a current one that needs to be solved, since it has high user impact. I also believe that having a standard way to transmit IKEv2 and ESP over a stream-based protocol will be useful going forward, and the draft specifically defines exactly what is needed to be interoperable and functional, without creating limitations about usage scenarios (specific port numbers, TLS parameters, etc). 

Thanks,
Tommy

> On Sep 18, 2015, at 11:28 AM, Samy Touati <[email-masked]> wrote:
> 
> Hi Valery,
> 
>> On Sep 18, 2015, at 6:54 AM, Valery Smyslov <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Tommy, 
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=p3wIGO08_H-OJhunJTPABw&m=4GK9GDAJB4AfnjxKtZO86J_C51187G2Wd6iGESlw-tc&s=r-OioL-HDBAQtOyfaWxfvw2XYMyePRHw--cSv0lCNto&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=p3wIGO08_H-OJhunJTPABw&m=4GK9GDAJB4AfnjxKtZO86J_C51187G2Wd6iGESlw-tc&s=r-OioL-HDBAQtOyfaWxfvw2XYMyePRHw--cSv0lCNto&e=>

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Mon, 21 Sep 2015 19:44:08 +0000

Hi

>From my personal experience it¹s not as high as 10%, but I¹ve certainly
seen a number of cases where either UDP/4500 or ESP, is blocked. (saw a
timely example of this at the weekend..)

cheers

From:  IPsec <[email-masked]> on behalf of Tommy Pauly
<[email-masked]>
Date:  Saturday, 19 September 2015 00:44
To:  Valery Smyslov <[email-masked]>
Cc:  IPsecME WG <[email-masked]>, Paul Wouters <[email-masked]>
Subject:  Re: [IPsec] WG Interest in TCP Encapsulation

You asked about how widespread this issue is. I cannot provide exact
numbers here, but on a global scale, I would estimate that around 10% of
networks that mobile customers may be using will block UDP traffic, but
allow traffic encapsulated as we define in the draft.