Re: [IPsec] IKE fragmentation

["Valery Smyslov" <[e-mail]>]

> > There is no DH calculating per fragment. DH is calculated once in 
> > IKE_SA_INIT
> > as in ordinary IKE SA establishment (note, that unprotected messages, 
> > including IKE_SA_INIT
> > and IKE_SA_RESUME cannot be fragmented).
>
> If we do IKEv2 fragments the way everyone does IKEv1 fragments, the 
> initiator can send multiple fragments that don't assemble to a
> protected packet, causing the responder to allocate memory to store these 
> fragments (at least for a short while). Doing this does not
> require completing the D-H calculation, and does not require running 
> either an encryption or MAC function.

Yes, in our solution only protected messages could be fragmented. This is 
its limitation.
But in IKEv2 all messages except for IKE_SA_INIT, IKE_SA_RESUME and some
informational must be protected.

> What your draft does, is force the initiator to protect each fragment. To 
> protect a fragment in a way that will cause the responder
> to store it, requires running the MAC function, and that in turn requires 
> generating the keys (running the PRF), which in turn requires
> completing the D-H calculation. If the initiator fails to do any of these 
> things, the fragment will be immediately rejected at the responder.

Yes, but initiator needs to do it in any case. You cannot send protected
message (fragmented or not) without calculating DH, SKEYSEED etc.

> Of course, the D-H calculation is not per-fragment, and I did not claim 
> that this was the case.

Sorry I didn't quite catch you.

> > And you spent absolutetly the same amount of CPU power to 
> > calculate/verify ICV on
> > fragments as you would spend it on non-fragmented message
>
> You spend the same amount only if you require that your ICV verify. This 
> is not needed for creating DoS on the way fragmentation
> is done in IKEv1.

ICV must be verified in any case - fragmented or non-fragmented.

> > (probably a little bit more, as total length of all fragments of one 
> > message could
> > be a bit more than the length of original message due to padding, IKE 
> > header and so on,
> > but the usual difference is few percents).
>
> Measurably more, because MAC functions have an initialization part, so 
> running it on a single packet by parts incurs the per-run
> overhead multiple times. See the differences in the throughput of HMAC 
> based on buffer size (obtained by running "opnessl speed":
>
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 
> bytes
> hmac(md5)        17801.04k    53527.61k   132966.20k   210528.97k 
> 253873.49k
>
> So if the packet is 8000 bytes, and you divided it into 1024 fragments, 
> you would incur a slightly more than 20% penalty.

Yes, as I've said there is some penalty. It may differ depending on 
algorithm and implementation.
I don't see a big problem here, as ICV computation must be fast anyway.

Valery.