[tor-dev] Tor and BGP integration

[Jacob Appelbaum]

On Thu, Jun 9, 2011 at 8:40 PM, grarpamp <grarpamp at gmail.com> wrote:

> Some thoughts from a quasi network operator...
>
> Perhaps a tracking reason not to do this...
>
> Normally exit traffic is free to travel the globe across jurisdictions
> on its way to its final destination (ie: webserver). Doing this
> forces that traffic to sink at the exit jurisdiction... removing
> that part of its independence.
>
>
No, it does not change anything except adding more exiting bandwidth to the
network. People who otherwise would run a middle node are willing to endure
Tor connections *to their own netblocks* from their own Tor nodes. That will
only improve things and it does not aide in tracking and Tor will still use
three hop circuits...


> As to why it could be of help...
>
> Restricting exit policy to only the networks announced via BGP by
> the operator (primarily destinations within their own AS's) could
> save some bandwidth (transit) costs. Mostly because you wouldn't
> be shuffling bits into your AS and straight back out across the
> border (cost point) again to a third party. You'd be saying to Tor
> that traffic destined within your AS is essentially free once it
> gets to your border.
>

It will probably also reduce concerns about abuse.


>
> As to making it happen...
>
> - For network operators who also run their own nodes
>
> They already have easy ways of generating their CIDR blocks.
> Databases, 'sh ip bgp', etc. They can easily pipe that into a script
> to generate an exit policy. It would take all of about 15 minutes
> to set it all up. Beyond some project publicity that says, 'Hey,
> you could maybe save some costs by doing this...' any competent
> operator would not need any tools or services to do this.
>
>
Sure or we can make a supported method of doing this and help the operators
who are competent but wouldn't mind a little integration.


> - For nodes run by third parties
>
> Sure, if the node operator wants to be friendly to their ISP,
> particularly as a means of qualifying the existance of their node.
>
> You definitely don't to task the user with BGP stuff. So a web
> service that spits out an exit list based on the nodes IP would
> suffice. If you're worried about network slush, email them once a
> quarter with the new list, etc.
>
>
If it's like BulkExitList.py, anyone who wants a list of network blocks can
download it. It would probably only be useful for Tor node operators who
don't have a BGP feed. This may also be useful for say, a node operator who
is willing to talk to his own ISP (and knows their ASN).


> For Tor itself doing some programmatic things... There are plenty
> of BGP looking glasses out there. But for the purposes of some
> script banging away at them (times the number of nodes doing so),
> yes, it is definitely considered proper to set up a dedicated feed.
> I don't think the project would have any problem running its own
> Quagga, OpenBGPD, etc instance. And then if it asked around, finding
> a couple of friendly ISP's to peer with (and to even host the query
> interface) for this purpose.
>
>
I think the NORDUnet people are interested in doing this; I suspect they're
the biggest ISP we'll find and one of their hackers works on Tor quite a
bit, he even runs a Directory Authority....


> The controller method obviously makes more sense than messing with
> config files and restarts. Option: ExitToMyASTracking
>
>
Well, I was thinking:
ASExitingAllowed asn asn asn asn

We'd probably want something that also takes port numbers and all the other
stuff we have in exit policies.


> > In the future, I imagine that it makes a lot of sense for circuit
> > building to be BGP aware.
>
> Yes. I think I posted something about this a while back. Discrimination
> based on AS is one of many ways to help ensure the independence of
> nodes in the path.
>
>
Yes but sadly, without some kind of verification, I'm not sure that BGP is
really up to the task either.


> Consider putting these different types of data/metrics into some
> form of DHT or database that runs internal to, alongside, or on top
> of Tor...


We need a proposal for a circuit selection process that is BGP aware. I
guess we'll need it around the time that we want to support IPv6 entirely...

All the best,
Jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110609/3f335cba/attachment.htm>