On 2012-01-26 03:07, Fernando Gont wrote: > On 01/25/2012 10:43 AM, Brian Haberman wrote: > >>> That said, if the attacker is able to observe traffic, then game over. >>> Whether we use random FlowLabels or predictable FlowLabels is the same: >>> the attacker is not going to waste his time "guessing" when he can learn >>> the labels by listening to traffic. >> I think you and Brian C. are not talking about the same issue. Brian C. >> is talking about being able to see current flow labels and then being >> able to guess future flow labels. That is, the attacker has the ability >> to forge traffic for a future exchange. You seem to be focused on the >> observation of a current flow and the attacker being able to inject >> traffic into that flow. > > 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, 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. All I'm saying is that *any* kind of predictability of future flows is a weakness that we should avoid. > > >>> 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. > > > >>> That aside, as noted above, the attacker could only predict flowlabels >>> if he is on-path. And if the attacker is on-path, game over. >> I don't think that is completely true. If the attacker cannot guess the >> future flow label correctly, its attempts may be detected. > > 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, 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. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
