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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
