On 01/24/2012 11:39 PM, Brian E Carpenter wrote: >>>> If the attacker can *observe* labels, why would he bother to "guess" them? >>> So that s/he can generate plausible bogons as part of a DOS attack. It seems >>> to me that predictability of the flow label is similar to predictability >>> of port numbers in that respect. >> >> Let me rephrase with two questions: >> >> a) If an attacker is off-path, how can he "attack" the algorithm >> proposed in "draft-gont-6man-flowlabel-security-02.txt"? > > OK, I mean an attacker who is able to observe the traffic but not > perform MITM modifications. Some people call that off-path...
Well, the attacker *is* on the path if he can observe traffic. 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. >> b) If an attacker is on-path how does any algorithm prevent the attacker >> from *knowing* which FlowLabels he should forge? > > Obviously for an established flow, you can inject forged packets that > appear to belong to that flow; we can never prevent this. But if you > can predict the flow label for *future* flows, you can forge and > inject SYN packets before the real user ever starts the flow. Since > a large part of today's forged traffic seems to consist of SYN packets, > this seems like a sensitive target. 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. 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. >> How worse would the approach in >> "draft-gont-6man-flowlabel-security-02.txt" for FlowLabels when e.g. >> Linux uses the same approach for port numbers? > > I thought we were trying to randomise port numbers for exactly > that reason; it seems to me that any form of regularity in the > numbers is asking for trouble, even if we don't have an exact > attack model. As noted in the port randomization RFC, the goal is that an off-path attacker can not predict values. In particular, if we start imposing requirements such as "we must minimize the probability of FL reuse", etc., then that's certainly asking against randomness at the same time. In the case of port randomization, the port selection algorithm has two goals: * selecting port numbers such that they are not predictable by an off-path attacker * minimizing the port reuse frequency. As a result, a hash based approach can tackles the two of them. An anecdote: While working on the port randomization stuff, a guy from vendor X argued that he'd not implement the hash-based algorithm because one of his customers was running a small app to measure the "randomization quality" of their port selection algorithm. -- Clearly, they were missing the point (and we noted that at the time): what we wanted was the port numbers to be difficult to guess by *off-path* attackers. If the attacker was on the other endpoint of the connection, he could always see the packets, and could always perform any attack that he wanted. >>>> That said, and as noted above, it is interesting to offer alternatives. >>>> For example, if you implement the hash-based approach described in my >>>> I-D, the first flow label is "expensive", but the rest are really cheap: >>>> e.g., just add the counter to the value of F() that you have recorded in >>>> the destinations cache. OTOH, randomizing every FlowLabel might be more >>>> expensive. >>> That depends on how much extra you pay for holding state in the destinations >>> cache. A stateless algorithm avoids that. >> >> The destinations cache is already there. So a few bytes per entry does >> not seem to be a big deal. -- and if it is, then you'd probably be >> concerned about having the Destinations Cache in the first place.... > > It's an engineering trade-off, certainly. My taste is always to avoid > extra state, however. Four bytes per IP address (*not* per TCP connection or the like) doesn't seem like a big deal. -- You're going to hit many other problems before those four extra bytes become a problem. That said, I'm generally in favour of offering choices, discussing the trade-offs, and let people pick the option that they like most. >> I'm fine with not describing any algorithms in the base expect. But I do >> think that something along the lines of RFC 6056 is needed -- everytime >> something like that was misswing, people got it wrong. Thing about IP >> ID, TCP port numbers, etc., etc. > > Yes, but maybe we need a little experience first. That's why I have a > student playing with the largest IPv6 traces we've managed to get hold > of. Experimental data is always good. However, regardless of what the results of this experiment are, let's just say that with the current levels of v6 deployment, it's hard to tell whether those results will still hold in, say, two years, or whatever. Different systems use different address types, addresses selection algorithms, etc., that are likely to evolve over time (not to mention the traffic patterns). So I'm more of the idea that the aforementioned experiment could help to identify algorithms that suck, but not really prove that this or that algorithm is (or will be) best (assuming that there's such a thing -- which I don't think it's the case... there are just different options, with different trade-offs). Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
