Why does IKE use UDP instead of TCP?

Question

Why does IKE use UDP, and handle any retransmission itself?

(Larger IKE packets may cause UDP fragmentation and are dropped by some ISPs: IKE over TCP.

Answer 1

Originally, UDP was chosen over TCP because of its lower latency and processing requirements. Also, if ISPs followed the IETF standards, this wouldn't be an issue. There has been a movement to add TCP as an alternative, and there was a draft RFC (A TCP transport for the Internet Key Exchange draft-ietf-ipsecme-ike-tcp-01), which expired.

The problem you describe really lies in two places: cheap consumer-grade equipment, and ISPs which don't follow the IETF standards, especially when implementing CGN. Many in the IETF have no sympathy for either of those situations, which is why the proposed RFC expired, and, I suppose, the point is that the standards become meaningless when the tail wags the dog: the IETF doesn't want to be bullied into new standards simply because vendors and ISPs don't/won't follow other, existing standards (e.g. handling fragmentation).

Some equipment vendors have created workarounds (e.g., UDP packets encapsulated by TCP), but that is far from universal or standardized.

You could lobby or join the IETF to express your support of a standard for using TCP.

Answer 2

IKE is mean to encapsulate other communication. If that "other communication" requires all the L4 error correction that TCP offers, than the "other communication" should use TCP.

In this way, IKE/IPsec are only responsible for creating a secure transport. Not a reliable one.

Imagine transferring VOIP through an IPsec/IKE tunnel. VOIP largely (and intentionally) uses UDP, but if this VOIP traffic goes over an IPsec tunnel, and if the IPsec tunnel used TCP, your call may be delayed while IPsec is sorting out re-transmissions for dropped packets -- thereby negating the benefits of using UDP for VOIP.

Putting it another way, it doesn't add any benefit to have two independent functions handling error correction. If your data stream cares about error correction, use TCP. If your data stream doesn't, or wants to manage error correction itself, use UDP. The transporting of these UDP or TCP packets should not interfere or cause conflict with what you chose for your data.

And the only protocol that would add no additional error correction would be UDP.

Another example: If both IPsec used TCP and the underlying data used TCP, should a packet be dropped in transit, both the IPsec function and the TCP function would each request a re-transmission. Which would not be ideal.