Re: [IPsec] IKE fragmentation

[Paul Wouters <[e-mail]>]

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.

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.

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)

Paul