Thomas, All,

On Jan 10, 2011, at 15:31 MST, Thomas Narten wrote:
> Brian E Carpenter <brian.e.carpen...@gmail.com> writes:
>> Given that we expect people to put flow labels into a
>> hash function of some kind, a 20-bit pseudo random number
>> seems like a better default than 1,2,3,... (depending on
>> the hash function, obviously).
> 
> I want to challenge that up front.
> 
> For the example in your draft, MODULO(n), incrementing by one has
> wonderful properties. Given that incrementing by 1 is about as simple
> as it gets, that seems like a fine thing to do.

Let's take a step back here for a moment and recognize a few things:
1)  Routers, (specifically, 1st-hop routers that would be replacing a zero 
flow-label with something non-zero), already implement a pseudorandom hash 
algorithm today (sometimes in HW), in order that they can determine an outgoing 
component-link for packets sent out/across LAG's and ECMP paths.  So, this 
draft is simply proposing to re-use an existing pseudorandom function already 
built-in to routers and simply encode that result into a flow-label.  
2)  For your proposal, above, of incrementing the flow-label by one to be 
successful, the device encoding the flow-label would have to track state of all 
flows in order to ensure that all packets belonging to the same flow got the 
same flow-label.  While this might be true, and easy, for hosts or stateful 
firewalls, this would absolutely not work for 1st-hop routers that are allowed 
to set a flow-label if they observe an incoming packet whose flow-label wasn't 
set by the host, (IOW, flow-label == 0).

So, I'm seeing a technical problem with your proposal (#2) and huge advantages 
for re-use of pseudorandom algorithms already implemented within devices in the 
network that are potentially responsible for writing a flow-label with as 
little state as possible, (#1).

-shane


> There may be security downsides by having such a predicable generator
> at the source, but that is a different issue than making it hash well.
> 
> Thomas
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to