Hello, >> 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.
Thanks for implementing this. However, there is no .c code involved in the mentioned branch: is it enough to make it work? Regards, Emeric _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users