Hi, Brian, On 01/24/2012 05:18 PM, Brian E Carpenter wrote: >>>>> 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.
Let me rephrase with two questions: a) If an attacker is off-path, how can he "attack" the algorithm proposed in "draft-gont-6man-flowlabel-security-02.txt"? b) If an attacker is on-path how does any algorithm prevent the attacker from *knowing* which FlowLabels he should forge? >> 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. How could you possible predict, being an off-path attacker, the next FlowLabel? > 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. My understanding is that FlowLabels are expected to be used as I-Ds for flows, and have no internal semantics. -- it's not that forging a specific value will make packets always go through the same set of routers. > (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.) How worse would the approach in "draft-gont-6man-flowlabel-security-02.txt" for FlowLabels when e.g. Linux uses the same approach for port numbers? >> 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. The destinations cache is already there. So a few bytes per entry does not seem to be a big deal. -- and if it is, then you'd probably be concerned about having the Destinations Cache in the first place.... >> 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. I'm fine with not describing any algorithms in the base expect. But I do think that something along the lines of RFC 6056 is needed -- everytime something like that was misswing, people got it wrong. Thing about IP ID, TCP port numbers, etc., etc. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
