Bandwidth throttling (was Re: Padding)

[Paul Syverson]

> Date: Wed, 10 Jul 2002 04:51:32 -0400
> From: Roger Dingledine <arma at mit.edu>
> 
> On Wed, Jul 10, 2002 at 03:41:50AM -0400, Matej Pfajfar wrote:
> > > up his own. Roger noted that a good way to think about his budget
> > > might be in terms of the reputation.  That's food for later thought.
> > This is where I scream for help ;-). OK if the adversary sets up his 
> > (read as his/her) own nodes then yes, we can think of it as a matter of 
> > reputation. How does reputation come in to it if you have a guy rooting a 
> > few routers?
> 
> We make the simplifying assumption that higher-reputation nodes are in
> some sense more valuable, and thus better-defended. Not true in all cases,
> but maybe more true than not.
> 
> Speaking of which, something that's been bugging me:
> We treat each node as equal in terms of cost of compromise (which is
> reasonable, because it's much more complex to treat them as not equal),
> but one of the guidelines we keep repeating is "users should choose an
> OR they trust for their first hop". Is there some way to reconcile these
> two assumptions?
> 

I think what's coming out here is the tension between reliability and
trustability, both on this last question and in Mat's and Roger's
answer to it. I don't know that I buy the idea that a
higher-reputation node is better-defended. If I am an adversary, and
some site has good engineering for performance, etc. but bad security
(that never happens), I would be quite happy. I might even try to
help the performance of that site any way I could. This would be
lower cost then setting up my own high reputation node. I don't think
we have come up with a good way to represent this area yet.

> > How bad would it be (anonymity-wise) if we made the OP set up a 
> > "permanent" (ish) connection to a random COR when the network interface 
> > comes up (be it eth, ppp whatever). And then multiplex all connections on 
> > that link, with dummy traffic when there is no real one (effectively 
> > making OP even more similar to a COR, some sort of a local-COR setup).
> 
> Currently the code is designed so we can do this. The OP and OR basically
> are the same program, and can have the same traffic shaping, etc, rules.
> All circuits are multiplexed over a single connection, and if we ever get
> around to doing it, the new_route() function should:
>   * If we're not an OR, then always use the same first OR
>   * If we are an OR, then pick randomly but don't start with ourselves
>     (it would simply waste a hop to start with ourselves)
> (Feel free to patch the code. It should be an easy patch.)
> 
> > The OP could also hop between different onion routers - say that it swaps 
> > to a different COR every hour (still maintaining the connection to the 
> > previous one until all connections going through it have been destroyed).
> 
> If our adversary is a fixed (non-roaming) partial adversary, then either
> he owns the OR you chose or he doesn't. If he doesn't, then you should
> stick with it forever. If you keep hopping around, then at least some
> of the time you'll probably be using an adversary-owned OR. Users should
> choose behavior based on their anonymity goal:
> * If they're worried about profiling, they should jump around a lot.
> * If they're worried about linkability, they should stick with one OR.
> 
> (On the other hand, maybe the roaming adversary becomes more plausible if
> we're talking about a long enough timeframe for the adversary to switch
> which nodes he owns.)
> 
I think that is probably true.

These all sound like good schemes (modulo an analysis of them, as
always) and unlike padding, do not require big additions to how things
work or big overhead. 

I should note that my comments in the last message and yesterday
were addressed primarily at end-to-end or end-to-middle or middle-to-end, etc.
padding. Link padding is another matter. Maybe the points I made apply
to it as well, but I had not been thinking about link padding when I
made them.

-Paul