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

Thomas Narten <narten@us.ibm.com> Tue, 05 April 2011 18:07 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 4ACF03A67DA for <ipv6@core3.amsl.com>; Tue, 5 Apr 2011 11:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.699
X-Spam-Level:
X-Spam-Status: No, score=-106.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 8pANcxD2oV30 for <ipv6@core3.amsl.com>; Tue, 5 Apr 2011 11:07:34 -0700 (PDT)
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id B50FF3A67B6 for <ipv6@ietf.org>; Tue, 5 Apr 2011 11:07:34 -0700 (PDT)
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35Hv7NE018902 for <ipv6@ietf.org>; Tue, 5 Apr 2011 11:57:07 -0600
Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p35I97xJ120220 for <ipv6@ietf.org>; Tue, 5 Apr 2011 12:09:07 -0600
Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35IE25X007402 for <ipv6@ietf.org>; Tue, 5 Apr 2011 12:14:02 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-65-200-167.mts.ibm.com [9.65.200.167]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p35IE1I7007355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 12:14:02 -0600
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 p35I94HL018340; Tue, 5 Apr 2011 14:09:04 -0400
Message-Id: <201104051809.p35I94HL018340@cichlid.raleigh.ibm.com>
To: Bob Hinden <bob.hinden@gmail.com>
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-update-04.txt>
In-reply-to: <2F8FF78F-24CF-4895-A5BC-EA4167D92C6D@gmail.com>
References: <2F8FF78F-24CF-4895-A5BC-EA4167D92C6D@gmail.com>
Comments: In-reply-to Bob Hinden <bob.hinden@gmail.com> message dated "Mon, 21 Mar 2011 10:15:42 -0700."
Date: Tue, 05 Apr 2011 14:09:04 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: Brian Haberman <brian@innovationslab.net>, 6man Mailing 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 18:07:35 -0000

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.

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.

   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.

   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".

   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...

Thomas