Re: I-D Action: draft-baker-ipv6-ospf-dst-flowlabel-routing-03.txt

[Brian E Carpenter <[e-mail]>]

On 03/09/2013 14:49, Fred Baker (fred) wrote:
> I thought we had been over this ground and come up with text you found acceptable? Did I inadvertently change it, or are you just bringing up the topic again?

I looked at the new drafts, and concluded that a little explanation
would be useful - it seems to me that if the point is made explicit,
there is much less likelihood of confusing the implementors. Really
what it says is "RFC6437 is flexible enough to allow this".

Note, I'm quite happy with your proposals.

    Brian

> On Sep 2, 2013, at 5:16 PM, Brian E Carpenter <[e-mail]>
>  wrote:
> 
>> Hi,
>>
>> The IPv6 flow label is defined by RFC 6437. This isn't just an editorial
>> correction - the rules about how to set the flow label are in 6437,
>> not in 2460.
>>
>> I believe that this draft (and draft-baker-ipv6-isis-dst-flowlabel-routing)
>> needs some extra text explaining how it's compatible with the flow label
>> specification. I don't think there's any problem, it just needs a little
>> explanation.
>>
>> We're talking about a 20-bit authorization token, which I assume would
>> be an unpredictable value, such that there is only a one-per-million
>> chance of an off-path attacker guessing it. So a pesudo-random value is
>> needed, and from the RFC 6437 point of view that is just fine.
>>
>> That means we can say something like the following:
>>
>> According to [RFC6437], a flow is "a sequence of packets sent from a
>> particular source to a particular unicast, anycast, or multicast destination
>> that a node desires to label as a flow." It is not necessarily in 1:1
>> correspondence with a single transport connection. Using a given label
>> (in this case an authorization token) for all traffic to a given destination
>> is compatible with this definition. In fact [RFC6437] allows for, but does
>> not define, uses of the flow label that rely on pre-established flow-specific
>> state, and route authorization is an example of such stateful usage.
>> Assuming the authorization token will have a pseudo-random value, it will
>> also serve well for the load balancing scenarios described in [RFC6437].
>>
>> Also one warning: there are rumours of firewalls that will change or clear
>> flow labels. This would break the authorization token.
>>
>> Regards
>>   Brian
>