Internet exit strategies
Warning: This page is not completely finished yet.
Warning: Some of these ideas might already been described or or even implemented somewhere else. If you know about such sites, please send me an email.
One of the most important applications for cor will probably be to connect to the internet. Doing this well might not be as easy as it sounds. Two hard problems are getting enough users to run internet exits and make these exits safe to use.
Getting users to run internet exits
Anonymisation networks have the problem that somebody has to own an IP address which is visible to outside people. Being this person can be quite uncomfortable, because in some places anonymisation is seen as a threat. However a lack of exit nodes translates to bad performance. Cor faces 2 additional challanges to other anonymisation networks. First, the per user bandwidth requirement for providing nearly full internet access very high. Second, the internet exits need to be close to users, not on the other side of the world. Internet exits which are far away have higher latency and put more load on the cor network and routing daemon. Some ways of reducing the risks might be:
- A simple solution for some cases might be exit nodes which only provide access to authenticated users. This way everybody can limit access to a few trustworthy people or maybe even only himself. However, operating a network like this is rather limiting.
- Another way could be to forward the data through other proxies. See "Verification of internet exits" below for how this can be done in a way which does not allow the cor->proxy forwarder to do a man in the middle attack. This will probably help in some cases, but this approach might not be able to provide lots of bandwidth.
- Some protocol might be safer than others and could be allowed internet connection by firewall rules and/or application gateways. This could be used to allow people to connect to fast proxies which require user authentication.
- Applications which use much upload bandwidth can use something like the Smart IP Tunnel for mostly upload traffic described below.
Making internet exits safe to use
Users who want to use an internet exit put its the owner in the position of being able to intercept and/or man-in-the-middle his connection. Protecting with SSL/TLS is a good start, but might not always be easily possible and effective. In this case it should be possible to route data differently whether it is more important be stay anonymous or being able to communicate unintercepted. In the latter case traffic should be routed to the internet connection of the owner. Other ways to improve safety are to distribute trust (see "Smart IP Tunnel for mostly upload traffic") and to do some basic checks on internet exits (see "Verification of internet exits")
Extending the socks protocol
The socks protocol is good for some simple uses, but is quite limited for others. Socks has limited support for incoming TCP connections. Limited means it is only meant for protocols like FTP which requires a way for a server to connect back to the client. The protocol provides the neccesary fields to support opening ports like it should and maybe some servers support this the "unlimited" way, only the spec seems to restrict this. Version 4 requires a timeout for incoming connections in a way which is painful when "abusing" socks for operating servers. The rfc about Version 5 does not mention this timeout. However in order to run dynamic dns internet services this way, you may need application gateways and some ports like 80, because you might have a hard time finding internet exits which do not already have this ports open. Socks 5 also provides a way to send and receive UDP. So far I never seen the opening of remote ports and UDP in operation and I am curious whether somebody has this running.
Smart IP Tunnel for mostly upload traffic
In many cases, where (extended) socks proxy are too risky to operate, sending only internet exits may provide a way to safely share bandwidth. The idea is that these sending only internet exits do not write their own source ip in the packet. Instead, the source IP points to a "receive only" internet exit. The more risky receive side forwards the packet to the real end host. However neither the sending nor the receiving internet exit may be behind a firewall. This exit stragegy has some interesting properties:
- Operating a sending only exit will be pretty safe. It is easy to imagine that there will be many people who will run these hosts.
- The receiving exit will only have to carry the receive traffic. If the traffic is mostly upload, the bandwidth requirement will be very low compared to the upload bandwidth requirement. Moreover many lines are asymetric and have more download than upload bandwidth. So single receiving exit could be able to saturate a lot of sending only exits, depending an how much upload vs. download traffic there is. Even if nobody wants to operate receiving exits locally, operating them as part of e.g. tor exits will still put much less load on the tor network than socks exits.
- In case somebody already has an internet connection with an IP, he could run an authenticating receiving only exit for himself and still use the sending bandwidth of other sending only exits. This can be used to host services "at home", which would otherwise require a server in a datacenter. Being able to do this might help getting the data and services "out of the cloud" and back to the users.
- Routing the receive and send traffic through different paths will probably make some man in the middle attacks harder, because the attacker might need to intercept both the sending and receiving channel.
In order to implement this, the receive only exit will have to allocate ports and tell them to the real end host. The end host will then have send the packets with the correct ports. One way to do this on the end host is to create a virtual interface with the tun/tap device and mangle/forward the packets as needed. However, some parts of the tcp stack will probably have to be tuned. This includes making the congestion avoidance faster on high delay paths. The sending exit will do QoS decide the rates itself anyway and packets will not get lost, but queue up on the sending end host. The only bottleneck the congestion avoidance should worry about is the bandwidth of the receiving host. Maybe the TCP retransmit delays will also have to be tuned, especially in case of doing sending load balancing with varying latency for each path.
Verification of internet exits
Internet exits could be checked whether they have their own connection or are just forwarding the data to another exit. All that needs do be done is something like this: (1) Connect to the exit. (2) It tells you its SSL fingerprint. (3) You send the SSL fingerprint and same random data via weird, usually not forwarded packets (like the data field of an icmp echo). (4) If the fingerprint is correct, it sends the random data back to you. If somebody is doing a man in the middle, the random data will not came back. The real proxy will receive the wrong SSL fingerprint and discard the packet. The fake proxy will not know the random bytes and cannot respond.