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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
