Re: [IPsec] WG Interest in TCP Encapsulation

[Samy Touati]

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 
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  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-3D13632609353-26r-3D1-26w-3D1=BQICAg=eEvniauFctOgLOKGJOplqw=p3wIGO08_H-OJhunJTPABw=YwqtMpmTqLSFY01PopC4Ane63G1nyZ04LeAcZPn94us=uizqLw8LM5bxVJAGGXyM2XfMCL4pT-B5pYfWxblhIEU=
>  
>
> 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_=BQICAg=eEvniauFctOgLOKGJOplqw=p3wIGO08_H-OJhunJTPABw=YwqtMpmTqLSFY01PopC4Ane63G1nyZ04LeAcZPn94us=o7KJL1YNdcjmDXh8Nc2klEkemDtBi8TQ98-hMj-1q6k=
>  
> -- 
> kivi...@iki.fi




smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Interest in TCP Encapsulation

[Paul Wouters]

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

Re: [IPsec] WG Interest in TCP Encapsulation

[Tommy Pauly]

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  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
> IPsec@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec=BQIGaQ=eEvniauFctOgLOKGJOplqw=p3wIGO08_H-OJhunJTPABw=NS8d18flBXl5ifdG12-KKND7GHXI1pJTsHY3oN8YLqQ=QAyt5Max6LT-7yXfOOEqnhdsFfHCwuR1Y7YO-htB98A=
>  

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec