Re: [IPsec] IKE fragmentation

"Valery Smyslov" <> Thu, 14 March 2013 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF70711E81D0 for <>; Thu, 14 Mar 2013 07:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.003
X-Spam-Level: ***
X-Spam-Status: No, score=3.003 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dmTCI0zOdbe1 for <>; Thu, 14 Mar 2013 07:51:16 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22c]) by (Postfix) with ESMTP id 3014411E819E for <>; Thu, 14 Mar 2013 07:51:15 -0700 (PDT)
Received: by with SMTP id eb20so2585568lab.17 for <>; Thu, 14 Mar 2013 07:51:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=ztS6cUSjinRkn8lP+zFAv4i7T1CvF94ukVGhCXdvC6Q=; b=gFxU8YbCEKhs2HURJKeQpxszN9pz8er/JXwzE2qQh1fO1s4iDw56fIR/PzypuVu5HP 2847Ke4EEqRtg+M59R/e6SC72wrcOi5V6A3PH534vkOqxyR9gyr8unMZfFTGW5+X3qCj sdmikoER8JYJC4lmEsYMgYvQtJx6a8sWWCVyskMZjG2XgeKT9CSTWNNvOxqS8dKlC2m/ XdhDwa9knh6PXIh4RoPOPmIz5FyWokL8T980OVUYMJ0GMEYl29tABupRrQD9y2dckMZk i29HWJEegWufwcd3e2u8SA+OAzeRzRw0PM9Qiple6N67Cg790gzTbZ2LH9LY0iGehNsB Q91g==
X-Received: by with SMTP id mt15mr2477731lab.26.1363272674104; Thu, 14 Mar 2013 07:51:14 -0700 (PDT)
Received: from buildpc ([]) by with ESMTPS id o11sm915399lbu.6.2013. (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 07:51:13 -0700 (PDT)
Message-ID: <8499A22E140C4EE3AAD3D79C4E304094@buildpc>
From: Valery Smyslov <>
To: Yoav Nir <>
References: <> <294A12724CB849D2A33F7F80CC82426A@buildpc> <> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <> <FCC464E01434424EB7EB4365E86F9130@buildpc> <>
Date: Thu, 14 Mar 2013 18:51:27 +0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Cc:, 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:51:17 -0000

> > There is no DH calculating per fragment. DH is calculated once in 
> > 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.