Re: Fragment ID generation and Flow Label generation

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 29 January 2012 19:46 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7B221F8570 for <ipv6@ietfa.amsl.com>; Sun, 29 Jan 2012 11:46:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.576
X-Spam-Level:
X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 2P7eGuuwcpMA for <ipv6@ietfa.amsl.com>; Sun, 29 Jan 2012 11:46:26 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9F2821F852C for <ipv6@ietf.org>; Sun, 29 Jan 2012 11:46:25 -0800 (PST)
Received: by eekc1 with SMTP id c1so1164493eek.31 for <ipv6@ietf.org>; Sun, 29 Jan 2012 11:46:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vMPy0cxjAoeg6xXdrYNCNWd+FeVfr1D3SQZS2asUeVs=; b=bOD5/Z3a4SvdYPLRMQ/o/G5nkZpHjF+pGn4p8Phb+zkzRraQdLYAnMGnf10dDlPGrI Ao7644RRn2F/2CdZt48Z3nC64gtfF2yRq5di5f8ThGEkgdIAP85biSO9680a23AUf9SE NrDr391OuysdZ7R55uGLWsbhECWErcQ+GX1is=
Received: by 10.14.13.129 with SMTP id b1mr1702385eeb.41.1327866385038; Sun, 29 Jan 2012 11:46:25 -0800 (PST)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id t11sm35668269eea.10.2012.01.29.11.46.22 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 11:46:24 -0800 (PST)
Message-ID: <4F25A206.1070701@gmail.com>
Date: Mon, 30 Jan 2012 08:46:14 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>
Subject: Re: Fragment ID generation and Flow Label generation
References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <m1Rqjjw-0001oHC@stereo.hq.phicoh.net> <4F22CE8C.2030107@si6networks.com> <m1Rqpit-0001jbC@stereo.hq.phicoh.net> <4F22F884.1080101@si6networks.com> <m1Rqt1p-0001ivC@stereo.hq.phicoh.net> <4F23219A.10101@si6networks.com> <4F23AAFC.6010404@si6networks.com>
In-Reply-To: <4F23AAFC.6010404@si6networks.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Philip Homburg <pch-6man-1a@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 29 Jan 2012 19:46:26 -0000

On 2012-01-28 20:59, Fernando Gont wrote:

...
> A similar approach could be implemented for the generation of Fragment
> Identification values.
> 
> Thus, even if you needed to empty the Destinations Cache, you'd still
> have the benefit that the algorithm:
> * Makes the IDs (either FL or Fragment ID) difficult to guess by an
> off-path attacker
> * Minimize the reuse frequency of the corresponding IDs.

I think it's a mistake to draw a strong analogy between the flow label
and the fragment ID.

When the flow label is used for any form of load distribution, it
really doesn't matter if occasional flows share the same label value,
as long as this is statistially rare. It just means that the two flows
might happen to follow the same path - so what? Thus, a completely
stateless algorithm is fine and the counter brings no benefit.

OTOH surely we need to completely avoid overlapping fragment IDs.

   Brian