Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt

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

On 2012-01-24 17:17, Fernando Gont wrote:
> On 01/24/2012 12:04 AM, Brian E Carpenter wrote:
> 
>>>> Effectively the equivalent algorithm in RFC 6437 is
>>>>
>>>>  Flow Label = F(Srce Addr, Dest Addr, Protocol #, Srce Port, Dest Port, Secret Key)
>>>>
>>>> which is less predictable, even if the port number is not randomized.
>>> If the attacker can predict the algorithm in
>>> draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses
>>> of the two endpoints, and the secret key. So I don't see what'd be the
>>> real improvement of this variant.
>> With your proposal, after observing label N, you can (with reasonable probability)
>> predict label N+1; you don't need this to be 100% accurate to cause trouble.
> 
> If the attacker can *observe* labels, why would he bother to "guess" them?

So that s/he can generate plausible bogons as part of a DOS attack. It seems
to me that predictability of the flow label is similar to predictability
of port numbers in that respect.

>>> Yes, now that the requirement of uniqueness has been relaxed, collisions
>>> are less important... but I don't see what's the "gain" of the modified
>>> expression you suggest above.
>> That label 4502 will essentially never be followed by label 4503,
>> which your method explictly allows (your Table 1). Include the counter in
>> the input to the hash function and this problem disappears.
> 
> Well, one should clearly state the threat model:
> If you're thinking about off-path attackers, then the fact that flow
> labels corresponding to the same set (src IP, dst IP) will be
> incremental is irrelevant (the attacker knows that the Flow-IDs are a
> monotonically-increasing sequence, but does not know where that sequence
> is).

If you are trying to confuse a load balancing algorithm, being able to
predict the next new SYN packet, even only with partial success,
might be a useful thing. Since all major content providers run load
balancers, attacks on load balancing algorithms are an important
concern. If you can bias a load balancer to (almost) always pick
the same server, the content provider will not be happy.

(Note: I am not suggesting that existing load balancers are open
to such an attack, but we don't want the flow label to make things
worse.)

> 
> If the threat model is that we're concerned about on-path attacker,
> then: game over: the attacker will always know the FlowLabel values,
> regardless of the algorithm that we use.

Indeed.

> That said, and as noted above, it is interesting to offer alternatives.
> For example, if you implement the hash-based approach described in my
> I-D, the first flow label is "expensive", but the rest are really cheap:
> e.g., just add the counter to the value of F() that you have recorded in
> the destinations cache. OTOH, randomizing every FlowLabel might be more
> expensive.

That depends on how much extra you pay for holding state in the destinations
cache. A stateless algorithm avoids that.

> I personally think that rather than enforcing a single algorithm, we
> should offer a set of possible algorithms, and discuss the tradeoffs --
> after all, not all implementations need to agree on the same algorithm.

Absolutely; that's why RFC 6437 does not specify an algorithm.

    Brian