This would be handy for a number of reasons:
It would make Tor better able to handle new protocols like VoIP.
It could solve the whole need to socksify applications.
Exit relays would also not need to allocate a lot of file descriptors for all the exit connections.
We're heading in this direction. Some of the hard problems are:
IP packets reveal OS characteristics.
We would still need to do IP-level packet normalization, to stop things like TCP fingerprinting attacks.
Given the diversity and complexity of TCP stacks, along with device fingerprinting attacks, it looks like our best bet is shipping our own user-space TCP stack.
Application-level streams still need scrubbing.
We will still need user-side applications like Torbutton.
So it won't become just a matter of capturing packets and anonymizing them at the IP layer.
Certain protocols will still leak information.
For example, we must rewrite DNS requests so they are delivered to an unlinkable DNS server rather than the DNS server at a user's ISP; thus, we must understand the protocols we are transporting.
DTLS (datagram TLS) basically has no users, and IPsec sure is big.
Once we've picked a transport mechanism, we need to design a new end-to-end Tor protocol for avoiding tagging attacks and other potential anonymity and integrity issues now that we allow drops, resends, et cetera.
Exit policies for arbitrary IP packets mean building a secure Intrusion Detection System (IDS).
Our node operators tell us that exit policies are one of the main reasons they're willing to run Tor.
Adding an IDS to handle exit policies would increase the security complexity of Tor, and would likely not work anyway, as evidenced by the entire field of IDS and counter-IDS papers.
Many potential abuse issues are resolved by the fact that Tor only transports valid TCP streams (as opposed to arbitrary IP including malformed packets and IP floods.)
Exit policies become even more important as we become able to transport IP packets.
We also need to compactly describe exit policies in the Tor directory, so clients can predict which nodes will allow their packets to exit.
Clients also need to predict all the packets they will want to send in a session before picking their exit node!
The Tor-internal name spaces would need to be redesigned.
We support onion service ".onion" addresses by intercepting the addresses when they are passed to the Tor client.
Doing so at the IP level will require a more complex interface between Tor and the local DNS resolver.
No, you cannot trust the network to pick the path.
Malicious relays could route you through their colluding friends.
This would give an adversary the ability to watch all of your traffic end to end.
Requiring every Tor user to be a relay would help with scaling the network to handle all our users, and running a Tor relay may help your anonymity.
However, many Tor users cannot be good relays — for example, some Tor clients operate from behind restrictive firewalls, connect via modem, or otherwise aren't in a position where they can relay traffic.
Providing service to these clients is a critical part of providing effective anonymity for everyone, since many Tor users are subject to these or similar constraints and including these clients increases the size of the anonymity set.
That said, we do want to encourage Tor users to run relays, so what we really want to do is simplify the process of setting up and maintaining a relay.
We've made a lot of progress with easy configuration in the past few years: Tor is good at automatically detecting whether it's reachable and how much bandwidth it can offer.
There are four steps we need to address before we can do this though:
First, we still need to get better at automatically estimating the right amount of bandwidth to allow.
It might be that switching to UDP transport is the simplest answer here — which alas is not a very simple answer at all.
Second, we need to work on scalability, both of the network (how to stop requiring that all Tor relays be able to connect to all Tor relays) and of the directory (how to stop requiring that all Tor users know about all Tor relays).
Changes like this can have large impact on potential and actual anonymity.
See Section 5 of the Challenges paper for details.
Again, UDP transport would help here.
Third, we need to better understand the risks from letting the attacker send traffic through your relay while you're also initiating your own anonymized traffic.
Three different research papers describe ways to identify the relays in a circuit by running traffic through candidate relays and looking for dips in the traffic while the circuit is active.
These clogging attacks are not that scary in the Tor context so long as relays are never clients too.
But if we're trying to encourage more clients to turn on relay functionality too (whether as bridge relays or as normal relays), then we need to understand this threat better and learn how to mitigate it.
Fourth, we might need some sort of incentive scheme to encourage people to relay traffic for others, and/or to become exit nodes.
Here are our current thoughts on Tor incentives.
Please help on all of these!
It would be nice to let relay operators say things like reject www.slashdot.org in their exit policies, rather than requiring them to learn all the IP address space that could be covered by the site (and then also blocking other sites at those IP addresses).
There are two problems, though.
First, users could still get around these blocks.
For example, they could request the IP address rather than the hostname when they exit from the Tor network.
This means operators would still need to learn all the IP addresses for the destinations in question.
The second problem is that it would allow remote attackers to censor arbitrary sites.
For example, if a Tor operator blocks www1.slashdot.org, and then some attacker poisons the Tor relay's DNS or otherwise changes that hostname to resolve to the IP address for a major news site, then suddenly that Tor relay is blocking the news site.
