Thomas, On Jan 17, 2011, at 10:08 MST, Thomas Narten wrote: [--snip--] > The second case concerns a number of paths across which traffic is to > be split. An attacker might want to overload a particular path. One > way to do this is to guess the Flow Labels being used for ECMP. But it > seems like there is an even easier way. If there are N paths, whatever > hash is used will distribute over those N paths. So all an attacker > needs to do is generate src/dest/Flow IDs and probe the network to see > which paths are actually being used. And then generate lots of traffic > to target the particular path they are after. (Rereading the thread I > see now that Fred made this same point.)
This type of attack is likely insignificant in the real-world, at least for links within the Backbone. Let's keep in mind that a victim's traffic (assuming it's well-behaved) will already, automatically be spread across a large number of component-links in a ECMP/LAG group. Thus, if an attacker were either patient enough or had the appropriate HW to generate the right traffic pattern congest a single link in that ECMP/LAG group, then it would only affect a, possibly small, percentage of the overall traffic toward a particular victim -- it depends on how many component-links are in the particular LAG/ECMP group. Instead, it's much more straightforward for an attacker to [easily] acquire several hundred/thousand/etc. bots and congest the small-ish access circuit(s) that are closest to the victim/destination, (i.e.: from PE -> CE) ... or use application-level attacks on the servers, etc. As you get closer to the victim/destination LAG/ECMP is less likely to be used, which is why it's an easier place to attack. > The point being, an attacker doesn't have to guess the actual Flow > Labels that are being in use, but just come up with way to generate > traffic that ECMP maps onto the target path. That suggests that having > Flow Label values themselves be "pseudo random" doesn't buy a whole > lot. > > Or am I missing something? > > I'm a bit stuck on this point, because both of the current flow label > document continue to say flow labels should be generated SHOULD be > psuedo-random, and I'm not convinced this is necessary, required, or > buys us anything. What compelling argument am I missing? Fernando Gont (and, Steve Blake) have been proposing using the flow-label as a security mechanisms for hosts to prevent off-path spoofing attacks. However, to successfully implement/deploy this, you need the pseudo-random flow-labels: Therefore, the Flow Label should be obfuscated so that the chances of an off-path attacker of guessing the Flow Label of future flows are reduced. http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-01 So, why not take the opportunity to use the flow-label to reduce the attack surface of IPv6, (compared to v4)? Does that help? -shane -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
