Re: Bandwidth throttling (was Re: Padding)

[Matej Pfajfar <badbytes@freehaven.net>]

> True. Basically, in this scenario what we want is for everybody to
> broadcast whenever *anybody* broadcasts. I wonder how we could coordinate
> this. It turns more into a DC-net like structure then.
> 
> An alternative here is to do quite a bit of padding when the network is
> active, and less when it's not, as per the traffic shaping proposal. But
> this is still different, because you're saying the traffic between two
> *unused* nodes should increase when data cells are present anywhere on
> the network. That's a nice idea. I wonder how it could be done.
OK say we pad according to traffic. Then a passive adversary will have 
some idea of which connections go through which routers (he can probably 
presume that the links with comparatively little padding are empty - 
without losing too much precision?).

So let's presume CORs broadcast a padding cell on all adjacent links when 
it transmits a cell on any of its adjacent links (with the exception of 
the padding cells it creates itself of course, otherwise we are counting 
to infinity). 
What problems are there with this? The algorithm to prevent this from 
scaling too much is definitely one. Others?

> Genuine slow connections which are queuing a whole lot of bytes and
> refusing to read them at the server *are* denial of service attacks. If
> nobody's attacking us and we can handle the load, there's no problem. If
> somebody's attacking us, and some legitimate connection is doing a
> better job at DoSing us than the adversary, then I say we kill that
> connection. :)
Hit and sunk. Convinced :-).

> > Yes that's a bitch. But even if you don't ocontrol any onion routers you 
> > can still confirm the relationship between Alice and Bob by observing the 
> > network for a longer period of time and corrleating the times of 
> > connections.
> 
> Yep. Well, I think a broader statement to make is that people using these
> anonymity networks really can't afford to send more than one message
> to a given recipient. Having long-term-linkable "conversations" is not
> a behavior that we can safely support now, either in onion routing or
> in Mixminion.
Unless we can somehow prevent the adversary from detecting the setup of an 
anonymous connection from Alice in the first place.
Or at least make the long-term intersection attack *really* long-term for 
it to have any precision.

> > Again, with heavy traffic on the network you have to do this several times 
> > to confirm the relationship with some certainty. In general, timing 
> > attacks are a killer - do you think they are plausible attacks in 
> > practice?
> 
> It depends who our adversary is. A global passive adversary is a very
> strong adversary, and I think timing attacks will benefit him greatly.
> Perhaps we should back off on our threat model?
I am not sure. I would agree that a global passive adversary that is 
trying to infer relationships between Alices and Bobs is really not much 
of a real threat - although Andrei I think you mentioned at some point 
that this is actually quite possible?

A worse problem is an adversary that is confirming a relationship between 
a particular Alice and Bob as he only has to compromise those two bits of 
the network to mount an intersection attack. I think this should stay in 
our threat model because it's easy enough to do to make it a real threat.

> Stopping the circuit is an attack, yes. But I think these flooding attacks
> (where any node in the circuit can inject an arbitrary number of cells)
> are much scarier anonymity-wise.
Agreed.


> We really need end-to-end dummy traffic, which is sent at regular
> intervals regardless of whether Alice or Bob are online. Check out the
> paper by Heinrich Langos on dummy traffic against long-term intersection
> attacks (hopefully I'll have a link to it soon, from the pet2002.org
> page). Basically, he proposes a dummy database to which you give
> convincing-looking dummies before you go offline, and volunteers pull
> down messages and send them for you while you're gone. It's got a long
> way before it's a reasonable design, unfortunately.
Cool, I'll try and find it.

> 
> I was muttering something to Paul and Andrei at the workshop about a
> p2p design that does the same thing without any centralized db, but I
> think we got sidetracked at some point.
Have you got anything written down? Sounds interesting although is it too 
expensive? 

> > I like this approach. But I don't think it would work for long-range dummy 
> > cells - the first node in the circuit can still just drop the bad-hash 
> > cells. Since they come from the onion proxy which is unlikely to corrupt 
> > its own data stream, it can assume that they are all dummy padding.
> 
> No, the hashes work out correctly (and thus those data cells are
> indistinguishable from real data cells), up to the point in the path
> where the hash is incorrect. That node, if it's honest, drops the cell.
> We can make all hashes from that point onward incorrect, so the first
> honest node drops the cell.
> 
OK me being stupid.

> > With regards to return data - 
> > Dummy cells :
> > I think we can tell each node how to generate dummy cells (embed this in 
> > the onion) - the other nodes won't be able to recognize them and they will 
> > get forwarded all the way to the onion proxy (which will discard them) but 
> > this isn't much of a problem. It will still prevent other nodes (with the 
> > exception of the exit node) from learning the true number of cells being 
> > transmitted. The nly way to beat this is to control all the nodes in a 
> > circuit, which is a killer anyway.
> 
> Ah! So the idea isn't to have the exit node instruct some of its data
> cells to be dropped along the circuit on the way back, but instead to
> have each node in the circuit randomly choose to *add* cells, which the
> onion proxy can recognize as dummies.
Yep - read my email about it. Let me know what you think.

> (Except for that whole hash thing. ;) But as argued in my mail about
> tagging attacks, perhaps hashes are less necessary for the return path.)
OK they are not important when trying to find out which Bob Alice is 
talking to. But what if you suspect a particular Bob - then you can still 
mount a tagging attack can you not? Hmm I guess not because you can't 
recognize your tags...?

Matej

-- 
Matej Pfajfar

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