Padding

[Andrei Serjantov <aas23@hermes.cam.ac.uk>]

> Roger:
>* Padding between ORs, and correct padding between OPs. Currently
>  the OP seems to send padding at a steady rate, but data cells can
>  come more quickly than that. This doesn't provide much protection
>  at all. I'd like to investigate a synchronous mixing approach, where
>  cells are sent at fixed intervals. We need to investigate the effects
>  of this on DoS resistance -- what do we do when we have too many
>  packets? One approach is to do traffic shaping rather than traffic
>  padding -- we gain a bit more resistance to DoS at the expense of some
>  anonymity. Can we compare this analysis to that of the Cottrell Mix,
>  and learn something new? We'll need to decide on exactly how the
>  traffic shaping algorithm works.

Ok. Here is a proposal:

Constant padding between OP and OR_1 -- 56Kbits back and 28kbit forwards.
That'll remind users what the internet was like in 1998. :-))

OR -> OR links: I propose we leave the n^2 padding for now. Though we have
this idea that each OR may only need to be connected to a few OR's
(statically)  and this would give the same anonymity as being connected to
all of them, but then the OP's need to know which OR's are connected to
which to choose valid routes. Any opinions on this?

Padding: Constant padding to, say, 500Kbit. Per OR -> OR link. Each way.
Furthermore, every OR picks a random percentage (eg. between 75 and 100%)
of the bandwidth which will be used to transport real traffic and the rest
will be padding. This process is repeated every timeperiod, say 10 mins.
This is in order to prevent the attacker from finding out the bandwidth on
a particular link at any particular time.

If instead you always carry all real traffic up to the 500Kbit limit, the
following attack can be used to find out the amount of real traffic on a
link. This is a basis of an trickle ($n-1$!)-like attack.

To find out the bandwidth on a particular link, just establish as many
connections as the system will allow you to (which brings us to a
discussion about what an OR should do if there is too much traffic to go
down on a particualr link (and it ran out of buffer space!)) find out how
much is left.

Ok, I am sorry I cannot think more at the moment, but this is the thinking
we have developed with Matej while he was doing his dissertation.

Thanks,

A.

------------------
Andrei Serjantov
Queens' College
Cambridge CB3 9ET
http://www.cl.cam.ac.uk/~aas23/