On 2012-01-25 10:02, Fernando Gont wrote: > Hi, Brian, > > On 01/24/2012 05:18 PM, Brian E Carpenter wrote: >>>>>> which is less predictable, even if the port number is not randomized. >>>>> If the attacker can predict the algorithm in >>>>> draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses >>>>> of the two endpoints, and the secret key. So I don't see what'd be the >>>>> real improvement of this variant. >>>> With your proposal, after observing label N, you can (with reasonable >>>> probability) >>>> predict label N+1; you don't need this to be 100% accurate to cause >>>> trouble. >>> 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... > > 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. > >>> Well, one should clearly state the threat model: >>> If you're thinking about off-path attackers, then the fact that flow >>> labels corresponding to the same set (src IP, dst IP) will be >>> incremental is irrelevant (the attacker knows that the Flow-IDs are a >>> monotonically-increasing sequence, but does not know where that sequence >>> is). >> If you are trying to confuse a load balancing algorithm, being able to >> predict the next new SYN packet, even only with partial success, >> might be a useful thing. > > How could you possible predict, being an off-path attacker, the next > FlowLabel? Yes, you must be able to passively observe the previous traffic. > > >> Since all major content providers run load >> balancers, attacks on load balancing algorithms are an important >> concern. If you can bias a load balancer to (almost) always pick >> the same server, the content provider will not be happy. > > My understanding is that FlowLabels are expected to be used as I-Ds for > flows, and have no internal semantics. -- it's not that forging a > specific value will make packets always go through the same set of routers. If the label is used in a load balancer, it *might* do exactly that. It isn't certain (see draft-carpenter-v6ops-label-balance-01.txt). >> (Note: I am not suggesting that existing load balancers are open >> to such an attack, but we don't want the flow label to make things >> worse.) > > 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. >>> 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. >>> I personally think that rather than enforcing a single algorithm, we >>> should offer a set of possible algorithms, and discuss the tradeoffs -- >>> after all, not all implementations need to agree on the same algorithm. >> Absolutely; that's why RFC 6437 does not specify an algorithm. > > 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. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
