Re: Pseudorandom Flow Labels

Thomas Narten <narten@us.ibm.com> Tue, 05 April 2011 20:35 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4193428B797 for <ipv6@core3.amsl.com>; Tue, 5 Apr 2011 13:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.682
X-Spam-Level:
X-Spam-Status: No, score=-106.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpwu+Nts2UlP for <ipv6@core3.amsl.com>; Tue, 5 Apr 2011 13:35:17 -0700 (PDT)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 8FA9028C0E9 for <ipv6@ietf.org>; Tue, 5 Apr 2011 13:35:17 -0700 (PDT)
Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35KBC6v005309 for <ipv6@ietf.org>; Tue, 5 Apr 2011 16:11:12 -0400
Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 7E6626E803E for <ipv6@ietf.org>; Tue, 5 Apr 2011 16:36:54 -0400 (EDT)
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p35KarwT2252998 for <ipv6@ietf.org>; Tue, 5 Apr 2011 16:36:53 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35Kaq5x029998 for <ipv6@ietf.org>; Tue, 5 Apr 2011 16:36:53 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-65-200-167.mts.ibm.com [9.65.200.167]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p35KapSj029918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 16:36:52 -0400
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p35KaoHV019253; Tue, 5 Apr 2011 16:36:51 -0400
Message-Id: <201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com>
To: Shane Amante <shane@castlepoint.net>
Subject: Re: Pseudorandom Flow Labels
In-reply-to: <BD901061-96AC-4915-B7CE-2BC1F70861A5@castlepoint.net>
References: <BD901061-96AC-4915-B7CE-2BC1F70861A5@castlepoint.net>
Comments: In-reply-to Shane Amante <shane@castlepoint.net> message dated "Tue, 05 Apr 2011 13:22:16 -0600."
Date: Tue, 05 Apr 2011 16:36:50 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
Cc: 6man List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 20:35:18 -0000

Case in point about how we are being *extremely* loose in using the
term "pseudo random".

If you look at draft-gont-6man-flowlabel-security-01, it proposes two
different algorithms for generating Flow Label values.

Unless I'm missing something, neither of them actually provides
"pseudo randomness". Both have subsequent Flow Label values simply
increment a counter to get to the next value. What these algorithms do
do is make it very hard for an off-site attacker to guess what Flow
Label values are being used. That is probably a good thing. But that
is not the same thing as saying that the Flow Labels that are
generated are "pseudo random", which is what the current Flow Label
documents are saying we need.

Part of my objection to the term "pseudo random" is that the term has
not been defined within the context of the Flow Label.

RFC 4086 "Randomness Requirements for Security" talks quite a bit
about pseudo randomness. I don't think we need that for the Flow
Label. But without carefully defining terms, that is what is
presumably being required...

Thomas