[IPsec] note on ike fragmentation and ike over tcp

[Paul Wouters <[e-mail]>]

(missed from the jabber room)

The bug mentioned that there was a lot of IKE fragments for IKEv1 without
seeing the FRAGMENTATION vendorid was solved. It was iOS 6.0 and they
fixed it since. (either in 6.01 or 6.1)

It did cause people to be forced to implement fragmentation for IKEv1.

The best "specification" I found was at Microsoft:

http://msdn.microsoft.com/en-us/library/cc233452.aspx

However note that it seems most (every?) implementation only uses fragment
ID = 1. Probably because that field is useless and an IETF review would
have found that and kicked it out :)

There seem to be different tresholds for when to do fragmentation. Stock
racoon uses 552, while racoon on iOS uses 1280. We (libreswan) ran into
strange Linux kernel issues for IPv6 when using 552 (might be our own
fault). Neither upstream racoon or iOS racoon treats IPv4 different from
IPv6. Libreswan uses 552 for IPv4 and 1240 for IPv6 but that might change,
as our exposure and interop experience is rather new (and mostly with
racoon or racoon-derivatives code such as strongswan)

Note also that it is likely there could be interoperability issues
because the racoon code (and the strongswan port of that) are directly
using sizeof(struct) for wire format, so we might see strange issues on
certain CPUs now or in the future due to alignments.

The fragmentation seems pretty straightforward. I personally like
not needing to rely on TCP (which can be trivially DOS'ed using
an unauthenticated TCP RST packet). So I'm with Tero that if IKE
fragmentation works, and it seems that it does, the incentive for
implementing IKE over TCP is low, while the changes are pretty invasive.

So I am okay with abandoning it for now.

Paul