Hi Emeric, > Let's sum up the proposal: > - no: do not announce IKE frag support, drop received IKE fragmented packets
While we could do that, at least for IKEv1 it is not really possible (due to the `force` case - we handle the initial messages before we know what was configured). And I'm not sure if we gain much if we drop them outright anyway (would be a lot more code changes too). Actually, I noticed that there is no code that restricts `force` to be IKEv1-only. However, since IKEv2 fragmentation requires an encrypted payload it has no effect on IKE_SA_INIT messages, but it still forces every packet to be fragmented, even if the peer didn't announce its support for the extension. So you could configure one IKEv2 peer with `force` and the other with `no` and that still works because we currently don't drop these messages. > - accept: announce IKE frag support, accept IKE fragmented packets > - yes: announce IKE frag support, accept IKE fragmented packets and emit > fragmented packets using the other option to set the max fragment size. That's simple enough to implement. See the fragments-accept branch. > By the way, is there any known resource attack based on IKE > fragmentation? I guess that depends on the implementation. In our current code base we store the fragments in a sorted array and drop duplicates. For IKEv1 the maximum number of fragments is naturally limited to 255 because the fragment number is just one byte. For IKEv2 we limit the maximum to 255 explicitly. And the total size of all fragments per message is limited by charon.max_packet. Regards, Tobias _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users