Pseudorandom Flow Labels

Shane Amante <shane@castlepoint.net> Tue, 05 April 2011 19:20 UTC

Return-Path: <shane@castlepoint.net>
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 D50353A6407 for <ipv6@core3.amsl.com>; Tue, 5 Apr 2011 12:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level:
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599]
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 tCnKoMXnCsyE for <ipv6@core3.amsl.com>; Tue, 5 Apr 2011 12:20:34 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 28FE53A63CA for <ipv6@ietf.org>; Tue, 5 Apr 2011 12:20:34 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 39FB2268676; Tue, 5 Apr 2011 13:22:17 -0600 (MDT)
Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 05 Apr 2011 13:22:17 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=59821; data-bytes=0
From: Shane Amante <shane@castlepoint.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Pseudorandom Flow Labels
Date: Tue, 5 Apr 2011 13:22:16 -0600
Message-Id: <BD901061-96AC-4915-B7CE-2BC1F70861A5@castlepoint.net>
To: Thomas Narten <narten@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
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 19:20:36 -0000

Thomas,

With respect to your comments on, both at the mic at the 6MAN WG and on the list:
draft-ietf-6man-flow-3697bis-02
draft-ietf-6man-flow-ecmp-01
draft-ietf-6man-flow-update-04

You seem to take issue with a recommendation for creating/selecting a flow-label that is "pseudo-random".  Can you clarify the reason(s) you take issue with creating/selecting a flow-label that is "pseudo-random"?  (IMO, the current 'SHOULD' in the draft provides enough leeway that if implementations have good reason(s) to not select pseudo-random values for flow-labels they can choose to do so, but would hopefully have good reasons for that).

The reason I ask is as follows:
1)  RFC 6056: Recommendations for Transport Protocol Randomization, in particular Appendix A.  In short, a lot of [deployed] implementations are already computing a pseudo-random value for a transport protocol port (within the ephemeral port range), today, so IMHO the implementation "burden" of choosing a pseudo-random value must be quite low and, in theory, there should be good re-use of that code/logic for selecting flow-labels.
2)  If we expect that if a intermediate router or switch is using *just* the 3-tuple of {src_ip, dst_ip + flow_label} as input-keys to compute a load-balancing hash algorithm, then the more random the flow-label, the better load-distribution of /all/ traffic will be across the LAG and/or ECMP paths.  Here's a few cases in point:
    a)  As a network operator I have no control over the number of IP addresses used by content farms or residential networks.  Furthermore, it's not clear that as more & more machines (and, smartphones!) ship that support multiple CPU's and/or multiple cores that each of those discrete computing units will (or, should?) receive their own IP address.  With IPv6 that's at least a possibly, but perhaps due to "ease of development", that won't happen often, or at all.  If we strongly recommend a pseudo-random flow-label and a device is only capable of load-balancing using a 3-tuple, then I've at least got a [relatively] unique flow-label in the packet header to provide load distribution.
    b)  The reason that we observe in today's production networks very good load-distribution over LAG and/or ECMP paths is most likely the result of, first, hosts selecting a pseudo-random value for their ephemeral ports (based on RFC 6056) and, second, the ability for intermediate routers/switches to use the traditional 5-tuple for input-keys for load-distribution on those paths.  Since we would like to move in a direction of LAG/ECMP load-balancing based on just the 3-tuple of {src_ip, dst_ip, flow_label}, then we should not take a step backwards from where we are today wrt pseudorandom-ness of individual flows.
3)  Finally, if we expect that the flow-label may (or, hopefully will) get used as a lightweight method of detecting and, possibly, preventing 3rd-party DoS or traffic injection attacks, (i.e.: draft-gont-6man-flowlabel-security), then it depends on generation of pseudo-random values for flow-labels in order that off-path attackers have a reasonably low chance of guessing a valid flow-label.

Thanks,

-shane