Hi Tor list,
I'm already running a small exit node (100Mbps bandwidth) and I'm ready to spend more money on it, so have a question for you guys :
Is it better if I run other small ones (100Mbps too) or only 1 big exit relay (1 Gbps) ? What's best for the network stability/security ?
Thanks a lot
IPonU
Hi,
100Mbps is not a small node. Thanks for running a relay!
When you say you're going to spend more money on it... do you mean hardware or bandwidth?
All of my relays are running as virtual machines on multiple computers to maximize the CPU and memory usage. If you didn't want to virtualize your machines you could put two Tor nodes on the same physical box to maximize hardware usage.
If you're comfortable telling us where you're putting your money I suspect we can advise you better.
John Quintex Alliance Consulting
On Sep 29, 2017, at 02:37, IPonU <contact@iponu.netmailto:contact@iponu.net> wrote:
Hi Tor list,
I'm already running a small exit node (100Mbps bandwidth) and I'm ready to spend more money on it, so have a question for you guys :
Is it better if I run other small ones (100Mbps too) or only 1 big exit relay (1 Gbps) ? What's best for the network stability/security ?
Thanks a lot
IPonU
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.orgmailto:tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I'm not sure what you're asking so I'll show you the website : http://www.digicube.fr/rapidserveurs
ATM I have the cheapest (4€). So i'm not sure if I take others or if I take only one at the top with 1Gbps bandwidth.
I think it could be great to have multiple relays in case one is down but i'm not sure
Le 29/09/2017 à 09:54, John Ricketts a écrit :
Hi,
100Mbps is not a small node. Thanks for running a relay!
When you say you’re going to spend more money on it... do you mean hardware or bandwidth?
All of my relays are running as virtual machines on multiple computers to maximize the CPU and memory usage. If you didn’t want to virtualize your machines you could put two Tor nodes on the same physical box to maximize hardware usage.
If you’re comfortable telling us where you’re putting your money I suspect we can advise you better.
John Quintex Alliance Consulting
On Sep 29, 2017, at 02:37, IPonU <contact@iponu.net mailto:contact@iponu.net> wrote:
Hi Tor list,
I'm already running a small exit node (100Mbps bandwidth) and I'm ready to spend more money on it, so have a question for you guys :
Is it better if I run other small ones (100Mbps too) or only 1 big exit relay (1 Gbps) ? What's best for the network stability/security ?
Thanks a lot
IPonU
tor-relays mailing list tor-relays@lists.torproject.org mailto:tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 29.09.2017 10:18, IPonU wrote:
DigiCube notes "Offre uniquement valable pour la France métropolitaine". Has anybody asked if non-French customers are also welcome? Have they agreed to hosting Tor nodes, especially exits? My French is rusty, and I could not find answers to these questions on their site, and I get only timeouts when trying to connect to the DigiCube forum.
-Ralph
I don't know if they accept foreign people to order (you could ask them by clicking on "Nous contacter http://www.digicube.fr/index/contact") The forum doesn't work in France either.
I already asked them about tor exits and they told me they were OK with it as long it's not spamming and it's not affecting (slowing) their network.
This ISP is already mentionned in the goodbadisp page and i'll update it if they shut down my relay.
Le 29/09/2017 à 13:31, Ralph Seichter a écrit :
On 29.09.2017 10:18, IPonU wrote:
DigiCube notes "Offre uniquement valable pour la France métropolitaine". Has anybody asked if non-French customers are also welcome? Have they agreed to hosting Tor nodes, especially exits? My French is rusty, and I could not find answers to these questions on their site, and I get only timeouts when trying to connect to the DigiCube forum.
-Ralph
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi there,
If your exit node has been online for more than two months with little hassle from the ISP, be sure to update the wiki at https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs with your exit node's ISP information. And thank you for your contribution to the Tor network.
Thank you for your email, Isaac, Tor@SechsNullDrei.org
-----Original Message----- From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of IPonU Sent: Friday, September 29, 2017 2:37 AM To: tor-relays Subject: [tor-relays] About relay size
Hi Tor list,
I'm already running a small exit node (100Mbps bandwidth) and I'm ready to spend more money on it, so have a question for you guys :
Is it better if I run other small ones (100Mbps too) or only 1 big exit relay (1 Gbps) ? What's best for the network stability/security ?
Thanks a lot
IPonU
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Fri, Sep 29, 2017 at 09:37:00AM +0200, IPonU wrote:
I'm already running a small exit node (100Mbps bandwidth) and I'm ready to spend more money on it, so have a question for you guys :
Thanks for running a relay!
Is it better if I run other small ones (100Mbps too) or only 1 big exit relay (1 Gbps) ? What's best for the network stability/security?
My overall analysis is that one 1Gbps relay is a better contribution to the network than two 100 Mbps relays, assuming other variables are held constant. This choice by a single operator isn't a significant impact on security or stability, but in general we want
- more operators - more AS diversity as share of exit bandwidth - more bandwidth - more nodes
in approximately that order of importance. You're already nailing it on the first (thanks again!), I think you're not considering to add another AS (your new node would be on the same ISP), so it's mostly just a choice between 200 mbps and 1gbps, and a choice between one descriptor in the consensus or two descriptors.
Also, if we were very short of nodes, then adding more nodes would be a higher priority; but currently we seem to be more short of skilled and motivated operators, rather than node-limited.
-andy
On 30 Sep 2017, at 09:55, Andy Isaacson adi@hexapodia.org wrote:
Is it better if I run other small ones (100Mbps too) or only 1 big exit relay (1 Gbps) ? What's best for the network stability/security?
My overall analysis is that one 1Gbps relay is a better contribution to the network than two 100 Mbps relays
I agree. Larger, faster relays help clients achieve low-latency, high bandwidth connections.
But depending on your processor speed, you might find that each tor instance can only use about ~300Mbps before it maxes out the CPU. (And it can take a few weeks for a new tor relay to get to the maximum.)
So you may need 3-4 tor instances on your 1Gbps connection. And you can only have 2 tor instances per public IPv4 address.
Larger, faster relays help clients achieve low-latency, high bandwidth connections.
This may depend? Do we have a graph of actual headroom / saturation in the network of boxes versus consensus weight versus max box speed? Does weight back off below historically sensed saturation levels? Because seems even the fastest box would become high latency low bandwidth upon saturation, and a path through three 40Mbit boxes that are all 25% loaded might provide better performance than through a single saturated gig box anywhere in path.
Hi tor-relay list,
El 30/09/17 a las 14:02, teor escribió:
On 30 Sep 2017, at 09:55, Andy Isaacson adi@hexapodia.org wrote:
…
And you can only have 2 tor instances per public IPv4 address.
Why? Is there any place where I can find this kind of info?
Maybe it's another issue, but I have recently tried to run a second relay behind the same IPv4 address than my first relay, and the connection quality strongly diminished. I suppose my ISP equipment was not able to handle the two relays on NAT, but I would need to investigate further.
Cheers,
-- S
On 2 Oct 2017, at 03:53, Santiago santiagorr@riseup.net wrote:
Hi tor-relay list,
El 30/09/17 a las 14:02, teor escribió:
On 30 Sep 2017, at 09:55, Andy Isaacson adi@hexapodia.org wrote:
… And you can only have 2 tor instances per public IPv4 address.
Why?
It makes it harder for people to start hundreds of relays.
Is there any place where I can find this kind of info?
Yes, it's documented in the tor manual page. And search the list archives for explanations.
Maybe it's another issue, but I have recently tried to run a second relay behind the same IPv4 address than my first relay, and the connection quality strongly diminished. I suppose my ISP equipment was not able to handle the two relays on NAT, but I would need to investigate further.
This is typically many consumer NAT boxes. Every active tor relay has ~6000 open connections to other relays. Exits have even more. Many systems just don't have this capacity.
T
On Mon, Oct 2, 2017 at 3:53 AM, Santiago santiagorr@riseup.net wrote:
And you can only have 2 tor instances per public IPv4 address.
Why? Is there any place where I can find this kind of info?
Read the archives of this list linked at the bottom of every message. As an operator you'll find lots more interesting subjects there too.
Maybe it's another issue, but I have recently tried to run a second relay behind the same IPv4 address than my first relay, and the connection quality strongly diminished. I suppose my ISP equipment was not able to handle the two relays on NAT, but I would need to investigate further.
Lots of hardware for use in the home, whether ISP provided or bought from wherever by the user, has been known to fall over under load, cable / dsl / fiber modems, whether in bridge or router modes, wifi, etc.
For tor you need to test with tens to hundreds of TCP connections or more in parallel. The simple online "speedtests" don't do that. One way is to load up increasing numbers of opensource Unix iso's, conference videos, whatever... into whatever torrent client and watch the stats. If upon passing the expected / required number of connections, it starts falling significantly off the maximum recorded speed, never recovers when unloaded, locks up, reboots, melts / smokes / combusts, etc... then try another brand.
Or instead of router mode, try bridge mode feeding into any old pc running [Free]BSD / Linux to do the functions of routing, wifi, firewall, nat, dhcp, dns, etc... this may often perform better and give more flexibility.
grarpamp grarpamp@gmail.com wrote:
On Mon, Oct 2, 2017 at 3:53 AM, Santiago santiagorr@riseup.net wrote:
And you can only have 2 tor instances per public IPv4 address.
Why? Is there any place where I can find this kind of info?
Read the archives of this list linked at the bottom of every message. As an operator you'll find lots more interesting subjects there too.
Maybe it's another issue, but I have recently tried to run a second relay behind the same IPv4 address than my first relay, and the connection quality strongly diminished. I suppose my ISP equipment was not able to handle the two relays on NAT, but I would need to investigate further.
Huh? What kind of ISP NATs its customers' connections? Your ISP should be assigning your machine/router a legitimate, unique IPv4 address. The assignment is often, even usually, a temporary assignment via DHCP, but it should not be a private address. If NAT is a factor, that should happen at the boundary of your own private network, not at an ISP's facility.
Lots of hardware for use in the home, whether ISP provided or bought from wherever by the user, has been known to fall over under load, cable / dsl / fiber modems, whether in bridge or router modes, wifi, etc.
For tor you need to test with tens to hundreds of TCP connections or more in parallel. The simple online "speedtests" don't do that. One way is to load up increasing numbers of opensource Unix iso's, conference videos, whatever... into whatever torrent client and watch the stats. If upon passing the expected / required number of connections, it starts falling significantly off the maximum recorded speed, never recovers when unloaded, locks up, reboots, melts / smokes / combusts, etc... then try another brand.
I'll second the above comments. Most of those little router boxes are running some form of LINUX or FreeBSD as an embedded configuration, which includes swapping and paging being disabled due to the absence of secondary storage. All of them have limited RAM. One typical problem with running tor on a NATed machine behind such a device is that the NAT table grows until all of the real memory on the device has been consumed and there is no more room for new NAT entries.
Or instead of router mode, try bridge mode feeding into any old pc running [Free]BSD / Linux to do the functions of routing, wifi, firewall, nat, dhcp, dns, etc... this may often perform better and give more flexibility.
Yes, and because there is secondary storage (HDD and/or SSD), paging is available if the routing functions' memory needs grow larger than the available real memory. Home electronics store routers cannot hold a candle to a full OS with a decent packet filter.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
On Mon, 02 Oct 2017 13:19:59 +0000, Scott Bennett wrote: ...
Huh? What kind of ISP NATs its customers' connections?
All kinds of ISPs that were too late to grab enough IPv4 space for their customer base. Here in germany these are mostly the cable companies.
Also, generally mobile IP.
Andreas
Or instead of router mode, try bridge mode feeding into any old pc running
Noting that even some crappy hardware will still fall over when put in its so called "bridge" mode, which should just be some packet buffering between the wires and their encodings, but it's obviously still looking at the traffic above layer2. So you may still need to swap out hardware.
because there is secondary storage (HDD and/or SSD), pagingis available if the routing functions' memory needs grow larger than the
Sure, but there's no free substitute for RAM, and you probably don't want packets burning a hole in your SSD. Add more RAM if not maxed out. disable swap, boot USB, set read-only, use small ramdisks for write paths. If used RAM for a used PC isn't in budget or isn't enough, then maybe spindle, but it won't be as fast. And eventually CPU or interrupts or i/o get swamped. Then you put a newer PC that can hold proper amounts of RAM, CPU, etc.
grarpamp grarpamp@gmail.com wrote:
Or instead of router mode, try bridge mode feeding into any old pc running
Noting that even some crappy hardware will still fall over when put in its so called "bridge" mode, which should just be some packet buffering between the wires and their encodings, but it's obviously still looking at the traffic above layer2. So you may still need to swap out hardware.
Absolutely. Another reason to avoid electronics store routers for tor (or many other things) is the information in recently exposed documents that the CIA started invading those devices and, where possible, "upgrading" their firmware as standard practice at least a decade ago.
because there is secondary storage (HDD and/or SSD), pagingis available if the routing functions' memory needs grow larger than the
Sure, but there's no free substitute for RAM, and you probably don't want packets burning a hole in your SSD. Add more RAM if not maxed out.
My point was intended to be only that having a regular computer handle the routing means it doesn't have to die if available RAM be exhausted, i.e., not an argument for speed, but rather for survival under unusual loads. Now that I'm more awake than when I wrote that, though, I realize I don't recall whether routing and NAT tables and mbufs are page-fixed or pageable anyway. :-( It's still better to have a router that you own and the CIA [probably] doesn't.
disable swap, boot USB, set read-only, use small ramdisks for write paths. If used RAM for a used PC isn't in budget or isn't enough, then maybe spindle, but it won't be as fast. And eventually CPU or interrupts or i/o get swamped. Then you put a newer PC that can hold proper amounts of RAM, CPU, etc.
Very true. The device need also not be dedicated to just those functions. Many people would prefer to stick a heavily used relay on their border gateway machine to keep its traffic load off their LANs anyway. Also, if FreeBSD is used, kernel memory for routing tables, NAT tables if used, and mbufs should be allocated from 4 MB superpages, allowing the routing to run very fast. And with an electronics store router, you don't have the kernel configuration information available to look at, whereas you do have that and all the rest as well if you install the OS yourself. Let's also not omit the ability to apply security fixes as they become available, where the store-bought boxes would be running obsolete and unsafe OS in their firmware, probably by the time the store sold them.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
El 02/10/17 a las 13:19, Scott Bennett escribió:
grarpamp grarpamp@gmail.com wrote:
On Mon, Oct 2, 2017 at 3:53 AM, Santiago santiagorr@riseup.net wrote:
…
Huh? What kind of ISP NATs its customers' connections? Your ISPshould be assigning your machine/router a legitimate, unique IPv4 address. The assignment is often, even usually, a temporary assignment via DHCP, but it should not be a private address. If NAT is a factor, that should happen at the boundary of your own private network, not at an ISP's facility.
It seems that a French ISP was also planning to share an IPv4 address per four costumers.
…
I'll second the above comments. Most of those little router boxes arerunning some form of LINUX or FreeBSD as an embedded configuration, which includes swapping and paging being disabled due to the absence of secondary storage. All of them have limited RAM. One typical problem with running tor on a NATed machine behind such a device is that the NAT table grows until all of the real memory on the device has been consumed and there is no more room for new NAT entries.
I am not currently able to replace the modem/router my ISP provides. But I'd plan to give it away in the future.
In the meantime, I think it would be great to have IPv6-only relays, to avoid this kind of NAT-related issues.
Cheers,
-- S
On 2 Oct 2017, at 16:54, Santiago santiagorr@riseup.net wrote:
El 02/10/17 a las 13:19, Scott Bennett escribió: grarpamp grarpamp@gmail.com wrote:
On Mon, Oct 2, 2017 at 3:53 AM, Santiago santiagorr@riseup.net wrote:
…
Huh? What kind of ISP NATs its customers' connections? Your ISPshould be assigning your machine/router a legitimate, unique IPv4 address. The assignment is often, even usually, a temporary assignment via DHCP, but it should not be a private address. If NAT is a factor, that should happen at the boundary of your own private network, not at an ISP's facility.
It seems that a French ISP was also planning to share an IPv4 address per four costumers.
…
... One typical problem with running tor on a NATed machine behind such a device is that the NAT table grows until all of the real memory on the device has been consumed and there is no more room for new NAT entries.
I am not currently able to replace the modem/router my ISP provides. But I'd plan to give it away in the future.
In the meantime, I think it would be great to have IPv6-only relays, to avoid this kind of NAT-related issues.
We'd love to make this happen, but the anonymity implications of mixed IPv4-only and IPv6-only (non-clique) networks need further research. Search the list archives for details.
T
teor teor2345@gmail.com wrote:
On 2 Oct 2017, at 16:54, Santiago santiagorr@riseup.net wrote:
El 02/10/17 a las 13:19, Scott Bennett escribi?: grarpamp grarpamp@gmail.com wrote:
On Mon, Oct 2, 2017 at 3:53 AM, Santiago santiagorr@riseup.net wrote:
?
Huh? What kind of ISP NATs its customers' connections? Your ISPshould be assigning your machine/router a legitimate, unique IPv4 address. The assignment is often, even usually, a temporary assignment via DHCP, but it should not be a private address. If NAT is a factor, that should happen at the boundary of your own private network, not at an ISP's facility.
It seems that a French ISP was also planning to share an IPv4 address per four costumers.
?
... One typical problem with running tor on a NATed machine behind such a device is that the NAT table grows until all of the real memory on the device has been consumed and there is no more room for new NAT entries.
I am not currently able to replace the modem/router my ISP provides. But I'd plan to give it away in the future.
In the meantime, I think it would be great to have IPv6-only relays, to avoid this kind of NAT-related issues.
We'd love to make this happen, but the anonymity implications of mixed IPv4-only and IPv6-only (non-clique) networks need further research. Search the list archives for details.
teor, Couldn't that be taken care of in the tor client code? For example, a client, having chosen a path through which an IPv6-only relay, could extend the path by one hop to tunnel through a node with both types of interface published? A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
On 3 Oct 2017, at 03:07, Scott Bennett bennett@sdf.org wrote:
In the meantime, I think it would be great to have IPv6-only relays, to avoid this kind of NAT-related issues.
We'd love to make this happen, but the anonymity implications of mixed IPv4-only and IPv6-only (non-clique) networks need further research. Search the list archives for details.
Couldn't that be taken care of in the tor client code? For example, aclient, having chosen a path through which an IPv6-only relay, could extend the path by one hop to tunnel through a node with both types of interface published?
Yes, clients choose paths, and could choose them using these kinds of restrictions. But current tor relay versions won't extend to other relays over IPv6. Because we don't understand the anonymity implications of restricting the next relay in the path based on the previous relay. Which is why we need further research.
A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
T
teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 03:07, Scott Bennett bennett@sdf.org wrote:
In the meantime, I think it would be great to have IPv6-only relays, to avoid this kind of NAT-related issues.
We'd love to make this happen, but the anonymity implications of mixed IPv4-only and IPv6-only (non-clique) networks need further research. Search the list archives for details.
Couldn't that be taken care of in the tor client code? For example, aclient, having chosen a path through which an IPv6-only relay, could extend the path by one hop to tunnel through a node with both types of interface published?
Yes, clients choose paths, and could choose them using these kinds of restrictions. But current tor relay versions won't extend to other relays over IPv6. Because we don't understand the anonymity implications of restricting the next relay in the path based on the previous relay. Which is why we need further research.
Here's a procedure: if the next hop/destination does not use a protocol in common with the client/current hop, a dual-protocoled node must be interposed; else use the originally selected hop/destination directly. The client-to-first-hop situation is analogous to using a set of entry guards today, so that much should be okay. What do IPv6-only clients currently do? Allowing IPv6 destinations today limits exit-hop selections to dual- protocol-capable exit nodes, which is like using an "ExitNodesIPv6" (if there were such a thing) line in torrc with a long and growing list of nodes. How long would that list have to be for the warning on the man page under the ExitNodes statement definition to become unimportant? How many were there when IPv6 destinations were first allowed? For interposing dual-protocoled nodes along the way, how many do there have to be for it to become "not too limiting"?
A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
That's okay, but what if the node is an entry-and-middle node only?
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
Scott Bennett bennett@sdf.org wrote:
teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 03:07, Scott Bennett bennett@sdf.org wrote:
In the meantime, I think it would be great to have IPv6-only relays, to avoid this kind of NAT-related issues.
We'd love to make this happen, but the anonymity implications of mixed IPv4-only and IPv6-only (non-clique) networks need further research. Search the list archives for details.
Couldn't that be taken care of in the tor client code? For example, aclient, having chosen a path through which an IPv6-only relay, could extend the path by one hop to tunnel through a node with both types of interface published?
Yes, clients choose paths, and could choose them using these kinds of restrictions. But current tor relay versions won't extend to other relays over IPv6. Because we don't understand the anonymity implications of restricting the next relay in the path based on the previous relay. Which is why we need further research.
Here's a procedure: if the next hop/destination does not use a protocolin common with the client/current hop, a dual-protocoled node must be interposed; else use the originally selected hop/destination directly. The client-to-first-hop situation is analogous to using a set of entry guards today, so that much should be okay. What do IPv6-only clients currently do? Allowing IPv6 destinations today limits exit-hop selections to dual- protocol-capable exit nodes, which is like using an "ExitNodesIPv6" (if there were such a thing) line in torrc with a long and growing list of nodes. How long would that list have to be for the warning on the man page under the ExitNodes statement definition to become unimportant? How many were there when IPv6 destinations were first allowed? For interposing dual-protocoled nodes along the way, how many do there have to be for it to become "not too limiting"?
A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
That's okay, but what if the node is an entry-and-middle node only?
Hmm. On second thought, it's *not* okay because it means that such a node cannot be a middle node because it could only connect to the IPv6 universe. Or the man page is wrong about OutboundBindAddress. Or there is something else amiss.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
That's okay, but what if the node is an entry-and-middle node only?Hmm. On second thought, it's *not* okay because it means that such anode cannot be a middle node because it could only connect to the IPv6 universe. Or the man page is wrong about OutboundBindAddress. Or there is something else amiss.
"This option may be used twice, once with an IPv4 address and once with an IPv6 address"
T
teor teor2345@gmail.com wrote:
A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
That's okay, but what if the node is an entry-and-middle node only?Hmm. On second thought, it's *not* okay because it means that such anode cannot be a middle node because it could only connect to the IPv6 universe. Or the man page is wrong about OutboundBindAddress. Or there is something else amiss.
"This option may be used twice, once with an IPv4 address and once with an IPv6 address"
I see the problem. I'm running 0.3.1.6-rc at present, 0.3.2.1-alpha has been installed since I last started tor, and the timestamp on the man page says "Oct 2 2012". :-( Now I have to track down why the man page updates have not been getting installed. Sigh. Sorry for that bit of noise. The other questions remain, however, including the one above.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
On 3 Oct 2017, at 08:52, Scott Bennett bennett@sdf.org wrote:
teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 03:07, Scott Bennett bennett@sdf.org wrote:
In the meantime, I think it would be great to have IPv6-only relays, to avoid this kind of NAT-related issues.
We'd love to make this happen, but the anonymity implications of mixed IPv4-only and IPv6-only (non-clique) networks need further research. Search the list archives for details.
Couldn't that be taken care of in the tor client code? For example, a client, having chosen a path through which an IPv6-only relay, could extend the path by one hop to tunnel through a node with both types of interface published?
Yes, clients choose paths, and could choose them using these kinds of restrictions. But current tor relay versions won't extend to other relays over IPv6. Because we don't understand the anonymity implications of restricting the next relay in the path based on the previous relay. Which is why we need further research.
Here's a procedure: if the next hop/destination does not use a protocolin common with the client/current hop, a dual-protocoled node must be interposed; else use the originally selected hop/destination directly.
But is this procedure safe? And is it an efficient use of resources to add extra hops? (That is, is there a more efficient 3-hop algorithm that's just as safe?) We need research to answer these questions.
The client-to-first-hop situation is analogous to using a set of entry guards today, so that much should be okay. What do IPv6-only clients currently do?
Choose a relay with an IPv6 ORPort. (Or configure a bridge with an IPv6 ORPort or pluggable transport.)
IPv6-only clients need to be manually configured using "ClientUseIPv4 0", because this feature is still experimental. We think it will be safer when all dual-stack clients use some IPv6 guards.
Allowing IPv6 destinations today limits exit-hop selections to dual-protocol-capable exit nodes
No, IPv4-only exits are still useful and used, because tor clients typically send DNS names to exits. IPv6 DNS records typically have IPv4 as well, so any exit will work. (There's a ticket for better handling of DNS that only resolves to IPv6.)
And in the rare case of address literals, the client can choose a capable exit. (I think there's a ticket for this, too.)
which is like using an "ExitNodesIPv6" (if there were such a thing) line in torrc with a long and growing list of nodes.
There are flags on SOCKSPort for IP versions, including PreferIPv6, which is the default.
How long would that list have to be for the warning on the man page under the ExitNodes statement definition to become unimportant? How many were there when IPv6 destinations were first allowed?
The situation isn't analogous.
For safety, IPv6 exit destinations were turned off by default until we had enough IPv6 exits. Now they are on by default.
But we haven't done the same thing for relays, because we don't know how to design the feature so it's safe.
For interposing dual-protocoled nodes along the way, how many do therehave to be for it to become "not too limiting"?
This is one of the questions we need researchers to answer.
A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
That's okay, but what if the node is an entry-and-middle node only?
Relays don't extend to IPv6, so you can set the option, but it won't do anything, because there are no outbound IPv6 connections.
Tim
On Tue, 3 Oct 2017 09:53:46 -0400 teor teor2345@gmail.com wrote:
For interposing dual-protocoled nodes along the way, how many do therehave to be for it to become "not too limiting"?
This is one of the questions we need researchers to answer.
I can't help but feel you are overcomplicating this.
Clients create a circuit by randomly picking 3 nodes out of the all-nodes pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are IPv4-only, the whole selection can be thrown away and repeated.
That way IPv6-only relays could get some usage on a totally random basis, with no compromises and no restraining "of the next hop based on the previous one", not hurting anonymity. Clients just need to know which nodes are IPv4-only, IPv6-only or dual-stack, to not attempt unworkable combinations, discarding them instead.
And as there are more and more dual-stack or IPv6-only relays, the "throw away" step will be needed less and less often.
On 3 Oct 2017, at 10:57, Roman Mamedov rm@romanrm.net wrote:
On Tue, 3 Oct 2017 09:53:46 -0400 teor teor2345@gmail.com wrote:
For interposing dual-protocoled nodes along the way, how many do there have to be for it to become "not too limiting"?
This is one of the questions we need researchers to answer.
I can't help but feel you are overcomplicating this.
Clients create a circuit by randomly picking 3 nodes out of the all-nodes pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are IPv4-only, the whole selection can be thrown away and repeated.
That way IPv6-only relays could get some usage on a totally random basis, with no compromises and no restraining "of the next hop based on the previous one", not hurting anonymity. Clients just need to know which nodes are IPv4-only, IPv6-only or dual-stack, to not attempt unworkable combinations, discarding them instead.
Discarding unworkable combinations and restraining node choices seem equivalent to me, although the relay weights may be different.
And as there are more and more dual-stack or IPv6-only relays, the "throw away" step will be needed less and less often.
If you think this will work and is safe for client anonymity, then the next step is to write a tor proposal. Having a concrete design could help with analysing the anonymity implications as well.
I think IPv6-only relays are a lower priority than better IPv6 and dual-stack client support, and IPv6-only bridge support But we could do both in the same release.
Tim
Roman Mamedov rm@romanrm.net wrote:
On Tue, 3 Oct 2017 09:53:46 -0400 teor teor2345@gmail.com wrote:
For interposing dual-protocoled nodes along the way, how many do therehave to be for it to become "not too limiting"?
This is one of the questions we need researchers to answer.
I can't help but feel you are overcomplicating this.
Clients create a circuit by randomly picking 3 nodes out of the all-nodes pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are IPv4-only, the whole selection can be thrown away and repeated.
That way IPv6-only relays could get some usage on a totally random basis, with no compromises and no restraining "of the next hop based on the previous one", not hurting anonymity. Clients just need to know which nodes are IPv4-only, IPv6-only or dual-stack, to not attempt unworkable combinations, discarding them instead.
Looks good to me, Roman. I like it better than what I suggested, though adding some variability to path length had some appeal, too. Your way is certainly simpler. If tor ever starts to support TCP over UDP and/or TCP over SCTP, that will be a similar situation for a while, where some relays can do both and others are limited to one protocol or the other.
And as there are more and more dual-stack or IPv6-only relays, the "throw away" step will be needed less and less often.
Yet the same process could be applied to the TCP-over-non-TCP situation quite easily, too. I think I like your way even better now. My memory is a bit hazy on this, but I seem to recall watching a video file of Roger Dingledine giving a talk somewhere about tor long ago in which he commented happily that the tor network had grown to where it usually had at least 300 nodes up and running at all times of day. If 300 were enough for path selection before, aren't they still enough? Aren't there at least 300 IPv6-only nodes and at least 300 dual-protocol nodes now? And, of course, there must have been a time when the network was smaller than 300...
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
Little thought yet but related, figured if client host is dual stack, could separate "client over WAN via IPv<whatever> to reach relay" function from traffic routed into tor's cells for carriage to pop out other side, like a VPN for IP versions. Exits would have to tag their support of "exit v4 and/or v6 to clearnet" in consensus so circuits get built to a place that can actually ship the client's cells out to clearnet. Relays WAN function already offer inbound connection capabilities by their listed OR IP format in consensus, but not yet any outbound IP version, which client must also know from consensus and compute to reach next input. Building WAN paths is different from what is carried within. So that, it seems possible, if in consensus, to make WAN path like... v6 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v6 ==> v6 clearnet v4 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v4 ==> v4 clearnet Not quite sure why yet, or if theory correct.
teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 08:52, Scott Bennett bennett@sdf.org wrote:
teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 03:07, Scott Bennett bennett@sdf.org wrote:
In the meantime, I think it would be great to have IPv6-only relays, to avoid this kind of NAT-related issues.
We'd love to make this happen, but the anonymity implications of mixed IPv4-only and IPv6-only (non-clique) networks need further research. Search the list archives for details.
Couldn't that be taken care of in the tor client code? For example, a client, having chosen a path through which an IPv6-only relay, could extend the path by one hop to tunnel through a node with both types of interface published?
Yes, clients choose paths, and could choose them using these kinds of restrictions. But current tor relay versions won't extend to other relays over IPv6. Because we don't understand the anonymity implications of restricting the next relay in the path based on the previous relay. Which is why we need further research.
Here's a procedure: if the next hop/destination does not use a protocolin common with the client/current hop, a dual-protocoled node must be interposed; else use the originally selected hop/destination directly.
But is this procedure safe?
Why might it not be safe?
And is it an efficient use of resources to add extra hops?
Well, the additional hops ought to increase the safety. Wouldn't that have to be considered in an efficiency calculation?
(That is, is there a more efficient 3-hop algorithm that's just as safe?) We need research to answer these questions.
It seems to me that a) using a small number (i.e., 3) of hops reduces safety and b) a constant number of hops also reduces safety. Added hops to make an unpredictable path length ought to counter the alleged safety issues in choosing hops from a smaller pool. Also, unless the pool of dual-protocol hops is much smaller than the number of relays available, say, ten years ago, I don't see a reason to worry. (We were thrilled to have 900 - 1300 up at any one time.)
The client-to-first-hop situation is analogous to using a set of entry guards today, so that much should be okay. What do IPv6-only clients currently do?
Choose a relay with an IPv6 ORPort. (Or configure a bridge with an IPv6 ORPort or pluggable transport.)
IPv6-only clients need to be manually configured using "ClientUseIPv4 0", because this feature is still experimental. We think it will be safer when all dual-stack clients use some IPv6 guards.
Dual-protocol clients connecting to dual-protocol entry nodes ought to choose randomly which protocol to use. Similarly, a dual-protocol relay extending to another dual-protocol relay ought to choose randomly which protocol to use for the connection. Both clients and relays would have the option of retrying the attempt via the other protocol in the event a failed attempt to connect. This ought to have been implemented already, but can still be done soon.
Allowing IPv6 destinations today limits exit-hop selections to dual-protocol-capable exit nodes
No, IPv4-only exits are still useful and used, because tor clients typically send DNS names to exits. IPv6 DNS records typically have IPv4 as well, so any exit will work. (There's a ticket for better handling of DNS that only resolves to IPv6.)
And in the rare case of address literals, the client can choose a capable exit. (I think there's a ticket for this, too.)
Okay, but those circuits are incidental to the circuit that a user wants, which is limited to dual-protocol-capable nodes.
which is like using an "ExitNodesIPv6" (if there were such a thing) line in torrc with a long and growing list of nodes.
There are flags on SOCKSPort for IP versions, including PreferIPv6, which is the default.
How long would that list have to be for the warning on the man page under the ExitNodes statement definition to become unimportant? How many were there when IPv6 destinations were first allowed?
The situation isn't analogous.
For safety, IPv6 exit destinations were turned off by default until we had enough IPv6 exits. Now they are on by default.
I repeat: how many were there when IPv6 destinations were first allowed? How many when the default was changed?
But we haven't done the same thing for relays, because we don't know how to design the feature so it's safe.
As soon as there are as many IPv6-capable relays as there were IPv4 relays ten years ago, there will no longer be any reason not to enable their use. How close are we to reaching that number now? Or have we already passed it?
For interposing dual-protocoled nodes along the way, how many do therehave to be for it to become "not too limiting"?
This is one of the questions we need researchers to answer.
Maybe. That depends upon whether we already have at least as many as were considered safe for IPv4.
A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
That's okay, but what if the node is an entry-and-middle node only?Relays don't extend to IPv6, so you can set the option, but it won't do anything, because there are no outbound IPv6 connections.
But they could, and ought to, be doing that, at least in some circumstances, as noted above.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
On 4 Oct 2017, at 01:38, grarpamp grarpamp@gmail.com wrote:
... Exits would have to tag their support of "exit v4 and/or v6 to clearnet" in consensus so circuits get built to a place that can actually ship the client's cells out to clearnet. Relays WAN function already offer inbound connection capabilities by their listed OR IP format in consensus, but not yet any outbound IP version, which client must also know from consensus and compute to reach next input.
The ExitPolicy ad IPv6Exit options on Exits are put into the relay's descriptor, which gets turned into the microdescriptor, which clients use to select exits.
And most clients just send a DNS name and a set of IP version flags.
For the rare cases where literal addresses are used, or there are IPv6-only websites over DNS, tor could be smarter.
We accept patches, but it's not a high priority, because it works for almost all hostnames / addresses that clients actually use.
Building WAN paths is different from what is carried within. So that, it seems possible, if in consensus, to make WAN path like... v6 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v6 ==> v6 clearnet v4 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v4 ==> v4 clearnet
This abstraction layer exists in tor and it works fine.
On 4 Oct 2017, at 00:49, Scott Bennett bennett@sdf.org wrote:
teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 08:52, Scott Bennett bennett@sdf.org wrote:
teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 03:07, Scott Bennett bennett@sdf.org wrote:
> In the meantime, I think it would be great to have IPv6-only relays, to > avoid this kind of NAT-related issues.
We'd love to make this happen, but the anonymity implications of mixed IPv4-only and IPv6-only (non-clique) networks need further research. Search the list archives for details.
Couldn't that be taken care of in the tor client code? For example, a client, having chosen a path through which an IPv6-only relay, could extend the path by one hop to tunnel through a node with both types of interface published?
Yes, clients choose paths, and could choose them using these kinds of restrictions. But current tor relay versions won't extend to other relays over IPv6. Because we don't understand the anonymity implications of restricting the next relay in the path based on the previous relay. Which is why we need further research.
Here's a procedure: if the next hop/destination does not use a protocol in common with the client/current hop, a dual-protocoled node must be interposed; else use the originally selected hop/destination directly.
But is this procedure safe?
Why might it not be safe?
Because it may make clients distinguishable from each other. Client indistinguishability is a key part of tor's anonymity design. I encourage you to read the original Tor paper.
And is it an efficient use of resources to add extra hops?
Well, the additional hops ought to increase the safety. Wouldn't thathave to be considered in an efficiency calculation?
(That is, is there a more efficient 3-hop algorithm that's just as safe?) We need research to answer these questions.
It seems to me that a) using a small number (i.e., 3) of hops reducessafety and b) a constant number of hops also reduces safety. Added hops to make an unpredictable path length ought to counter the alleged safety issues in choosing hops from a smaller pool.
No, because added hops make clients distinguishable via latency, and as far as we can tell, they don't increase safety. There's a paper on this, too.
Also, unless the pool of dual-protocol hops is much smaller than the number of relays available, say, ten years ago, I don't see a reason to worry. (We were thrilled to have 900 - 1300 up at any one time.)
Tor provides better anonymity guarantees than it used to ten years ago. So it's today's anonymity we need to measure against, not 2007's.
The client-to-first-hop situation is analogous to using a set of entry guards today, so that much should be okay. What do IPv6-only clients currently do?
Choose a relay with an IPv6 ORPort. (Or configure a bridge with an IPv6 ORPort or pluggable transport.)
IPv6-only clients need to be manually configured using "ClientUseIPv4 0", because this feature is still experimental. We think it will be safer when all dual-stack clients use some IPv6 guards.
Dual-protocol clients connecting to dual-protocol entry nodes ought tochoose randomly which protocol to use. Similarly, a dual-protocol relay extending to another dual-protocol relay ought to choose randomly which protocol to use for the connection. Both clients and relays would have the option of retrying the attempt via the other protocol in the event a failed attempt to connect. This ought to have been implemented already, but can still be done soon.
I agree.
We accept proposals, and patches. I've been trying to find time to write these ones.
If my emails are a bit short, or a bit repetitive, or point you to other resources, it's because I'm trying to keep some time for volunteer development work like this.
Allowing IPv6 destinations today limits exit-hop selections to dual- protocol-capable exit nodes
No, IPv4-only exits are still useful and used, because tor clients typically send DNS names to exits. IPv6 DNS records typically have IPv4 as well, so any exit will work. (There's a ticket for better handling of DNS that only resolves to IPv6.)
And in the rare case of address literals, the client can choose a capable exit. (I think there's a ticket for this, too.)
Okay, but those circuits are incidental to the circuit that a user wants,which is limited to dual-protocol-capable nodes.
No, this isn't how tor works. Read the relevant proposals, or the source code.
...
How long would that list have to be for the warning on the man page under the ExitNodes statement definition to become unimportant? How many were there when IPv6 destinations were first allowed?
The situation isn't analogous.
For safety, IPv6 exit destinations were turned off by default until we had enough IPv6 exits. Now they are on by default.
I repeat: how many were there when IPv6 destinations were first allowed?
I don't know. Read the relevant proposals.
How many when the default was changed?
I don't know, but I think it was 2016, so you can check the metrics graphs. (Do we have a metrics graph for IPv6 exits? Or IPv6 ORPorts? Maybe we should!)
But we haven't done the same thing for relays, because we don't know how to design the feature so it's safe.
As soon as there are as many IPv6-capable relays as there were IPv4relays ten years ago, there will no longer be any reason not to enable their use. How close are we to reaching that number now? Or have we already passed it?
It's today's anonymity we need to measure against, not 2007's.
For interposing dual-protocoled nodes along the way, how many do there have to be for it to become "not too limiting"?
This is one of the questions we need researchers to answer.
Maybe. That depends upon whether we already have at least as many aswere considered safe for IPv4.
So it's today's anonymity we need to measure against, not 2007's.
A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
That's okay, but what if the node is an entry-and-middle node only?
Relays don't extend to IPv6, so you can set the option, but it won't do anything, because there are no outbound IPv6 connections.
But they could, and ought to, be doing that, at least in some circumstances, as noted above.
I agree.
But email threads can only achieve so much.
The next step is a proposal, and then a patch.
T
-- Tim / teor
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
On Wed, Oct 4, 2017 at 1:49 AM, teor teor2345@gmail.com wrote:
And most clients just send a DNS name and a set of IP version flags.
For the rare cases where literal addresses are used, or there are IPv6-only websites over DNS, tor could be smarter.
Not as rare as vanilla websurfing oriented people think. There are lots of tech implementors, pen test companies, diagnostics, p2p application developers, torrenters, etc... who use nothing but literal IPv4/6 numeric addresses over tor all day long. This is why it *sucks* that MAPADDRESS hasn't yet been enhanced to support even the simplest of /CIDR mapping semantics. *.fqdn DNS is hardly half the picture. See... https://trac.torproject.org/projects/tor/ticket/3982
On 7 Oct 2017, at 23:04, grarpamp grarpamp@gmail.com wrote:
On Wed, Oct 4, 2017 at 1:49 AM, teor teor2345@gmail.com wrote: And most clients just send a DNS name and a set of IP version flags.
For the rare cases where literal addresses are used, or there are IPv6-only websites over DNS, tor could be smarter.
Not as rare as vanilla websurfing oriented people think. There are lots of tech implementors, pen test companies, diagnostics, p2p application developers, torrenters, etc... who use nothing but literal IPv4/6 numeric addresses over tor all day long. This is why it *sucks* that MAPADDRESS hasn't yet been enhanced to support even the simplest of /CIDR mapping semantics. *.fqdn DNS is hardly half the picture. See... https://trac.torproject.org/projects/tor/ticket/3982
You're right, we don't know the number of literal vs DNS connections. I added it to the ticket: https://trac.torproject.org/projects/tor/ticket/23761#comment:3
T
Hi IPonU, Thanks for running a relay.
As I understand it, running one larger relay may be better. Traffic correlation attacks by a global persistent adversary might have a harder time due to the fact that more circuits are using one IP, rather than less circuits spread across multiple IPs. In no way is this a cure-all, but it might help.
Cheers
On Fri, Sep 29, 2017 at 12:37 AM IPonU contact@iponu.net wrote:
Hi Tor list,
I'm already running a small exit node (100Mbps bandwidth) and I'm ready to spend more money on it, so have a question for you guys :
Is it better if I run other small ones (100Mbps too) or only 1 big exit relay (1 Gbps) ? What's best for the network stability/security ?
Thanks a lot
IPonU
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
Andreas Krey -
Andy Isaacson -
Christopher -
grarpamp -
I -
IPonU -
John Ricketts -
Ralph Seichter -
Roman Mamedov -
Santiago -
Scott Bennett -
teor -
Tor Node Admin ＠ SechsNullDrei.org