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
Jacob Appelbaum <jacob@appelbaum.net> wrote Thu, 9 Jun 2011 14:59:55 +0000: | Hello from Iceland, Hello from a strikestrucken Keflavíkurflugvöllur, | We came up with two main ideas for making this happen. Thanks for the writeup. | 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... This is what I'd prefer. | It would be fantastic if someone offered a hidden service NORDUNet BGPMon | feed. This would help enable the first method of generating network aware Yes. | 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. The BGPmon we were discussing is the one at colostate.edu[0], not the other one. | Anyway, food for thought. Linus and I will probably hack on some of these | ideas in the near future. I'm already running something[1] that is collecting a feed and storing it in an SQL database. I should tech it i) how to emit torrc Export lines and ii) the Tor control protocol ("exit-policy/default"). [0] http://bgpmon.netsec.colostate.edu [1] http://git.nordu.net/?p=bgp-logger.git
On 2011-Jun-09 20:07, Linus Nordberg wrote: [..]
I'm already running something[1] that is collecting a feed and storing it in an SQL database. I should tech it i) how to emit torrc Export lines and ii) the Tor control protocol ("exit-policy/default").
If you want an IPv6 dump (aka grh.sixxs.net) don't hesitate to yell what information you would love to see out of it and in what format. (Better design this all with IPv6 in mind eh ;) Greets, Jeroen (Who will be finally doing his own BGP daemon in the next month so that GRH can actually scale again and will also become IPv4 aware and will retain 'best path' per peer instead of for all).
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. 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. 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. - 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. 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. The controller method obviously makes more sense than messing with config files and restarts. Option: ExitToMyASTracking
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. 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...
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
On 2011-Jun-09 23:34, Jacob Appelbaum wrote:
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....
We could create a hidden service that provides this feature then people who query stay anonymous too. I don't see any harm or difficulty in setting that up for a GRH interface if one would want that. If one can define the values that need to come out, then that can be setup quickly. Greets, Jeroen
On Thu, 9 Jun 2011 21:34:17 +0000 Jacob Appelbaum <jacob@appelbaum.net> wrote:
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...
No. Three hops are enough for normal Tor circuits because in a three-hop circuit, although the second hop knows some information about the client (one of its guard nodes) and the third hop knows the destination, no single hop has useful information about both. When a client's choice of exit node leaks useful information about its intended destination, as it does when using an ‘exit enclave’ and would when using an exit node that exits to a small number of destinations. Robert Ransom
On Thu, Jun 9, 2011 at 10:23 PM, Robert Ransom <rransom.8774@gmail.com>wrote:
On Thu, 9 Jun 2011 21:34:17 +0000 Jacob Appelbaum <jacob@appelbaum.net> wrote:
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...
No.
Three hops are enough for normal Tor circuits because in a three-hop circuit, although the second hop knows some information about the client (one of its guard nodes) and the third hop knows the destination, no single hop has useful information about both. When a client's choice of exit node leaks useful information about its intended destination, as it does when using an ‘exit enclave’ and would when using an exit node that exits to a small number of destinations.
Sure but this in no way changes the picture. It's not like exit enclaving at all, except that it encourages nodes that would otherwise reject *:* to accept some exiting traffic. There would be no change to the way that the Tor client builds the circuit; this is just a way to encourage network operators (who want to play nice) to run more than a middle node without a lot of overhead. Or do I misunderstand? All the best, Jake
this is just a way to encourage network operators (who want to play nice) to run more than a middle node without a lot of overhead. Or do I misunderstand?
You're fine. I was only speaking of the internet path between the exit and regular internet services. Such as what happens if a Tier-1/2 props up some fast nodes and might be able to vacuum up Tor traffic destined to itself. How that would affect the current presumption of reasonably randomized exit sources of traffic to that AS. Mostly from an abuse jurisdiction standpoint as it's harder to complain about (or apply policy to) roving exits halfway around the globe than it is one on your front door. Yet since anyone can prop up such a server today, it's moot I guess. That leaves just the Tor traffic skewing to consider. Also similarly mooted. (My understanding of an adversary being able to effectively force traffic to a destination through their exit... is weak. But if so, that's the skewing part of this.) Would this also mean that ISP's (or users) who deploy such a node would be more likely to block all other nodes such that all they need to manage/filter/etc, good or bad, is their own 'peering' node? Whether such nodes reside in/out of their AS, or use 0.0.0.0/0 exit or AS only exit. Is all.
On Thu, Jun 9, 2011 at 2:34 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
... 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...
why stop at BGP? at that point, might as well pay for a telegeography subscription and map AS->RoW for physically aware route building along sufficiently diverse fiber paths... (in other words, BGP aware route building is sufficiently complicated as to make the next jump past logical domains of administration worthwhile.)
participants (6)
-
coderman -
grarpamp -
Jacob Appelbaum -
Jeroen Massar -
Linus Nordberg -
Robert Ransom