Hello,

This seems to me like a really neat idea!

Reading from real time BGP feeds is not a simple task and I think it might be a bit of an overhead for the average Tor user.

On the other hand it could be a good idea to have some nodes run tools to generate exit policies or at least provide BGP routing information in a easy to consume format for the tor clients to use.

I have been doing some experimenting on getting and analysing BGP information and these are the resources that I have found useful:

- http://archive.routeviews.org/ - For getting raw MRT format BGP feeds and also the output of `bgp show ip`

- http://www-01.pch.net/resources/data/routing-tables/archive/2011/ - Routing information from other "probes"

- https://github.com/hellais/PyRT - A quick patch I made to make PyRT work on python > 2.3 (useful for parsing MRT format files), original: https://research.sprintlabs.com/pyrt/

IXPs:

- http://www.pch.net/resources/data/routing-tables/looking-glass/

- https://www.peeringdb.com/private/index.php - Very complete database on peers and ASN information. They also provide a very nice API for interacting with their database.

I have been working on some python code for adding BGP support to blockfinder. It basically just parses the results of the `bgp show ip` command outputs obtainable from route views and stores the routing paths inside a database. It needs to be cleaned up a bit, but if you are interested in using it I can hack on it some more.

Let me know of the progress you make :)

- Arturo `hellais`

Hello from Iceland,

Linus invited me to Reykjavik to talk about Tor at the NORDUnet conference and this idea is the result of a bit of feedback from some network operators here.

Tor needs a way to be friendly to large network operators who wish to enable exiting to anonymous communication for their networks. These network operators are happy to allow anyone to pass traffic to their relays as entry nodes, middle nodes and even limited exit nodes.

Linus and I have been discussing methods of automating this process and of course BGP integration makes a lot of sense. Generally, a network operator has a set of AS numbers for their network blocks and as they want people to connect to many of their services, it helps quite a bit to allow exiting to those services from their own Tor relays.

We came up with two main ideas for making this happen.

One method would be to write a program where given an AS number and a BGP feed, we parse all of the advertised network blocks and emit exit policy lines that accepts all traffic for the AS. This would allow for a web service similar to BulkExitList.py for network aware exit policy generation and relay operators would simply need to add this to their Tor configs manually. For mostly static networks, a cronjob would be fine and Tor doesn't need to know about AS numbers internally.

Another method would be to write a controller that watches for BGP network updates and Tor would add relevant exit policy lines for any configured AS. This would allow any Tor relay to dynamically learn about network changes if it has access to a BGP feed patched into a controller. This could be implemented by adding some configuration options to Tor that let Tor know which AS numbers matter to which router. It may also allow for the router to auto learn it's own likely family network but it lacks any kind of bi-directional confirmation, still it seems useful information to have...

It would be fantastic if someone offered a hidden service NORDUNet BGPMon feed. This would help enable the first method of generating network aware exit policies; this would also help with the development of AS awareness in Tor itself. In the future, I imagine that it makes a lot of sense for circuit building to be BGP aware as mere netblocks will not be very useful in an ipv6 world, they're already mostly irrelevant.

Anyway, food for thought. Linus and I will probably hack on some of these ideas in the near future.

All the best, Jake