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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 02 May 2011 21:37 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 296C3E07D9 for <ipv6@ietfa.amsl.com>; Mon, 2 May 2011 14:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.465
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrD+drnrpH1g for <ipv6@ietfa.amsl.com>; Mon, 2 May 2011 14:37:58 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72198E07D8 for <ipv6@ietf.org>; Mon, 2 May 2011 14:37:58 -0700 (PDT)
Received: by pzk5 with SMTP id 5so4000358pzk.31 for <ipv6@ietf.org>; Mon, 02 May 2011 14:37:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; 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; b=vKY11zNHt4EuibPjV2XDOoT9HGnfTWyBgwp+/tvJF4Rw3FkztvJnW0MJqdV0Bttvg5 dSK4JZBzwZOa/CtNYCS3ytvxcrFIwHNeiztklASNfBmKphH0gIrz5eDG5jNbNkyhwqIq qsGAfy/tY/AEXoycyWsaMaJKW2w3JdMLTlwmw=
Received: by 10.68.40.69 with SMTP id v5mr9284452pbk.467.1304372277766; Mon, 02 May 2011 14:37:57 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id s7sm52247pbn.15.2011.05.02.14.37.55 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:37:57 -0700 (PDT)
Message-ID: <4DBF2431.8000306@gmail.com>
Date: Tue, 03 May 2011 09:37:53 +1200
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: Thomas Narten <narten@us.ibm.com>, 6man Mailing List <ipv6@ietf.org>
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-update-04.txt>
References: <2F8FF78F-24CF-4895-A5BC-EA4167D92C6D@gmail.com> <201104051809.p35I94HL018340@cichlid.raleigh.ibm.com>
In-Reply-To: <201104051809.p35I94HL018340@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: 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...
>

Ditto.

   Brian, for the authors