Re: 6MAN WG Last Call: <draft-ietf-6man-flow-update-04.txt>

Brian E Carpenter <> Mon, 02 May 2011 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 296C3E07D9 for <>; Mon, 2 May 2011 14:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.465
X-Spam-Status: No, score=-103.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UrD+drnrpH1g for <>; Mon, 2 May 2011 14:37:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 72198E07D8 for <>; Mon, 2 May 2011 14:37:58 -0700 (PDT)
Received: by pzk5 with SMTP id 5so4000358pzk.31 for <>; Mon, 02 May 2011 14:37:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UlgeDV42Iw/8trqSVhyv2HUpEtuNKn2+0aLHeIBl16A=; b=dt5BRwC/mRfDWWtrbT4xVL6sYOmlB2CDd21ZzmO6hn24CsB2qvYE2ULpahak4kkBoa hTytwAv9OKrzfXosFlTGrZNpRHxSi2Vl50CGfZtbf/XxTRmmoOYxvjtK3lbDhZNsMjw8 HkhTNfS/48dI2tMCOXG1cNW9Ydd2SB35RtPQc=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=vKY11zNHt4EuibPjV2XDOoT9HGnfTWyBgwp+/tvJF4Rw3FkztvJnW0MJqdV0Bttvg5 dSK4JZBzwZOa/CtNYCS3ytvxcrFIwHNeiztklASNfBmKphH0gIrz5eDG5jNbNkyhwqIq qsGAfy/tY/AEXoycyWsaMaJKW2w3JdMLTlwmw=
Received: by with SMTP id v5mr9284452pbk.467.1304372277766; Mon, 02 May 2011 14:37:57 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id s7sm52247pbn.15.2011. (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:37:57 -0700 (PDT)
Message-ID: <>
Date: Tue, 03 May 2011 09:37:53 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Thomas Narten <>, 6man Mailing List <>
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-update-04.txt>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 May 2011 21:37:59 -0000

On 2011-04-06 06:09, Thomas Narten wrote:
> Here are my comments on this document.
> My main issue is that it continues to assert that flow labels are
> required to be pseudo random. I am not convinced that is necessary and
> I think it makes things more complex than necessary.

Emphasis changed to uniform distribution (and some text added why this is desirable).
See comments on 3697bis.

> Detailed comments:
> Review of -04
>        Also, it could be used as a covert data channel, since apparently
>        pseudo-random flow label values could in fact consist of covert data.
> drop "pseudo-random" as that is not relevant to the point.

Oh yes it is ;-). If the bits are cyphertext encrypted with a good algorithm,
as they would be in serious covert usage, they would indeed appear pseudo-random.
If somebody included plaintext in the flow label, that would hardly be covert.

>    As a result, some security
>    specialists believe that flow labels should be cleared for safety.
> If you don't have a reference to this, please delete.

It's mentioned in draft-gont-6man-flowlabel-security.

>    However, it is recommended that sources should set a pseudo-random
>    flow label value in all flows, replacing the less precise
>    recommendation made in Section 3 of RFC 3697.  Both stateful and
> Again, I don't think we have agreement on this "recommendation".

Ack, see above.

>    mathematically on immutable flow labels.  The new rules require that
>    flow labels exported to the Internet should always be either zero or
>    pseudo-random, but even this cannot be relied on mathematically.  Use
> Pseudo random requirement again...


   Brian, for the authors