On 06/04/2011 03:01 p.m., Fernando Gont wrote:
>> I think we can assume that if we use both the src/dst, we will get a
>> good degree of distribution in the values. Adding the Flow Label gives
>> more. I am just not convinced that to get good distribution we need to
>> *require* (or strongly sugge
Fernando Gont wrote:
> On 06/04/2011 05:44 p.m., John Leslie wrote:
>> Fernando Gont wrote:
>>> * We want Flow Labels that unpredictable by off-path attackers (history
>>> has taught us that this is a good proactive measure)
>>
>> I'm afraid I don't follow: what sort of attack could an off-pat
On 07/04/2011 04:32 a.m., Brian E Carpenter wrote:
> Setting the flow label by calling random() cannot be a stateless
> method - it would mean storing the value for use on future packets
> of the same flow. We need a stateless method.
Oops, you're right. (Although for FLs set by end nodes this sho
Setting the flow label by calling random() cannot be a stateless
method - it would mean storing the value for use on future packets
of the same flow. We need a stateless method.
Brian
On 2011-04-07 10:16, Fernando Gont wrote:
> Hi, Shane,
>
> On 06/04/2011 06:44 p.m., Shane Amante wrote:
>
Hi, Shane,
On 06/04/2011 06:44 p.m., Shane Amante wrote:
>> * We want Flow Labels that unpredictable by off-path attackers
>> (history has taught us that this is a good proactive measure) * We
>> want an algorithm for generating FL that produces FLs that do not
>> repeat with a high frequency (i
Fernando, Thomas,
On Apr 6, 2011, at 12:22 MDT, Fernando Gont wrote:
> Thomas,
>
> On 05/04/2011 05:36 p.m., Thomas Narten wrote:
>> Case in point about how we are being *extremely* loose in using the
>> term "pseudo random".
> []
>> Part of my objection to the term "pseudo random" is that th
John,
On 06/04/2011 05:44 p.m., John Leslie wrote:
> Fernando Gont wrote:
>> * We want Flow Labels that unpredictable by off-path attackers (history
>> has taught us that this is a good proactive measure)
>
>I'm afraid I don't follow: what sort of attack could an off-path
> attacker mount
Fernando Gont wrote:
>
> * We want Flow Labels that unpredictable by off-path attackers (history
> has taught us that this is a good proactive measure)
I'm afraid I don't follow: what sort of attack could an off-path
attacker mount by correctly guessing the Flow Label?
--
John Leslie
Hi, Hermant,
On 05/04/2011 10:15 p.m., Hemant Singh (shemant) wrote:
> Snipped from RFC 4193 is this text. "pseudo-randomly allocated global
> ID". If pseudo-random was accepted in this RFC, why are we discussing
> pseudo-random again?
Because the requirements are different. For RFC 4193, the
Shane,
On 05/04/2011 06:23 p.m., Shane Amante wrote:
> As I pointed out below, we already have pseudorandom distribution of
> flows today, given that most host implementations use RFC 6056 and
> (IPv4) load-balancing routers/switches use the 5-tuple as input-keys
> ... included in those input-keys
Thomas,
On 05/04/2011 05:36 p.m., Thomas Narten wrote:
> Case in point about how we are being *extremely* loose in using the
> term "pseudo random".
[]
> Part of my objection to the term "pseudo random" is that the term has
> not been defined within the context of the Flow Label.
You raise a
On 05/04/2011 04:58 p.m., Thomas Narten wrote:
> At the core, my concern with "pseudo random" is that I (as an
> implementor) do not know what I have to do do satisfy that requirement
> and I think in some cases that cost is higher than justified by the
> benefit. The current documents do not provi
Hi, Shane,
On 05/04/2011 04:22 p.m., Shane Amante wrote:
> 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 creati
> I have a quite strongly held belief that trying to be mathematically
> precise (not to say pedantic) has never worked well in IETF
> protocols.
Agree completely. :-)
> We do seem to agree that the important point is that the final output
> of the hash function used to select between alternate r
ingh (shemant) wrote:
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Thomas Narten
> Sent: Tuesday, April 05, 2011 8:08 PM
> To: james woodyatt
> Cc: 6MAN Working Group
> Subject: Re: Pseudorandom Flow Labels
>
>
>
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Thomas Narten
Sent: Tuesday, April 05, 2011 8:08 PM
To: james woodyatt
Cc: 6MAN Working Group
Subject: Re: Pseudorandom Flow Labels
>What is *required* is that the hash function (or whate
dyatt
Sent: Tuesday, April 05, 2011 6:49 PM
To: Thomas Narten
Cc: 6MAN Working Group
Subject: Re: Pseudorandom Flow Labels
On Apr 5, 2011, at 14:48 , Thomas Narten wrote:
> [I wrote:]
>>
>> I share your concern. Would replacing "pseudo-random" with "low
discrepancy" a
On Apr 5, 2011, at 17:08 , Thomas Narten wrote:
>
> What is *required* is that the hash function (or whatever function
> that is used) on the router maps the tuples in a *uniform* way across
> the range of possible outputs.
Then it seems like "Equidistributed Sequence" is the precise term you wan
Thomas Narten wrote:
>
> What is *required* is that the hash function (or whatever function
> that is used) on the router maps the tuples in a *uniform* way across
> the range of possible outputs.
>
> If you have 10 links, and all your Flow Labels are clustered around
> low ten values, but in an
> Discrepancy is a measure of the deviation of a point set from a
> uniform distribution.
Actually, the core issue is that we do not need the Flow Label to be
uniformly distributed.
In an ideal world, that would be a nice property to have. And all
things equal, better to have that propert than n
On Apr 5, 2011, at 14:48 , Thomas Narten wrote:
> [I wrote:]
>>
>> I share your concern. Would replacing "pseudo-random" with "low
>> discrepancy" address your concerns?
>
> Replacing the term with another would be fine. That said, the real issue is
> we need to define what we mean by whatever
> I share your concern. Would replacing "pseudo-random" with "low
> discrepancy" address your concerns?
Replacing the term with another would be fine. That said, the real
issue is we need to define what we mean by whatever term we use.
Thomas
On Apr 5, 2011, at 13:36 , Thomas Narten wrote:
>
> Case in point about how we are being *extremely* loose in using the term
> "pseudo random".
I share your concern. Would replacing "pseudo-random" with "low discrepancy"
address your concerns?
--
james woodyatt
member of technical staff, co
Thomas,
On Apr 5, 2011, at 13:58 MDT, Thomas Narten wrote:
[--snip--]
> I take it as a given that doing ECMP on the src/dst address gets you
> 80% of what you need today. Adding in the Flow Label (if set) will
> take you much further. I am not convinced you need real "pseudo
> randomness" in the F
Case in point about how we are being *extremely* loose in using the
term "pseudo random".
If you look at draft-gont-6man-flowlabel-security-01, it proposes two
different algorithms for generating Flow Label values.
Unless I'm missing something, neither of them actually provides
"pseudo randomness
At the core, my concern with "pseudo random" is that I (as an
implementor) do not know what I have to do do satisfy that requirement
and I think in some cases that cost is higher than justified by the
benefit. The current documents do not provide enough concrete
guidance, IMO. If we want folk to ac
26 matches
Mail list logo
