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

["Valery Smyslov" <[e-mail]>]

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.

> 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.

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.

> Yoav

Regards,
Valery.