Re: [IPsec] IKE fragmentation

"Valery Smyslov" <svanru@gmail.com> Thu, 14 March 2013 15:08 UTC

Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925EB11E8271 for <ipsec@ietfa.amsl.com>; Thu, 14 Mar 2013 08:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.57
X-Spam-Level: **
X-Spam-Status: No, score=2.57 tagged_above=-999 required=5 tests=[AWL=0.867, 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blFqtj+2CcrM for <ipsec@ietfa.amsl.com>; Thu, 14 Mar 2013 08:08:56 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DE58111E8262 for <ipsec@ietf.org>; Thu, 14 Mar 2013 08:08:37 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id fs13so2545612lab.8 for <ipsec@ietf.org>; Thu, 14 Mar 2013 08:08:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=nDC1R7Zl+3Sa0gSSSyoWvDPr7nX/byQDzjC1UdMFnXg=; b=e3D88hoKnF57vzy4H3FvtuyTirTPPOLjYs30DHS6GkOoRaxReWWau8AXndwJGyQw6V +rtVvytCQTm+dTkfhOi2z2t8r3fVg9vemz1ytoum77g7gElIezbk9jsa4MG72FZi4VI6 II4Ynvay4wOtz3KYi5Voidoq8b5wvZaZQqsBOd66cc6BN06BlcpWc0mruUovSogTXPnC dC9QHurSNhmk/qQICyu2zAE9W6cqKv84mCphLaDTbdIdJ9PURjjHroGbA62+ruBiAMLl pOg+MzeusntrvfNr8OGIULUMVeJZff/ST1ZiozI0Scss6PFOxVeXiZwpgs35QWBXWU+2 l9hg==
X-Received: by 10.152.105.17 with SMTP id gi17mr2457252lab.46.1363273714272; Thu, 14 Mar 2013 08:08:34 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id c10sm928089lbu.11.2013.03.14.08.08.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 08:08:33 -0700 (PDT)
Message-ID: <37EA3A0F84914E7FAB43CF50ABA9F780@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: Yoav Nir <ynir@checkpoint.com>, Tero Kivinen <kivinen@iki.fi>
References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <A5B456F7-DE58-4755-95B0-97D5D15D066C@checkpoint.com> <FCC464E01434424EB7EB4365E86F9130@buildpc> <FCFD00C2-2A6F-4D13-A98C-37BE16DD8A35@checkpoint.com> <20801.57047.617753.249763@fireball.kivinen.iki.fi> <EDE18D36-816E-4B4A-8D98-CCC9FC45A1F3@checkpoint.com>
Date: Thu, 14 Mar 2013 19:08:47 +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: ipsec@ietf.org
Subject: Re: [IPsec] IKE fragmentation
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 15:08:58 -0000

> >> 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.
> >
> > Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH.
>
> True for a legitimate Initiator. At attacker can send fake fragments, and 
> the responder has the option of expanding
> CPU resources for verifying the ICV, or expanding the memory resources for 
> storing them for a while.

There is no difference comparing with usual, non-fragmented IKE_AUTH 
message -
responder still can be forced by attacker to complete DH, calculate keys and
try to verify forged message. And fragmentation doesn't make it worse.

And even with unprotected fragments it is not a big deal for attacker to 
send
you a set of fragments that you will successfully reassemble to a 
good-looking
message and then you again will have to complete DH, calculate keys and
try to verify that garbage. No difference.