Steven Blake wrote:
draft-gont-6man-flowlabel-security assumes that you keep track of every
allocated src_addr, dst_addr, FL tuple (the if(three-tuple is unique)
return flowlabel; pseudo-code). If you are going to the trouble of
doing this, there is really no reason not to just use a good
Steven Blake wrote:
draft-gont-6man-flowlabel-security assumes that you keep track of every
allocated src_addr, dst_addr, FL tuple (the if(three-tuple is unique)
return flowlabel; pseudo-code). If you are going to the trouble of
doing this, there is really no reason not to just use a good
Hi Fernando,
Apologies for the delay.
On Sep 8, 2010, at 16:29 MDT, Fernando Gont wrote:
Hi, Shane,
I respectfully disagree that the hash provides the randomness
suitable for a flow-label to be used as an input-key for flow-based
load-balancing. In your draft, you've defined the
Hi, Shane,
Thus, for a given {src_ip, dst_ip} pair, the only thing providing
uniqueness to the output of that hash is the secret key.
I don't know what you mean by uniqueness here. If you mean the
secretkey is what makes it hard for an off-path attacker to predict
the result of the hash
Steve,
On Sep 7, 2010, at 14:17 MDT, Steven Blake wrote:
On Tue, 7 Sep 2010 13:58:21 -0600, Shane Amante sh...@castlepoint.net
wrote:
Hi Fernando,
I have a question on:
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00
Unless I misunderstand something, you're proposing
Hi, Shane,
With that said, I don't think this algorithm is necessarily ideal.
The FL value for any two flows from a src_addr, dst_addr pair may
only vary by a few bits, so if a switch/router uses a poor hash
algorithm for LAG/ECMP, you may not get a good load spread.
Agreed, I share your
Hi Fernando,
On Sep 8, 2010, at 12:18 MDT, Fernando Gont wrote:
Hi, Shane,
With that said, I don't think this algorithm is necessarily ideal.
The FL value for any two flows from a src_addr, dst_addr pair may
only vary by a few bits, so if a switch/router uses a poor hash
algorithm for
Hi, Shane,
I respectfully disagree that the hash provides the randomness
suitable for a flow-label to be used as an input-key for flow-based
load-balancing. In your draft, you've defined the calculation of a
Flow Label value as follows: Flow Label = counter + F(Source Address,
Destination
On Wed, 2010-09-08 at 11:22 -0600, Shane Amante wrote:
Steve,
On Sep 7, 2010, at 14:17 MDT, Steven Blake wrote:
On Tue, 7 Sep 2010 13:58:21 -0600, Shane Amante sh...@castlepoint.net
wrote:
[snip]
With that said, I don't think this algorithm is necessarily ideal. The FL
value for
Hi Fernando,
I have a question on:
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00
Unless I misunderstand something, you're proposing that a flow-label be
constructed using the IPv6 Source Destination values as input-keys to a hash
function as follows:
Flow Label = counter
On Tue, 7 Sep 2010 13:58:21 -0600, Shane Amante sh...@castlepoint.net
wrote:
Hi Fernando,
I have a question on:
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00
Unless I misunderstand something, you're proposing that a flow-label be
constructed using the IPv6 Source
Hi, Shane,
Please find my comments inline
I have a question on:
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00
Unless I misunderstand something, you're proposing that a flow-label
be constructed using the IPv6 Source Destination values as
input-keys to a hash
Hi, Steven,
I don't think your conclusion follows. One thing you want for LAG/ECMP is
for each flow from a given src_addr, dst_addr to have a unique FL value.
Fernando's algorithm achieves this by incrementing counter for each new
flow from that address pair.
With that said, I don't
13 matches
Mail list logo
