Hi, Brian, On 01/25/2012 05:08 PM, Brian E Carpenter wrote: >> Agreed. The point I'm trying to make is that I do not see what the >> attacker would gain from guessing a label that's not in use yet. For >> instance, if he were to send packets with that forged label, the spoofed >> traffic might not event "compete" with any existing traffic. > > One case that I'm thinking of specifically is if the attacker also knows > the load balancing algorithm in use,
One should expect the attacker to know the load-balancing algorithm, but not the parameters with which it operates. If the attacker knows all of these things (algorithm+parameters), then *that* is where the flaw is (assuming having the attacker play with load-balancing is a concern, of course). > 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? > 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. For yet another example, draft-gont-predictable-fragment-id. My original proposal was to simply randomize the Fragment Identification. But concerns with collisions of Fragment IDs led to alternative approaches (although I personally think that that doesn't mean that simple Fragment ID randomization should be ruled out). >>>> Since FlowLabels do not carry any specific semantics, I cannot see how >>>> "forge and inject before..." would be any worse than firing those >>>> packets once the flow has already been established. >>> Injection of state into the endpoints may influence a large number of >>> functions, so an attacker's ability to forge packets may allow it to >>> skew the behavior of one of the nodes. >> >> Not sure what you mean.... > > Load balancing is an example. I think you'd be courageous to assert > that the bad guys won't find another. 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. >> How? And more importantly, why would an attacker want to forge a future >> label that is not in use? >> >> Let's keep in mind that if the attacker is on-path, that of attacking >> the flow label is probably the last DoS variant an attacker could try >> (no amplification, etc.) > > They will try anything that works, 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. > 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). 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()". 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 --------------------------------------------------------------------
