Re: [IPsec] IKE fragmentation

Tero Kivinen <kivinen@iki.fi> Thu, 14 March 2013 14:31 UTC

Return-Path: <kivinen@iki.fi>
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 073FA11E8192 for <ipsec@ietfa.amsl.com>; Thu, 14 Mar 2013 07:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 9voWl0iEO6fx for <ipsec@ietfa.amsl.com>; Thu, 14 Mar 2013 07:31:43 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC15B11E8188 for <ipsec@ietf.org>; Thu, 14 Mar 2013 07:31:21 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2EETiDF014461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 16:29:44 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2EEThQn000832; Thu, 14 Mar 2013 16:29:43 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20801.57047.617753.249763@fireball.kivinen.iki.fi>
Date: Thu, 14 Mar 2013 16:29:43 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Yoav Nir <ynir@checkpoint.com>
In-Reply-To: <FCFD00C2-2A6F-4D13-A98C-37BE16DD8A35@checkpoint.com>
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>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 18 min
X-Total-Time: 17 min
Cc: "<ipsec@ietf.org>" <ipsec@ietf.org>, Valery Smyslov <svanru@gmail.com>
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 14:31:48 -0000

Yoav Nir writes:
> > There is no DH calculating per fragment. DH is calculated once in
> > IKE_SA_INIT 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. 

I would assume all implementations start doing Diffie-Hellman even
before than they even see the first fragment. I.e. when the responder
sends it IKE_SA_INIT reply back it will also start the Diffie-Hellman
calculation on the background so it might be ready when it gets next
packet from the initiator. The initiator must do the Diffie-Hellman
before it can send first IKE_AUTH packet anyways.

When responder gets IKE_AUTH packet from the initiator, then they will
start Diffie-Hellman calculation if they have not yet done it
previously. 

> 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.
Responder must do Diffie-Hellman anyways before it can process
incoming IKE_AUTH. And as the fragments are not acknowledged
separately the responder implementation can store all the encrypted
and authenticated fragments wihtout checking and when it all of them,
it can do Diffie-Hellman and decrypt + authentication to all of them,
just like in the IKEv1 fragment version. So there is no big difference
there.

The big differences is that smart implementation can check fragments
as they come in, thus it can immediately reject bogus fragments, and
only store and try reassembly on the valid fragments.

As earlier explained not doing that allows very wasy DoS attack, which
allows IKEv2 to finish by just sending very few packets, i.e. you send
one corrupted fragment to the packet and if you do that before
responder gets the correct fragment, the responder stores it for
reassembly and after it reassembles the packet it will only then
notice that the packet is corrupted, and then it needs to throw the
whole packet away. It cannot know which of the fragment is corrupted.
This means the initiator needs to retransmit whole packet, i.e. all
fragments of it, and attacker can do this again.

I think doing authentication per fragment is MUCH better method of
doing the fragmentation. 

> 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":

We are talking about IKE_AUTH here, and we will do the Diffie-Hellman,
and most likely also public key signature verification and generation
here (fragmentation is most likely only needed if we do have
certificates inside the packet, shared secret authentication should
work without fragmentation). 

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

It's actually more useful to compare the speeds from the 1024 bytes
down to 512 bytes and then add Diffie-Hellman over group 14 and RSA
signature verification + generation over 2048 bit key and check the
time difference there. I would expect it to be almost unnoticeable. 
-- 
kivinen@iki.fi