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 <kivi...@iki.fi> 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= > > -- > kivi...@iki.fi
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
