[strongSwan] Question about IKE frag

Tobias Brunner tobias at strongswan.org
Fri May 5 15:50:51 CEST 2017

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.


More information about the Users mailing list