Traffic class QoS patch wanted?
mikepery at fscked.org
Tue Feb 15 19:03:22 UTC 2005
Thus spake Geoffrey Goodell (goodell at cassandra.eecs.harvard.edu):
> The argument that "this is a good practical measure for now" is tenuous,
> since there are inevitable side effects that cannot be overlooked. By
> encouraging cheating, the QoS bit will encouarge the use of random or
> misleading port numbers in order to fool the port-number-based sanity
> check. Like other protocols that use port number as a meaningful way of
> differentiating services, this proposal if implmented will encourage the
> overloading of specific port numbers for different kinds of purposes,
> rendering them generally useless. There is a reason why more and more
> services on the Internet listen on port 80...
The reason I proposed this idea is because the current "good practical
measure" for controlling P2P/bulk traffic is to attempt to ban it from
Tor by removing it from the default exit policy.
The problem with the exit policy solution is that individuals will
move their P2P traffic to other ports just so they can use Tor. This
leaves those who can't handle the heat no recourse but to shut down
nodes. Note that most P2P clients are intelligent enough to
/autonegotiate/ accessible ports through firewalls, and thus through
Tor exit policies. If P2P users are able to obtain anonymity over
Tor in the first place, they (and more importantly, their clients) are
less likely to use ports that would cause people opposed to running
P2P traffic to have to do so. This should yield significant benefits
to the health of the network.
> Next, consider this port-number issue in a greater context: one can
> think of port numbers as a form of "transport-layer routing," which is
> to say that when a host receives an IP packet, it determines
> (demultiplexes) to what process to send that packet based upon its port
> number. Remember that Tor is ultimately about decoupling identity from
> routing information; making a gratuitous exception for what is
> ultimately just routing at the transport layer seems inappropriate and
> even dangerous.
So can we try to pin this down? Are there situations where you don't
want the adversary to know you're using one of web/irc/aim versus one
of ssh/telnet/rdesktop? I was under the impression that the routing
information Tor seeks to hide is identity-oriented, not
service-oriented. Perhaps I am mistaken, but I believe most people use
Tor to conceal WHO they are, and WHO they talking to, not necessarily
the types of services they are using to talk to people.
Note that I could implement the priority enforcement such that users
who wish to conceal their service type can opt to mix with one of the
lower priority classes.
Or is there a second order concern? Perhaps your feeling is that
adding these bits may make it easier to follow traffic through the
network. While this may be true (but only to a limited extent,
proportional to class unpopularity), I argue that it provides the
significant benefit of introducing reordering and arbitrary queuing
delays. This should serve to frustrate timing correlation attacks,
again improving the health of the network.
Mad Computer Scientist
fscked.org evil labs
More information about the tor-dev