On 01/30/2012 12:55 AM, Brian E Carpenter wrote: >>> and in particular how it interacts >>> with the flow label, then there might be a way to bias the load balancing >>> and orchestrate a DOS SYN attack on a particular server. >> >> Not sure what you mean. Are you arguing that in this case the flow-label >> would be used for *server* load-balancing? > > Yes (draft-carpenter-v6ops-label-balance) but there could be a similar > argument for ECMP or LAG, where "the worst an attacker > could do against ECMP or LAG is attempt to selectively overload a > particular path." [RFC6438]
Again: If using a specific value has any semantics other than just "identifying a flow", *that* is where the vulnerability is being introduced. >>> All I'm saying is >>> that *any* kind of predictability of future flows is a weakness that we >>> should avoid. >> >> I'm generally of the idea that "random is your friend" (wherever possible). >> >> That said, I'm also arguing that when analyzing the security properties >> of something, the threat model should be clearly defined. > > I think it's fairly clear: the attacker reverse-engineers a load balancer > and figures out how to make it send too many flows in the same direction, > thereby saturating a target. Well, that's a security-unwise approach. If you're concerned about that possible attack, use some local secret such that, even if the attacker knows the algorithm and the FL, he cannot really control the load sharing at his own will. >> I just have not seen any example in which an algorithm such as the one >> in "draft-gont-6man-flowlabel-security-02" would allow an attacker to do >> something that he cannot do with randomized (as in rand()) FlowLabels. >> >> And I'm just saying that if the attacker is on-path, what algorithm you >> use is mostly irrelevant. > > Unless you know all the load balancing algorithms in present and future use, > I don't see how you can assert that. It's the intended semantics for the FL and threat model that matters, rather than the algorithm. If the attacker is on-path, he can always learn the FLs in use, and forge packets with that FL such that his packets are sent on the same link as the legitimate packets (e.g. overloading the link) -- and you cannot do anything about that (other than preventing the attacker from snooping the packets, or forging the attack packets). The other possible threat is that of an attacker being able to send his packets on any particular link, at his own will. In that case, you should assume the attacker knows your algorithm, and that he can also pick the FLs he'll use. Therefore, it is the algorithm itself that must prevent the attacker from being able to do that (e.g., employ a secret). As noted, I'm not arguing that randomizing the FL is a bad thing. I'm just arguing that the rationale for claiming that simple randomization is better than other possible approaches is flawed. >> Again: Is there any benefit an attacker would get from knowing what FLs >> might be used in the future? >> >> For instance, if the FLs are not in use, it doesn't seem to make sense >> for an attacker to start firing packets with such labels, as those >> packet would not compete with the "real ones". And if the attacker is >> on-path, then he'll play lazy, and would simply learn the labels from >> the wire. > > Again: I don't know, and you don't know, According to my analysis, there isn't. -- So if you want to declare a "winner" among algorithms (particularly when there *are* tradeoffs) based, then you should be able to answer that question. > what use future load balancers might make of flow label values. We'll we should be providing guidance on how we expect the FL to be used, shouldn't we? > I do know that if the sequence of flow > labels is even partly predictable, the behaviour of load balancers *might* > become partly predictable. That is true only if the load balancer implementation is flawed. >>> in the end. I think it's very cheap >>> to avoid this risk - in your notation, it means >>> >>> Flow Label = counter + F(Source Address, Destination Address, Secret Key) >>> >>> is changed to >>> >>> Flow Label = F(Source Address, Destination Address, Secret Key, counter) >>> >>> That means that the regularity introduced by the counter is hidden by >>> the hash function. >> >> This also means that the algorithm is now broken. The goal of F() is to >> produce a constant value for each set (src IP, dst IP), which cannot be >> easily guessable by an off-path attacker (F() introduces the >> randomization). Then counter is incremented for each new label, such >> that for each set (src IP, dst IP) you get monotonically-increasing flow >> bales, such that the FL reuse frequency is minimized (please see the >> sampl output in the I-D). > > But you greatly increase predictability as a result. I don't understand > how that can possibly be a good thing. I don't understand the basis on which you flag things as "good" or "bad". If you can come up with a scenario in which *on-path* predictability makes possible attacks that simple randomization doesn't, then I would buy your argument. But so far it looks more like religion than anything else. >> If you introduce "counter" within F(), it's like changing the secret key >> for every flow label, at which point the result of F() is probably not >> better than than of "rand()". > > That depends entirely on the quality of F(); as I've already said, Not sure what you mean. If F() has the properties described in draft-gont-6man-flowlabel-security-02, the adding the counter as you described breaks the algorithm. Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
