On Mar 14, 2013, at 10:27 AM, Paul Wouters <p...@cypherpunks.ca> 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
