Fernando, On 2012-01-26 23:54, Fernando Gont wrote: > 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?
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] > >> 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. > > 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. Unless you know all the load balancing algorithms in present and future use, I don't see how you can assert that. > > >>> 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. > Again: I don't know, and you don't know, what use future load balancers might make of flow label values. I do know that if the sequence of flow labels is even partly predictable, the behaviour of load balancers *might* become partly predictable. > >> 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. > 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, I hope to have some results for various algorithms and some large IPv6 packet traces quite soon, but I already know that FNV1a gives very good results. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
