On Thu, Jun 9, 2011 at 8:40 PM, grarpamp grarpamp@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