> On 19 Mar 2017, at 13:20, Valery Smyslov <[email protected]> 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

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to