Bandwidth throttling (was Re: Padding)

[Andrei Serjantov]

> > 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

Ok. Sure.

> 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.

A.

------------------
Andrei Serjantov
Queens' College
Cambridge CB3 9ET
http://www.cl.cam.ac.uk/~aas23/