Re: [IPsec] IKE fragmentation

Yoav Nir <> Thu, 14 March 2013 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03D0321F8DF9 for <>; Thu, 14 Mar 2013 07:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oa+GyVpmpoeY for <>; Thu, 14 Mar 2013 07:38:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F1F0311E811F for <>; Thu, 14 Mar 2013 07:38:09 -0700 (PDT)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r2EEc07X004865; Thu, 14 Mar 2013 16:38:00 +0200
X-CheckPoint: {5141DFEB-0-1B221DC2-2FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 16:38:00 +0200
From: Yoav Nir <>
To: Paul Wouters <>
Thread-Topic: [IPsec] IKE fragmentation
Thread-Index: AQHOH/P+dHmEPMd7P0SMbddmnpEj3pikJ5oAgAEK/gb//+digIAABM8AgAAC0gA=
Date: Thu, 14 Mar 2013 14:37:58 +0000
Message-ID: <>
References: <> <294A12724CB849D2A33F7F80CC82426A@buildpc> <> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <> <FCC464E01434424EB7EB4365E86F9130@buildpc> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>, Valery Smyslov <>, Tero Kivinen <>
Subject: Re: [IPsec] IKE fragmentation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Mar 2013 14:38:29 -0000

On Mar 14, 2013, at 10:27 AM, Paul Wouters <> 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.