Re: Bandwidth throttling (was Re: Padding)

[Paul Syverson <syverson@itd.nrl.navy.mil>]

> Date: Wed, 10 Jul 2002 18:22:21 -0400
> From: Roger Dingledine <arma@mit.edu>
> 
> On Wed, Jul 10, 2002 at 04:34:07PM -0400, Paul Syverson wrote:
> >  But, I think we need to do some analysis
> > before we go building any of this stuff into our OR code.  
> 
> Ok. I think you should start us off on this, Paul. :)
> 
Fair enough. Unfortunately as you know, there is a big pile
of prior obligation in the way, but ASAP I would like to get
on that.

> It would be nice to resolve link padding first, because for the most
> part that's what I'd be implementing next. It comes in the form of:
> 
> a) Evenly spaced cells coming out of an onion router
> b) Sending padding cells if you don't have something better to send
> c) 'sendme' cells for congestion control
> d) Token buckets on the receiver to enforce bandwidth throttling 
> 
> I can do (d) independently of the others, and it will do a pretty good
> job by itself of enforcing bandwidth throttling.
> 
> I can do (c) in order to prevent DoS attacks where the adversary makes
> a lot of circuits and has them all funnel into one poor node at some
> point. But if we choose not to do (a), then doing (c) is much less
> critical.
> 
> Doing (b) makes no sense if we don't do (a).
> 
> 
> But adding any sort of scheduler is going to complicate the code, so
> ideally I want to have a sense of what I'm going to use it for before
> I build it. (I don't want to build it with lots of unused features and
> feature hooks, because that's just asking for bugs. But at the same time
> I don't want to have to throw it away to add an unexpected feature.)

I talked to Roger about these points on the phone a little while
ago. I'll try to recall and summarize for everyone else.
(c) and (d) seem worthwhile even absent (a) and (b)
in order to manage congestion or, even if that is not expected
to be a problem, reduce the DoS threat. Since it would be good to tell
DARPA about having made advances on that front soon, this seems
a priority.

I was a little concerned that my own previous arguments were too
strong. Specifically, I was wondering if even link padding made any
sense given those arguments; although my gut said yes.  If not, then
there wouldn't be any current argument for (a) and (b).  The argument
for these is that it is easier to be a passive adversary than an
active one. And, without padding between CORs, it is easy for someone
who just observes passively on the right links to see which OR is the
source of a connection. Against individuals in remote-COR configuration,
this is already a huge reduction in the anonymity set.  Against anyone,
individuals or enclaves, in local-COR configuration, it's the whole
ballgame. We can't say anything specifically quantitative without
knowing the likelyhood of an adversary to be on a given link, e.g.,
how much of the network is he watching, but we can still say that
clearly there is a win here against an adversary at least proportional
to the number of links he is passively watching.

There remains the question of how much padding to do. As we have said
for years, constant is too expensive for any but a small
network. Shaping seems the answer, but where the tradeoffs lie will
have to wait for further analysis. We had contemplated using a
sliding average of previous activity, but this will need further
analysis.

> >  but I think we
> > need some analysis first in this area.
> 
> Feel free. :)
> 
Answered above.

-Paul