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