Pseudorandom Flow Labels

Shane Amante <> Tue, 05 April 2011 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D50353A6407 for <>; Tue, 5 Apr 2011 12:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tCnKoMXnCsyE for <>; Tue, 5 Apr 2011 12:20:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 28FE53A63CA for <>; Tue, 5 Apr 2011 12:20:34 -0700 (PDT)
Received: by (Postfix, from userid 0) id 39FB2268676; Tue, 5 Apr 2011 13:22:17 -0600 (MDT)
Received: from ( []) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by with SMTP; Tue, 05 Apr 2011 13:22:17 -0600 (MDT) (envelope-from
X-Avenger: version=0.7.8;; client-ip=; client-port=59821; data-bytes=0
From: Shane Amante <>
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: <>
To: Thomas Narten <>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: 6man List <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Apr 2011 19:20:36 -0000


With respect to your comments on, both at the mic at the 6MAN WG and on the list:

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.