On Jan 21, 2011, at 4:29 PM, Brian E Carpenter wrote:
> On 2011-01-22 12:07, Fred Baker wrote:
>> On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote:
>>
>>> We seem to have agreed that the primary purpose of the flow label is
>>> to facilitate load balancing, which is a statistical process.
On 2011-01-22 12:07, Fred Baker wrote:
> On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote:
>
>> We seem to have agreed that the primary purpose of the flow label is
>> to facilitate load balancing, which is a statistical process.
>
> except when it is not a statistical process.
Yes, I sho
On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote:
> We seem to have agreed that the primary purpose of the flow label is
> to facilitate load balancing, which is a statistical process.
except when it is not a statistical process.
---
Fernando Gont writes:
> On 21/01/2011 04:49 p.m., Thomas Narten wrote:
> > But other uses of the Flow Label outside of that do not have that
> > requirement.
> >
> > So, if you do traditional flows, you have to be sure to generate Flow
> > Labels carefully. The default usage outside of signali
On 21/01/2011 04:49 p.m., Thomas Narten wrote:
> But other uses of the Flow Label outside of that do not have that
> requirement.
>
> So, if you do traditional flows, you have to be sure to generate Flow
> Labels carefully. The default usage outside of signaling does not
> have the same requirem
> However, it is NOT required that flow labels are strictly unique - a
> birthday-paradox rate of duplicate flow labels really won't
> matter. I suggest (and this is a new suggestion that's been in my
> mind for a few days) that the uniqueness requirement can and should
> be relaxed to 'unique with
On 2011-01-22 06:24, Fernando Gont wrote:
> Hi, Bob,
>
> On 21/01/2011 02:20 p.m., Bob Hinden wrote:
>
> 1. It is RECOMMENDED that source hosts support the flow label
> by setting the flow label field for all packets of a flow to
> the same pseudo-random value.
I do not see a rea
Hi, Bob,
On 21/01/2011 02:20 p.m., Bob Hinden wrote:
1. It is RECOMMENDED that source hosts support the flow label
by setting the flow label field for all packets of a flow to
the same pseudo-random value.
>>>
>>> I do not see a reason to require this.
>> Probably that could/shoul
Fernando,
On Jan 21, 2011, at 8:55 AM, Fernando Gont wrote:
> Hi, Thomas,
>
> On 10/01/2011 11:10 a.m., Thomas Narten wrote:
>> The crux of the issue is the following:
>>
>>> 1. It is RECOMMENDED that source hosts support the flow label by
>>> setting the flow label field for all packe
Hi, Thomas,
On 10/01/2011 11:10 a.m., Thomas Narten wrote:
> The crux of the issue is the following:
>
>>1. It is RECOMMENDED that source hosts support the flow label by
>>setting the flow label field for all packets of a flow to the
>>same pseudo-random value.
>
> I do not
On 2011-01-18 08:27, Christian Huitema wrote:
> Thomas Narten wrote:
>
>> I'm a bit stuck on this point, because both of the current flow label
>> document
>> continue to say flow labels should be generated SHOULD be pseudo-random,
>> and I'm not convinced this is necessary, required, or buys u
On Mon, 17 Jan 2011 12:55:53 -0700, Shane Amante
wrote:
Thomas,
On Jan 17, 2011, at 10:08 MST, Thomas Narten wrote:
The point being, an attacker doesn't have to guess the actual Flow
Labels that are being in use, but just come up with way to generate
traffic that ECMP maps onto the target
Thomas,
On Jan 17, 2011, at 10:08 MST, Thomas Narten wrote:
[--snip--]
> The second case concerns a number of paths across which traffic is to
> be split. An attacker might want to overload a particular path. One
> way to do this is to guess the Flow Labels being used for ECMP. But it
> seems like
Thomas Narten wrote:
> I'm a bit stuck on this point, because both of the current flow label
> document
> continue to say flow labels should be generated SHOULD be pseudo-random,
> and I'm not convinced this is necessary, required, or buys us anything.
> What compelling argument am I missing?
Christian Huitema writes:
> Have you looked at the security implications? Suppose that an
> attacker can predict the hash algorithm used by a router. This
> attacker could then pick "interesting" values of the flow ID, to get
> the flow of traffic directed to particular paths, or not. For
> examp
Thomas, All,
On Jan 10, 2011, at 15:31 MST, Thomas Narten wrote:
> Brian E Carpenter 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, obvi
On 2011-01-11 11:50, Fred Baker wrote:
> On Jan 10, 2011, at 11:26 AM, Christian Huitema wrote:
>
>> Fred wrote:
>>
>>> Note that I am in favor of suggesting that the Flow Label be included in
>>> the hash when doing load balancing. It is a no brainer. At worst, it is a
>>> no op. But it certain
Hi Thomas,
On 2011-01-11 11:31, Thomas Narten wrote:
> Brian E Carpenter writes:
>
>> I'm not sure there's a problem here. The draft has the
>> pseudo-random label as a SHOULD and Fernando's crypto
>> algorithm as OPTIONAL. The problem with the RFC 3697
>> text is that it apparently encouraged l
On Jan 10, 2011, at 11:26 AM, Christian Huitema wrote:
> Fred wrote:
>
>> Note that I am in favor of suggesting that the Flow Label be included in the
>> hash when doing load balancing. It is a no brainer. At worst, it is a no op.
>> But it certainly is never better to exclude it.
>
> Have yo
Brian E Carpenter writes:
> I'm not sure there's a problem here. The draft has the
> pseudo-random label as a SHOULD and Fernando's crypto
> algorithm as OPTIONAL. The problem with the RFC 3697
> text is that it apparently encouraged lots of people
> to design complex schemes for encoding semanti
I'm not sure there's a problem here. The draft has the
pseudo-random label as a SHOULD and Fernando's crypto
algorithm as OPTIONAL. The problem with the RFC 3697
text is that it apparently encouraged lots of people
to design complex schemes for encoding semantics in the
flow label.
Given that we e
> Have you looked at the security implications? Suppose that an
> attacker can predict the hash algorithm used by a router. This
> attacker could then pick "interesting" values of the flow ID, to
> get the flow of traffic directed to particular paths, or not. For
> example, they could systemati
Fred wrote:
> Note that I am in favor of suggesting that the Flow Label be included in the
> hash when doing load balancing. It is a no brainer. At worst, it is a no op.
> But it certainly is never better to exclude it.
Have you looked at the security implications? Suppose that an attacker can
Brian E Carpenter writes:
> I'm confused. We've been talking for months about recommending
> pseudo-random flow label values as inputs to hash functions,
> precisely to allow scaleable and stateless load balancing and ECMP.
I have a general issue with the above, but I'm not sure whether its a
re
24 matches
Mail list logo
