Re: [tor-dev] Proposal 287: Reduce circuit lifetime without overloading the network.

[Fernando Fernández Mancera <ffernandezmancera@xxxxxxxxx>]

Hi,

> Interesting proposal.
>
> Please see this:
> https://lists.torproject.org/pipermail/tor-dev/2014-September/007517.html
>
> And especially this reply:
> https://lists.torproject.org/pipermail/tor-dev/2014-September/007518.html
>
> It would be very nice if you could glue these into this proposal as well.

It looks interesting so I will try to get it included into the proposal 
in the next update.

> It makes sense, but the hardest thing here is coming with the right
> amount of bytes value so we won't end up building on average more
> circuits than we were with the 10 minutes time dirtiness configuration.

Of course it will be something really hard but my first idea is to use 
an amount of bytes a little low than the average amount in ten minutes.

> I just want to understand something clear so pointing it out, because it
> reads "maximum amount of bytes...": the MaxCircuitSizeDirtiness counter
> will count bytes read/write on a circuit by all streams attached to that
> circuit, and as soon as threshold is reached the circuit will be marked
> as dirty, but the circuit will be closed when all streams are idle,
> correct? Like
>
> If MaxCircuitSizeDirtiness is 10000 bytes (just for example)
> I could download a file of 150000 bytes from a destination host:36455
> over the same circuit, via a single stream, and as soon as that stream
> is idle, count 150000 > 10000 --> mark circuit dirty, stop attaching new
> streams to it? I think you thought of this but want to confirm.

Yes, the moment the circuit exceeds the amount of bytes established it 
will stop attaching new streams to it. But the attached ones will 
continue sending/receiving data until idle.

> Looking forward to see some preliminary statistics. Please think of this
> threat model:
>
> - an attacker discovers the location of an onion service. He hijacks it,
> but does not alter the content or the functionality of the service, in
> order not to signal the discovery to its users and further deanonymize
> as many users as he can.
>
> - he starts serving useless noise on that services so the bytes limit
> threshold is reached fast, forcing users to build circuits more often
> than the time dirtiness method.
>
> - the attacker also controls some hostile relays that could potentially
> be picked in any new created circuit.
>
> Do we increase the success changes for these kind of attackers? make it
> harder for them ? Or does the game remain unchanged?
>
> The time dirtiness cannot be gamed by the attacker because it is based
> just on user's action (or inaction), but the bytes sent over the circuit
> can. That is why it is there in the first place.
>
> If this sounds bad, here are two crazy ideas you could take into
> consideration when doing the numbers:
> 1. Put a hard limit per stream as in how much a single stream can count
> to the MaxCircuitSizeDirtiness threshold in terms of %, if that is
> exceeded the bytes in excess are simply discounted, so it becomes
> impossible for a circuit to be marked dirty "by size" just by being used
> by a single stream.
> 2. Make MaxCircuitSizeDirtiness random, a value between n and m, where m
> cannot be greater than n * q, for *each* circuit.
> 3. Both 1. and 2.?
>
> Either way, thanks for working on this - this area needs some attention
> and I am sure we can do better.

I was thinking in the second option but I need more time to make sure 
this is fine.

I will update the proposal in the next weeks, thank you for your advices.

ffmancera.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev