Re: [IPsec] IKE fragmentation

Paul Wouters <> Thu, 14 March 2013 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 194CE21F90B5 for <>; Thu, 14 Mar 2013 07:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A+bVfEy7SCkd for <>; Thu, 14 Mar 2013 07:28:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5107821F90AF for <>; Thu, 14 Mar 2013 07:28:01 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3ZRXMJ6pDZz3sq; Thu, 14 Mar 2013 10:27:56 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id PlyqWAtU4sX9; Thu, 14 Mar 2013 10:27:53 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP; Thu, 14 Mar 2013 10:27:53 -0400 (EDT)
Received: by (Postfix, from userid 500) id EC09480860; Thu, 14 Mar 2013 10:27:52 -0400 (EDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8D7E8085F; Thu, 14 Mar 2013 10:27:52 -0400 (EDT)
Date: Thu, 14 Mar 2013 10:27:52 -0400
From: Paul Wouters <>
To: Yoav Nir <>
In-Reply-To: <>
Message-ID: <>
References: <> <294A12724CB849D2A33F7F80CC82426A@buildpc> <> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <> <FCC464E01434424EB7EB4365E86F9130@buildpc> <>
User-Agent: Alpine 2.03 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
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:28:07 -0000

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)