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
- [IPsec] IKE fragmentation Tero Kivinen
- Re: [IPsec] IKE fragmentation Valery Smyslov
- Re: [IPsec] IKE fragmentation Yaron Sheffer
- Re: [IPsec] IKE fragmentation Paul Wouters
- Re: [IPsec] IKE fragmentation Valery Smyslov
- Re: [IPsec] IKE fragmentation Valery Smyslov
- Re: [IPsec] IKE fragmentation Paul Wouters
- Re: [IPsec] IKE fragmentation Valery Smyslov
- Re: [IPsec] IKE fragmentation Paul Wouters
- Re: [IPsec] IKE fragmentation Derek Atkins
- Re: [IPsec] IKE fragmentation Yoav Nir
- Re: [IPsec] IKE fragmentation Yoav Nir
- [IPsec] Informal poll on IKEv2 { over TCP | fragm… Paul Hoffman
- Re: [IPsec] Informal poll on IKEv2 { over TCP | f… Yoav Nir
- Re: [IPsec] Informal poll on IKEv2 { over TCP | f… Paul Wouters
- Re: [IPsec] IKE fragmentation Valery Smyslov
- Re: [IPsec] Informal poll on IKEv2 { over TCP | f… Valery Smyslov
- Re: [IPsec] IKE fragmentation Yoav Nir
- Re: [IPsec] IKE fragmentation Paul Wouters
- Re: [IPsec] IKE fragmentation Tero Kivinen
- Re: [IPsec] IKE fragmentation Yoav Nir
- Re: [IPsec] IKE fragmentation Yoav Nir
- Re: [IPsec] IKE fragmentation Valery Smyslov
- Re: [IPsec] IKE fragmentation Paul Wouters
- Re: [IPsec] IKE fragmentation Valery Smyslov
- Re: [IPsec] IKE fragmentation Tero Kivinen
- Re: [IPsec] Informal poll on IKEv2 { over TCP | f… Paul_Koning
- Re: [IPsec] IKE fragmentation Yaron Sheffer
- [IPsec] Informal poll on IKEv2 { over TCP | fragm… Tero Kivinen
- Re: [IPsec] Informal poll on IKEv2 { over TCP | f… Brian Weis