Re: [IPsec] IKE fragmentation

[Yoav Nir <[e-mail]>]

On Mar 14, 2013, at 10:29 AM, Tero Kivinen <[e-mail]>
 wrote:

> Yoav Nir writes:
>>> 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. 
> 
> I would assume all implementations start doing Diffie-Hellman even
> before than they even see the first fragment. I.e. when the responder
> sends it IKE_SA_INIT reply back it will also start the Diffie-Hellman
> calculation on the background so it might be ready when it gets next
> packet from the initiator. The initiator must do the Diffie-Hellman
> before it can send first IKE_AUTH packet anyways.
> 
> When responder gets IKE_AUTH packet from the initiator, then they will
> start Diffie-Hellman calculation if they have not yet done it
> previously. 

My implementation does that. We only calculate the shared key when we need it - when the IKE_AUTH request arrives.

>> 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. Of course, the D-H calculation is not
>> per-fragment, and I did not claim that this was the case.
> 
> Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH.

True for a legitimate Initiator. At attacker can send fake fragments, and the responder has the option of expanding CPU resources for verifying the ICV, or expanding the memory resources for storing them for a while.

>> 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":
> 
> We are talking about IKE_AUTH here, and we will do the Diffie-Hellman,
> and most likely also public key signature verification and generation
> here (fragmentation is most likely only needed if we do have
> certificates inside the packet, shared secret authentication should
> work without fragmentation). 
> 
>> 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.
> 
> It's actually more useful to compare the speeds from the 1024 bytes
> down to 512 bytes and then add Diffie-Hellman over group 14 and RSA
> signature verification + generation over 2048 bit key and check the
> time difference there. I would expect it to be almost unnoticeable. 

I agree it's in the noise.