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

["Fred Baker (fred)" <[e-mail]>]

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?

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