> 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.
Yes, in our solution only protected messages could be fragmented. This is
its limitation.
But in IKEv2 all messages except for IKE_SA_INIT, IKE_SA_RESUME and some
informational must be protected.
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.
Yes, but initiator needs to do it in any case. You cannot send protected
message (fragmented or not) without calculating DH, SKEYSEED etc.
Of course, the D-H calculation is not per-fragment, and I did not claim
that this was the case.
Sorry I didn't quite catch you.
> And you spent absolutetly the same amount of CPU power to
> calculate/verify ICV on
> fragments as you would spend it on non-fragmented message
You spend the same amount only if you require that your ICV verify. This
is not needed for creating DoS on the way fragmentation
is done in IKEv1.
ICV must be verified in any case - fragmented or non-fragmented.
> (probably a little bit more, as total length of all fragments of one
> message could
> be a bit more than the length of original message due to padding, IKE
> header and so on,
> but the usual difference is few percents).
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.
Yes, as I've said there is some penalty. It may differ depending on
algorithm and implementation.
I don't see a big problem here, as ICV computation must be fast anyway.
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
