Re: [IPsec] IKE fragmentation

[Yoav Nir <[e-mail]>]

On Mar 14, 2013, at 10:27 AM, Paul Wouters <[e-mail]> wrote:

> On Thu, 14 Mar 2013, Yoav Nir wrote:
> 
>> 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.
> 
> I don't understand this part? Legitimate fragments won't have a
> count higher then about 10. Current implementations I've seen cap at
> 16 fragments. If you receive a fragment number higher then that, you
> discard the whole thing. You could even wait with decrypting until you
> got all fragments.

True for the way things are done in IKEv1, but Valery's draft has you at least calculating the MAC for each fragment before storing. MAC-ing each fragment is 20% more expensive (for a 8000-byte message) than MAC-ing the whole thing. Not that it matters - it's all in the noise considering that there's also a D-H operation taking place.

> I don't see much value in authenticating each fragment. Possibly they
> would come in faster then you can decrypt each fragment anyway, so you
> need to store them regardless, especially in a DoS where the initiator
> does not perform real encryption for sending fragments.
> 
> I would likely implement it to receive all fragments, then run
> decryption on all its parts.

In that case you don't get the DoS protection offered by this draft.

> Furthermore, since we have the cookies/SPI, it is also pretty easy to
> ignore bogus fragments, and to require the 6 message echange when
> receiving a first-packet for a new exchange when under high load, so
> IKE spoofing won't cause us that much of a higher load.
> 
> So I'm not too worried about the DOS, and I'm leaning towards a similar
> model to the currently deployed method for IKEv1. Possibly dropping
> the useless "fragment id" (not fragment number)

It's a tradeoff of memory vs CPU. I'm not sure which is more constrained.

Yoav