Re: [tor-dev] Tor and BGP integration

[Arturo <art@xxxxxxxxxx>]

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

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev