Re: [IPsec] IKE fragmentation

[Yoav Nir <[e-mail]>]

On Mar 14, 2013, at 9:38 AM, Valery Smyslov <[e-mail]> wrote:

> Hi Yoav.
> 
>> > I agree that term "authenticated" is a bit misleading here.
>> > The better term would be "integrity protected".
>> > In our proposal receiver can be absolutely sure that
>> > each fragment comes from the very peer he/she exchanged
>> > DH exponents and calculated shared secret with.
>> >
>> > All fragments which ICV cannot be verified are discarded
>> > and don't prevent communication with real peer in any way.
>> 
>> So in order to get the responder to spend memory resources on storing the fragment, the initiator needs to expand
>> CPU resources on  completing the D-H calculation, and calculating integrity protection on the fragment. Makes sense.
> 
> Sorry, did you read the draft?

Yes.

> 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.

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. Of course, the D-H calculation is not per-fragment, and I did not claim that this was the case.

> 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.

> (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.

> 
> Let me emphasize again.
> 1. In our proposal sender and receiver spend roughly the same amount of CPU power
>   as they would spend on protecting/verifying non-fragmented message.
> 2. In our proposal sender and receiver spend roughly the same amount of CPU power
>   as they would spend on protecting/verifying fragmented message in Cisco/MS solution.
> 3. In our proposal sender needs to encrypt/protect one message twice only once
>   per SA establishments and only if he/she tries first to send unfragmented
>   message and after some retransmits decides to resend it fragmented.
>   This is avoidable if sender always sends large messages fragmented.
> 4. Comparing to Cisco/MS solution our proposal allows receiver to
>   verify integrity of individual fragment, so forged fragments will not
>   consume receiver's memory and could not prevent receiver
>   from getting valid fragments.
> 
>> What do you get when you put together the fragments? a decrypted IKE message?  Just the list of payloads?
> 
> After you decrypt and verify content of Encrypted Fragment Payload of all fragments,
> get rid of now unnecessary headers and put all together, you get a decrypted IKE message.

Good.

Yoav