Re: Bandwidth throttling (was Re: Padding)

[Matej Pfajfar <badbytes@freehaven.net>]

> For instance: Imagine you're on a network that has no traffic. The
> adversary is passively watching much of the network. Suddenly a request
> arrives at a node, and it broadcasts with horizon one. Then a nearby
> node broadcasts with horizon one. Then a node beyond that broadcasts
> with horizon one.
> 
> So it seems that for a very lightly loaded network, this approach doesn't
> buy you the anonymity you want. And since the amount of padding scales
> linearly with load, this approach becomes less desirable at high loads. At
> some point (and I don't know when), it becomes cheaper to just do traffic
> shaping or link padding.
Yes I agree with your second point - the approach certainly doesn't scale 
but we could specify a cut-off point where the router reverts to 
full-scale link padding (e.g. we could use a counter of broadcasts in a 
certain time interval as a measure or some heuristic like that).

I don't see though (and I may be being thick) how the approach decreases 
your anonymity on a lightly loaded network. A (passive) attacker can 
observe that a connection is being made by some party but it can't tell 
which route the connection takes. 

> 
> > > 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.
> > Yes that's the sort of idea I had with ACK/NACK cells - but there is no 
> > provision for discarding cells. I think we need to be able to drop cells
> > (at each node, in whichever way we like) to protect against DoS. In this 
> > idea, a node can't drop a cell once it has received it because it isn't 
> > being buffered anywhere else. So should we not consider end-to-end (OP -> 
> > COR_last) flow control?
> 
> I don't think dropping cells solves our problem. If you are going to have
> to drop the cell, then you shouldn't be reading it in the first place. If
> we allow dropping cells, then we must buffer it at the previous hop -- so
> we've got a very similar problem there. So to answer your above question,
> I don't think that "we need to be able to drop cells to protect against
> DoS" -- I think my design about protects against DoS. So we want to start
> looking at other parameters like throughput, latency, how easy it is to
> code, etc.
> 
> Invoking the term "end-to-end" is very good for your argument, since
> we computer scientists have been trained to believe that end-to-end is
> always the right approach. :) I'll have to consider this one some more.
Say I control machines A and B. I initiate many connections with the same 
route from A to B. I also make it so that B is *really* slow at reading 
data - in which case the last router will have to buffer the cells it has 
got for a long time. Add up the memory costs of many osuch connections and 
you can take the router offline, effectively. Is this not right?
If it is then the last router will have to drop cells if it wants to 
recover?

> > > 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.
> > OK, I need some more help with this - are you worried about an active 
> > adversary discovering the bandwidth of individual circuits?
> > A way of preventing this (just a quick idea, not thought about this) is to 
> > introduce another 
> > "command" field to the cell. A node will forward all non-padding cells 
> > unless the new field matches some certain value (which we could put in the 
> > onion). It will also replace the field with a new value for the next hop 
> > (also contained in the onion). The OP could then introduce random dummy 
> > traffic which only some nodes would recognize as dummy. 
> 
> Seems reasonable.
I'l give it more thought and write it up in more detail to see where that 
gets us. Being able to hide the true bandwidth of the connection from 
nodes is definitely a very good thing - we should look into it. Paul what 
do you think?

> 
> Could somebody take a stab at describing our threat model please? I
> know I've read a bunch of onion routing papers, but for some reason it's
> never quite sunk in. I guess I can't comprehend why we would assume our
> adversary is really good at some things and really bad at others. :)
> 
Well I always thought that a realistic threat model would be one composed 
of the following :

1. A global passive adversary.
2. A roving adversary (as defined in Towards an analysis of onion routing, 
Paul correct me if the reference is wrong). I.e. the bastard that controls 
a subset of routers at any time and can also compromise additional nodes 
(and lose control of some it has already compromised). Informally I think 
this reflects the capability of an attacker to root several machines very 
quickly but can't hold on to them for very long (sysadmin having a late 
night and figures out something is going on or some other form of IDS 
etc).

> --Roger
> 
> 

-- 
Matej Pfajfar

GPG Public Keys @ http://matejpfajfar.co.uk/keys