Re: Bandwidth throttling (was Re: Padding)

[Matej Pfajfar <badbytes@freehaven.net>]

> the network. An adversary has a budget, and short of a systemic
> vulnerability, he must compromise individual network elements or set
> 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.
> For now we can simply think about an adversary owning some percentage
> of the nodes. On to some specifics.
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?

> (1) If Alice and Bob live on pipes hanging off the network that are
> visible to the adversary, then I think they are hosed for ordinary
> applications. And I don't think padding/throttling will do any
> good unless it is onerous on pipenet levels.
> 
> Basically it will be trivial for the adversary to correlate the timing
> of connections opening and closing and the packet volume signature
> over time to confirm their connection(s). Even if these are
> padded/throttled to some reasonable rate an active adversary
> can easily induce a signature on them.
Yep.
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).

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

This way an adversary won't be able to observe that a new connection is 
being made.
 
> Countermeasures we considered some time ago include partial length
> padding similar to some of what has been discussed. Our idea was to
> use inband signalling (from the OP) to indicate to a COR when to
> drop/add a packet. Since the idea of inband signalling created
> religious wars among us, there was a one bit field put in the onion
> header to indicate whether or not the connection was one where inband
> signalling was permitted. Another idea was to announce in the onion
> some adding dropping regimen to each of the CORs in the route. Another
> countermeasure was to have partial routes that are left up and then
> make an OR connection to the head or tail of a route and mate it to
> the existing partial route (or conversely extend the tail of a partial
> route with more CORs). This will complicate the correlation of
> connection opening and closing.
Aaaah OK better than what I wrote above!!

> 
> I don't think these will help much against the threat we are
> considering. I suspect that the noise that this cover activity creates
> can only be either inadequate or too expensive (or both).
Hmm - is it inadequate? Definitely expensive - is it something we are 
prepared to live with considering it gives (I think?) some crucial 
protection?

Matej

-- 
Matej Pfajfar

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