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 protected]> wrote: > > 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 protected] >> <mailto:[email protected]>> wrote: >> >> Hi Tommy, >>> 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. >>> 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 >> >> I 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. >> >> _______________________________________________ >> IPsec mailing list >> [email protected] <mailto:[email protected]> >> 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=>
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
