Re: Low-Cost Traffic Analysis of Tor [QoS Solution?]

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Steven J. Murdoch (tortalk+Steven.Murdoch@xxxxxxxxxxxx):

> One of the advantages of Tor is that it is sufficiently open and
> widely deployed enough to run "real-world" anonymity experiments. Last
> year, myself and George Danezis performed traffic analysis on Tor to
> test the attack potential of weaker adversaries. This paper has now
> been accepted for a conference, the 2005 IEEE Symposium on Security
> and Privacy (Oakland). It isn't a full and general attack on Tor as
> the basic attack only gives path information, not the address of the
> originator, but we think it does provide some interesting results.

So I've got another question actually. A few weeks ago, I proposed a
possible QoS solution to the bittorrent/general network load issue to
this list and then to or-dev
(http://archives.seul.org/or/dev/Feb-2005/msg00008.html).

Basically, the idea was to seperate traffic into 4 classes based upon
exit port, and then use some form of Weighted Fair Queuing algorithm
to balance between them
(http://archives.seul.org/or/dev/Feb-2005/msg00008.html).

The classes were:

  0 -- Unbuffered interactive traffic (ssh, telnet, rdesktop, tcp dns)
  1 -- Application buffered interactive traffic (web, irc, aim)
  2 -- Data transfer (ftp)
  3 -- Bulk Traffic (bit torrent and the rest)

My current idea is to do the WFQ with something like serving class 0
four times, class 1 three times, class 2 twice, and class 3 once
(staggered in a round-robin fashion). If a class queue is empty, it
loses its turn.  I also intend to bump class 0 traffic with full 500
byte payloads up to class 1 or 2, to limit abuse.

This scheme was met with resistence for fear of cheating and
unfairness, but I think it might help to mitigate your attack. 

As I see it, it basically creates 4 scenario clases for your attack
based on the relative priorities of the probe and the corrupted
service traffic:

00. Both probe and server traffic have high precedence (class 0). In
this case, it would seem that there should be little to no effect on
the attack. This may just have to be the price you pay for using class
0. However, on the flip side, it may be that having the server
response traffic at high precedence may exacerbate false positives due
to amplified echo effect. Also note that the corrupted server would
have to ensure its burst traffic will not fill a 500 byte tor payload,
which may be difficult.

01. Probe traffic has higher precedence, server has lower precedence. In
this case, probe traffic should be only minimally delayed by the burst of
server response. This should impede the attack.

10. Probe traffic has lower precedence, server has higher. In this case,
the probe traffic would be delayed by just about any traffic. The
unknown is if it would experience a detectable increase in delay during
the burst from the server. Thoughts?

11. Both probe and server have lower precedence. In this case, the probe
response would again experience arbitrary delays due to other higher
priority traffic, and it is not clear that the low priority server
traffic would be able to generate enough load to be detected.


Does this make sense? Might some form of QoS mitigate this attack?
What do the tor maintainers think?

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs