Re: [IPsec] WG Interest in TCP Encapsulation

[Tommy Pauly]

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

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

[IPsec] Milestones changed for ipsecme WG

[IETF Secretariat]

Changed milestone "IETF Last Call on null authentication", resolved as
"Done", added draft-ietf-ipsecme-ikev2-null-auth to milestone.

URL: https://datatracker.ietf.org/wg/ipsecme/charter/

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

[IPsec] WG Interest in TCP Encapsulation

[Tero Kivinen]

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=13632609353=1=1

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

http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ike-tcp/
-- 
kivi...@iki.fi

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

[IPsec] WG Interest in TCP Encapsulation

[Tommy Pauly]

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 


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___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Not meeting at IETF 94 in Yokohama, but continuing work here on the list

[Paul Hoffman]

Greetings again. Dave (our new co-chair) and I talked, and we don't see 
any need to meet at the upcoming meeting in Yokohama. Instead, we would 
love to see more discussion here about the DDoS document and discussion 
of possible new items.


--Paul Hoffman

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