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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
