Subject: Re: [IPsec] WG Interest in TCP Encapsulation

From: Samy Touati <[email-masked]>
Date: Wed, 16 Sep 2015 07:09:54 +0000

Hi Tero,

From a gateway perspective having a standardized implementation from terminals for tcp encapsulation of ipsec is something which is needed. 
The untrusted Wi-Fi architecture defined in 3gpp is used for voice traffic, and is being deployed by multiple carriers. 
The mobile device may be connected to networks only allowing "web traffic" or using a web proxy, and this draft provide mobile devices with a standardized method to still use ipsec. 
The performance impacts on the gateway  are mitigated with the on-demand use of TCP encapsulation by mobile devices. 

Thanks
Samy. 

From: Tommy Pauly <[email-masked]>
Sent: Sep 15, 2015 8:20 PM
To: Tero Kivinen
Cc: IPsecME WG
Subject: Re: [IPsec] WG Interest in TCP Encapsulation

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:
>>
>> 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 
>
> 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= 
>
> So how does your draft relate to the earlier ike over tcp draft? 
>
> 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: Les Leposo <[email-masked]>
Date: Sat, 19 Sep 2015 12:18:16 +0300

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