Re: [secdir] sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06

"Derek Atkins" <derek@ihtfp.com> Thu, 03 April 2014 15:00 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463541A01DC; Thu, 3 Apr 2014 08:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level:
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1LDhEM5j01S; Thu, 3 Apr 2014 08:00:29 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 12EA61A01C2; Thu, 3 Apr 2014 08:00:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 29158E2033; Thu, 3 Apr 2014 11:00:24 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20433-10; Thu, 3 Apr 2014 11:00:20 -0400 (EDT)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id CB478E2036; Thu, 3 Apr 2014 11:00:20 -0400 (EDT)
Received: from 192.168.248.230 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 3 Apr 2014 11:00:20 -0400
Message-ID: <89fe86e74a6e22a538adcc0cc3db2489.squirrel@mail2.ihtfp.org>
In-Reply-To: <B90F5487B44E4F5E9B0904B14FE94D90@buildpc>
References: <sjmzjk2ijfd.fsf@mocana.ihtfp.org> <B90F5487B44E4F5E9B0904B14FE94D90@buildpc>
Date: Thu, 3 Apr 2014 11:00:20 -0400
From: "Derek Atkins" <derek@ihtfp.com>
To: "Valery Smyslov" <svan@elvis.ru>
User-Agent: SquirrelMail/1.4.22-13.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/AiJcd8V_HkKofppBQd-jp8JUVdM
Cc: ipsecme-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Apr 2014 15:00:33 -0000

Hi,

On Thu, April 3, 2014 10:42 am, Valery Smyslov wrote:
>>
>> There is still a minor issue where you move the exhaustion attack from
>> the IP layer to the IKE layer -- an attacker could, theoretically,
>> fill an IKE session with incomplete fragments causing it to use
>> resources waiting for missing fragments.
>
> Note, that in this proposal each IKE fragment is individually protected -
> encrypted and authenticated. Forged fragments will be detected
> before they are placed into reassembling queue and thus they
> couldn't exhaust receiver's resources - only fragments from real peer
> will be taken into consideration. And if attacker is capable enough
> to drop an arbitrary IP packet, than there is no protection
> anyway - the connection will fail on attacker's will in any case,
> with or without IKE fragmentation.

It's only authenticated in the sense that you have to have already had a
full round trip so yes, an attacker can not forge their source IP.  But
that doesn't prevent a true DDoS where real hosts (think botnet) all
perform a real IKE_SA_INIT and then use their sessions to build a lot of
held state with "fake" fragments that will never complete.

Like I said, it's an improvement because it's not at the kernel IP layer,
and theoretically there are more resources available at the IKE layer. 
But it probably should still be mentioned.  (Not that IKE without
fragmentation isn't also subject to this kind of DDoS attack).

Thanks,

>
> Regards,
> Valery Smyslov.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant