[or-cvs] Implemented link padding and receiver token buckets

[Andrei Serjantov]

> But the problem here is that if the network is full, then flushlen keeps
> increasing, and we keep adding padding cells. So first of all, when the
> connection slows down we end up with more and more cells to send out,
> eventually ending up with a datalen == len. Bad news. Secondly, when a
> new data cell arrives, it needs to wait til all that padding is flushed
> before it can go onto the network.

Ok....

> Solution: we don't let flushlen exceed a certain size, say 10ms worth
> of cells or 10 cells, whichever is larger. Thus we'll never have more
> than one flushlen worth of padding cells on the outbuf, ever.
>
> Our padding still successfully hides whether cells are data or padding,
> because we stick to the rule "whenever we can send a cell onto the network
> we do, but not to exceed 'bandwidth'". And our datalen will only grow
> large if we have lots of legitimate data cells queued.

But then surely, if you want to find out the bandwidth of real traffic on
the network, you just attack the network and then watch the traffic in the
next few seconds and it will all be real traffic. I think you have to
implement another one of these random back-off schemes I proposed: as the
network is songested, put in fewer and fewer dummies and then you may
rearrange the order of the dummies and real traffic in a fairly random
fashion as well. Should I work out the details or are we not going to
bother with such things? What I said above is a fairly weak attack, so I
don;t mind either way.

> This latter approach feels better, but I'm going to ignore this timing
> attack issue for now. We can change the code appropriately in the
> future. I'm going to go put the rest of this mail into effect.

I definitely agree with that. "Timing padding" is probably not too hard to
add, but if we are talking about these sorts of attacks, they are
implementation level!

Thanks,

A.

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