Re: [secdir] review of draft-ietf-6man-predictable-fragment-id-09

Fernando Gont <fgont@si6networks.com> Wed, 09 September 2015 11:37 UTC

Return-Path: <fgont@si6networks.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 DA8B71A003A; Wed, 9 Sep 2015 04:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 oYJrplACWWrp; Wed, 9 Sep 2015 04:37:30 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722AF1A00BB; Wed, 9 Sep 2015 04:37:30 -0700 (PDT)
Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <fgont@si6networks.com>) id 1ZZdfk-0001nf-Ek; Wed, 09 Sep 2015 13:36:16 +0200
To: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>, "draft-ietf-6man-predictable-fragment-id.all@tools.ietf.org" <draft-ietf-6man-predictable-fragment-id.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
References: <4F5FD3E9-B5A3-4AAB-A089-61B674B59ECC@cisco.com>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55F010E9.2060606@si6networks.com>
Date: Wed, 09 Sep 2015 07:58:49 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <4F5FD3E9-B5A3-4AAB-A089-61B674B59ECC@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/aX2diq7UCq-LWe6_XXFwz-wIzCk>
Subject: Re: [secdir] review of draft-ietf-6man-predictable-fragment-id-09
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 09 Sep 2015 11:37:32 -0000

Hi, Klaas,

Thanks so much for your feedback! -- Please find my responses in-line...

On 09/09/2015 07:12 AM, Klaas Wierenga (kwiereng) wrote:
> I believe the document has some issues, see below.
> 
> The document does an analysis of the security implications of
> predictable identification fields and I believe (not being an IPv6
> expert) that it does a good job at that. The analysis of the
> potential exploits is convincing. Where I am struggling a bit is the
> algorithms for selecting fragment identification values (5).
> 
> The intro text states that there are ‘a number of algorithms', but
> really there are only 3: 1- per destination counter random
> initialised 2- random value 3- hash over source, destination, secret
> with a counter

FWIW, these are three concrete algorithms, but that doesn't mean they
are the only possible ones...



> 1 and 3 are essentially the same, the hash function in 3 performs the
> same function as the pseudo random generated initial value in 1 if I
> am not mistaken.

Yes and no. 1 requires state, but 3 doesn't. That means that, e.g., if
you have lot's of flows to many different destinations, you may need to
remove some entries from the Dest Cache (and then you run the risk of
Frag ID collisions). However, this is not the case with algorithm #3.



> So really the choice is between a random value for
> every datagram or a random value at initialisation of a connection
> and increasing by 1 for every subsequent datagram.
> 
> I’d really like to see some quantitative analysis as to the impact of
> a random value per packet as well as between 1 and 3.

Impact in terms of what?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492