Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Yoav Nir <[e-mail]>]

> On 19 Mar 2017, at 13:20, Valery Smyslov <[e-mail]> wrote:
> 
> Hi Yoav,
> 
>> > I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks in terms of performance (see Section > 12), so it is considered
>> > as a last resort if UDP doesn't work. In general UDP (or no encapsulation) is a preferred transport. If we start > trying TCP and UDP in parallel, then
>> > in some cases TCP will win even if UDP works, resulting in non-efficient connection, even when UDP could be used.
>> 
>> So as I said before, we do it, although IIRC (I’m not on the client team) the client gives TCP a one-second head start.
>> The reason is that in many places where a UDP packet can go, a fragmented UDP packet gets dropped,
>> so the first packets will work fine but the packets with the certificates (either IKE_AUTH or Main Mode #5) will get dropped.
> 
> With IKE Fragmentation that's not a problem anymore.

IKE over TCP solves the same problem (and a few others).

>> In by the end of IKE we have determined that UDP also works, we move to that for IPsec. And if TCP is blocked, we will try the IKE negotiation on UDP.
> 
> Your TCP encapsulation protocol seems to be more flexible than what is described in the draft.

Yes, and we (the working group) decided to simplify things by not incorporating this flexibility.

> The current draft doesn't allow moving existing SA from TCP to UDP unless MOBIKE is negotiated (see Section 5).
> So, if you start with TCP first (or do happy eyeballs and TCP wins), you never switch back to UDP, even if it appears
> that UDP works for that path too, unless both sides support MOBIKE. And even with MOBIKE it's not clear if switching
> is alowed unless interface address changes. That's why UDP is given a preference.

Yes, and that’s why the cost of using this as an alternative to IKE fragmentation is too high.

Yoav