(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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec