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