[or-cvs] r10974: Be even more aggressive about separating local traffic from (in tor/trunk: . doc/spec/proposals src/or)

[Roger Dingledine]

For more context, see
https://tor.eff.org/svn/trunk/doc/spec/proposals/111-local-traffic-priority.txt

On Sun, Jul 29, 2007 at 09:25:34PM -0400, Nick Mathewson wrote:
>  [...]
> > +  Option 4: put both classes of circuits over a single connection, and
> > +  keep track of the last time we read or wrote a high-priority cell. If
> > +  it's been less than N seconds, give the whole connection high priority,
> > +  else give the whole connection low priority.
> 
> Hm.  Is it a problem that this approach makes it trivial for an attacker
> to tell when you've been online recently (to about the nearest second),
> and to learn your guard nodes?

Yes, this would be a problem. It would also be a problem with Option 5
(basically Option 4 plus communicating with the other end about how it
should rate limit the connection).

It would seem that we have a choice:

  Option A: let an observer between the relay we run and the next relay
  be able to distinguish local traffic from relayed traffic by seeing
  it in two different TCP connections, but they're separate so relayed
  users can't learn as much; vs

  Option B: put them on the same connection, and now an observer can
  still watch the speed to guess what sort of traffic it is but the
  attack is less straightforward, and there are new "relay through it
  to learn stuff" attacks.

> This seems somehow worse than the partitioning problem with "option
> 2", since this is something anybody can do remotely, rather than
> requiring the attacker to eavesdrop or be one of your guards.

It would seem that if we put all the traffic on a single connection,
then we will always be battling between giving good performance to local
traffic vs hiding whether local traffic is getting good performance now.

Does that mean you're happier about option 2 now? I had elaborated a
bit on it at http://archives.seul.org/or/dev/Mar-2007/msg00056.html

--Roger