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

Hi Eric,

> I just finished reading this document. Some comments below. 
> 
> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>    sentinel value to indicate that a packet is IKE rather than ESP.
>    Given that in S 3 graf 2 you have a SHOULD-level requirement
>    to use typical UDP payload lengths, why not instead explicitly
>    limit lengths to 15 bits and use the top bit to indicate IKE versus
>    ESP. This would be slightly more efficient and seems simpler.
>    I suppose that the counterargument is that IKE over UDP behaves
>    differently, but in terms of implementation, that doesn't seem like
>   much of an argument.

That won't work. An application protocol running over UDP
is free to send messages up to 64Kbytes. While in tunnel mode we can
first fragment these messages and then apply ESP (so that each ESP
packet is rather small) , in transport mode it's impossible, and the ESP
datagram can reach 64Kbytes in size. I agree that in wild there are few 
protocols that send such long UDP messages, but it is not prohibited.

> - It seems like IKE associations can span TCP connections (S 6)
>   so why not instead of doing UDP first then TCP, do happy eyeballs.

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. 

> -Ekr

Regards,
Valery Smyslov.

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