Bandwidth throttling (was Re: Padding)
aas23 at hermes.cam.ac.uk
Thu Jul 4 11:27:43 UTC 2002
> > Padding: Constant padding to, say, 500Kbit. Per OR -> OR link. Each way.
> Ow. I don't know what Internet you live on, but this is a lot. :) For 50
> nodes, that's 25 Megabits per second each way per node. I think we must
> take a lesson from Freedom here, and look for less expensive approaches.
I was thinking about a small-scale case, say 5 routers which are basically
uncompromised. So I think we are just talking about different things here.
> Bandwidth throttling and flow control are closely tied to traffic shaping.
> There are several issues to solve here. We need to make sure a node:
> 1) doesn't send too many data cells per timeslice
> 2) doesn't send too many bytes per timeslice
> 3) doesn't receive too many bytes per timeslice
> My proposed solution has several components:
> A) To prevent too many data cells from coming in to a node, we introduce
> 'sendme' cells for flow control. Each circuit has a window parameter at
> each hop, which is the number of data cells it's allowed to send. If
> the circuit's window reaches 0, it stops sending data cells. When a
> sendme cell arrives, the window is incremented by a value specified in
> the payload of the sendme.
Fine. But presumably all these cells are not just sent as fast as
possible, are they? (This is the missing bit of your email, I expect)
> (We could have the flow control be connection-wide rather than for
> individual circuits, but then we end up with DoS vulnerabilities a
> la Pipenet.)
I don't understand this comment, please elaborate.
> The adversary can observe some of the nodes, learn which ones are stalled,
> and correlate circuits and thus bridge honest nodes. But simple packet
> counting attacks will already bridge nodes.
What do you mean by stalled nodes?
> Traffic padding may foil passive adversaries, but not adversaries who
> are part of the network. So with this lighter threat model, where we
> don't worry about correlation attacks, we can afford to have the
> granularity of per-circuit flow control.
Sorry, you really have to explain this.
> Now, an aside before we get too much further: is there really anything
> we can do against the active (node-owning) adversary? Perhaps, if we
> introduce dummy traffic that looks legitimate to some nodes in the
> circuit. Paul, can you elaborate on this more? In any case, I'm scared
> to death of DoS, so this is it for now.
So even in the original OR design (+ OP -> OR padding) if the first node
of a connection is compromised (i.e. the attacker knows how much traffic
comes from the user) and the attacker can observe the entire network, the
anonymity of that connection is compromised. I don't think we can do
anything about that. (Mat, interestingly enough, we never thought of this
when suggesting the OP -> OR padding idea). On the threat model question,
I think we should not try to protect against compromised COR's (the
above). This is not as bad as it sounds -- the people who run COR's are
nto the ones who run the network. Although this is definitely a
significant reduction in security.
Maybe you *can* do something about this, though.
Side note: I am actively thinking of dummies (although more for Mixmaster)
and this may provide an anonymity protection scheme applicable for OR
which is not too expensive.
Cambridge CB3 9ET
More information about the tor-dev