Re: [IPsec] IKE fragmentation

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0290821F8CF7 for <>; Thu, 14 Mar 2013 06:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 4.303
X-Spam-Level: ****
X-Spam-Status: No, score=4.303 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 5TdA2dvUnyTp for <>; Thu, 14 Mar 2013 06:38:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::231]) by (Postfix) with ESMTP id C9ECE21F8CE2 for <>; Thu, 14 Mar 2013 06:38:49 -0700 (PDT)
Received: by with SMTP id fs13so2466467lab.36 for <>; Thu, 14 Mar 2013 06:38:36 -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=5gTJWPIJ/lmtfsrMmiahCxSaaEhAGv/1SYowb4ApJvY=; b=Nl6+g9FBEYNtsG+OL4Ev58kPHv59uLNgqjhg6yx5Bt7uMbazAC43hPlZ9FxQn1U6pD XinWSPI5PdfswDhPaXbQAneKIoQSLA4F3s+QZbQ6mXutMMz2K//gkpu9QAJFdloDYqnl 8rCe34JllrZfydrlqsaYqImjx34GS+Vg3/td9dmTmUZRkm5+P83Z5svtSK5bdApQRCyq wZMu99YdHr15TAVCsu5TeKnHT6Y5E1onfMASK/mcBH2DZa3fqgjDSIaWAmo2aQMNvVm/ gMeTR39A+pzOYD1IL79FgOtcHxT5mt49Q9cNKjwEbv8vw3Eza+on3SoVOpfkiYd/0635 CZFA==
X-Received: by with SMTP id so10mr2286392lab.9.1363268316597; Thu, 14 Mar 2013 06:38:36 -0700 (PDT)
Received: from buildpc ([]) by with ESMTPS id go12sm1206639lab.3.2013. (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 06:38:35 -0700 (PDT)
Message-ID: <FCC464E01434424EB7EB4365E86F9130@buildpc>
From: Valery Smyslov <>
To: Yoav Nir <>
References: <> <294A12724CB849D2A33F7F80CC82426A@buildpc> <> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <>
Date: Thu, 14 Mar 2013 17:38:48 +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 13:38:51 -0000

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?

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

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
(probably a little bit more, as total length of all fragments of one message 
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).

Let me emphasize again.
1. In our proposal sender and receiver spend roughly the same amount of CPU 
    as they would spend on protecting/verifying non-fragmented message.
2. In our proposal sender and receiver spend roughly the same amount of CPU 
    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 
    per SA establishments and only if he/she tries first to send 
    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 
get rid of now unnecessary headers and put all together, you get a decrypted 
IKE message.

> Yoav=