On Thu, Jun 9, 2011 at 8:40 PM, grarpamp <span dir="ltr"><<a href="mailto:grarpamp@gmail.com">grarpamp@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Some thoughts from a quasi network operator...<br>
<br>
Perhaps a tracking reason not to do this...<br>
<br>
Normally exit traffic is free to travel the globe across jurisdictions<br>
on its way to its final destination (ie: webserver). Doing this<br>
forces that traffic to sink at the exit jurisdiction... removing<br>
that part of its independence.<br>
<br></blockquote><div><br></div><div>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...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
As to why it could be of help...<br>
<br>
Restricting exit policy to only the networks announced via BGP by<br>
the operator (primarily destinations within their own AS's) could<br>
save some bandwidth (transit) costs. Mostly because you wouldn't<br>
be shuffling bits into your AS and straight back out across the<br>
border (cost point) again to a third party. You'd be saying to Tor<br>
that traffic destined within your AS is essentially free once it<br>
gets to your border.<br></blockquote><div><br></div><div>It will probably also reduce concerns about abuse.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
As to making it happen...<br>
<br>
- For network operators who also run their own nodes<br>
<br>
They already have easy ways of generating their CIDR blocks.<br>
Databases, 'sh ip bgp', etc. They can easily pipe that into a script<br>
to generate an exit policy. It would take all of about 15 minutes<br>
to set it all up. Beyond some project publicity that says, 'Hey,<br>
you could maybe save some costs by doing this...' any competent<br>
operator would not need any tools or services to do this.<br>
<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- For nodes run by third parties<br>
<br>
Sure, if the node operator wants to be friendly to their ISP,<br>
particularly as a means of qualifying the existance of their node.<br>
<br>
You definitely don't to task the user with BGP stuff. So a web<br>
service that spits out an exit list based on the nodes IP would<br>
suffice. If you're worried about network slush, email them once a<br>
quarter with the new list, etc.<br>
<br></blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
For Tor itself doing some programmatic things... There are plenty<br>
of BGP looking glasses out there. But for the purposes of some<br>
script banging away at them (times the number of nodes doing so),<br>
yes, it is definitely considered proper to set up a dedicated feed.<br>
I don't think the project would have any problem running its own<br>
Quagga, OpenBGPD, etc instance. And then if it asked around, finding<br>
a couple of friendly ISP's to peer with (and to even host the query<br>
interface) for this purpose.<br>
<br></blockquote><div><br></div><div>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....</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The controller method obviously makes more sense than messing with<br>
config files and restarts. Option: ExitToMyASTracking<br>
<div class="im"><br></div></blockquote><div><br></div><div>Well, I was thinking:</div><div>ASExitingAllowed asn asn asn asn</div><div><br></div><div>We'd probably want something that also takes port numbers and all the other stuff we have in exit policies.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
> In the future, I imagine that it makes a lot of sense for circuit<br>
</div>> building to be BGP aware.<br>
<br>
Yes. I think I posted something about this a while back. Discrimination<br>
based on AS is one of many ways to help ensure the independence of<br>
nodes in the path.<br>
<br></blockquote><div><br></div><div>Yes but sadly, without some kind of verification, I'm not sure that BGP is really up to the task either.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Consider putting these different types of data/metrics into some<br>
form of DHT or database that runs internal to, alongside, or on top<br>
of Tor...</blockquote><div><br></div><div>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...</div><div><br></div><div>
All the best,</div><div>Jake</div></div>