Your only option would be to ask your ISP to uncensor the internet, unfortunately. Tor requires that all relays are able to contact all other relays, and those which cannot participate in the network.

I think you meant to say: "Tor requires that all relays are able to contact all directory authorities" Tor certainly does NOT require all relays can contact all relays. In fact, the network is *very* partitioned... but as of the past few months I haven't put any energy into proving this; although I do have some mostly finished twisted python code to make all two hop tor circuits and records circuit build failures and circuit build timeouts.

Hi, On 17/09/17 00:56, Roger Dingledine wrote:

Actually, no, we want it to be the case that all relays can reach all relays. The less true that becomes -- that is, the less clique-like the network topology becomes -- the more complicated the anonymity measurements become, and that is potentially quite bad.

I would love to be able to add an "unreachable relays" box to Atlas to let operators see which relays they can't reach. I'll have a think about this. Thanks, Iain.

One must take care in the design of such Tor network scanning tools to not make successive circuits through the same relays repeatedly. Instead relay pairs should be shuffled. Yes AND if circuit building A->B fails but B->A succeeds then a subsequent A->B should also succeed. On Sun, Sep 17, 2017 at 08:11:29AM +0100, Iain R. Learmonth wrote:

Hi,

On 17/09/17 04:56, Iain R. Learmonth wrote:

...

I'll have a think about this.

I had a little think about this. While the search strategy is something to consider, I've hacked up a simple tool for building circuits and detecting, at a very high level, when it fails. I don't yet have the reason for the failure being captured.

To give an idea, failures are not uncommon but it is far more likely that the connections will succeed. I ran a trial with random selection to build two hop circuits.

The most interesting thing I've discovered so far is that it's common for the connections to fail in one direction but then succeed when the two relays are reversed. I can't be sure if this is because I can't reach one of the relays.

Thanks, Iain.

sqlite> select * from partitions; 80150521E1606A3C66FBD0502417775C06E83530|91516595837183D9ECD1318D00723A8676F4731C|REV|2017-09-17 06:55:42 C78AFFEEE320EA0F860961763E613FD2FAC855F5|57F5C55A6D76832400D679B4D6DCE6312CB724DD|FAIL|2017-09-17 06:55:58 721F8C234700A49C6CB42B8905719C4472698EEF|D01956B555BA59D422D994D41AC9634183974597|FAIL|2017-09-17 06:56:02 A39E63BF03742663C3945E774C71AD3B6DB935C5|C7FDF95CE03E8387780F75C9CD22B9A88C956BC9|FAIL|2017-09-17 06:56:08 1C173D4513B5BA66202E02CD4F61304FD4CC6C62|F2A6F1BB8ADD47CC9CC67928EA8EA7FDB3F92533|REV|2017-09-17 06:56:11 E5434A08ABDB8578C76BCDA3EECC22B5226D2CB4|77204802405A7DF1E7BD3BC579F8D1D7FB81DFD4|FAIL|2017-09-17 06:56:17 A0639496103E4F0C721E4CD31BD22CC9EF94C4CE|3C79699D4FBC37DE1A212D5033B56DAE079AC0EF|REV|2017-09-17 06:56:19 80150521E1606A3C66FBD0502417775C06E83530|C7BA56FA43EA6650E1644EA05CEC3A90F559B748|REV|2017-09-17 06:56:21 273C58C7764D2718A11FB7BA2205FC147948D7FE|8F2DDD78AC99CA0CFBFAF83CA33CE87785BB12C5|FAIL|2017-09-17 06:56:22 A2C2F9B652D6CFC6E0E329ED4577797CC9AD6BAB|655886ECB83A40E1BE989513D8C5C608D4B968C9|REV|2017-09-17 06:56:31 6DE375E172280727AEDCCA774D105692DEBF882A|A8A81263CB00469D98FF8E46A5A63FC4691BF3EA|REV|2017-09-17 06:56:41 88C615AC5F9591BFD48DB578B252B89A72F5C3AB|FF95E280D0DA09331EAE6B6C90F390A809D8FF9C|FAIL|2017-09-17 06:57:11 C9860279669435F6F237A04CC70849A3AB2BCB3B|5CA77202F93CDD06114A2F49309805F1881AE3E8|FAIL|2017-09-17 06:57:25 BA9E17048076E99AE359207A9436B7C07D1194C4|91716855ACF3C33C3EE49AAA046FA15486FDBDD5|FAIL|2017-09-17 06:57:26 7723B1B4B2B4D9D161209F770079A6F0A5A929BC|984096B174736E641F25B1B18312DA8629F1B2C4|FAIL|2017-09-17 06:57:48 D4691414A1C98DD3E022A0FFB1A2E11634BD0D21|887E2B73EDA109C09ADEBD6B1E788FDF620646B7|FAIL|2017-09-17 06:57:51 A07581D99FB42018B284484437DD60A0BA2BA254|8F46628BBDC55AA1065A6DB957E3A0187FD0C65F|FAIL|2017-09-17 06:58:04 A9B4409C72172BF3388B72CECB3F22538131F7C6|BD4C647508162F59CB44E4DFC1C2B2B8A9387CCA|REV|2017-09-17 06:58:13 4D6F22DE54C9CC48C15E2C01D53385D05D9AF31B|3B3D1284AAE1C039D3D0FB3BBAC38F2B0775FDED|FAIL|2017-09-17 06:58:17 18046895412A1185A1F3715D5FD2987CDC8C4B91|8E7093C928C5FF8D8E854A312002A582F131728F|FAIL|2017-09-17 06:58:25 A0639496103E4F0C721E4CD31BD22CC9EF94C4CE|A1D947A7751938A78FD00D971FC9098B5F397C6A|REV|2017-09-17 06:58:45 D7A6E23AEFB37D241D4408598434C7A6CB36F261|549FCA8AD9A43C8289A32D7702CDEDFE47029A43|FAIL|2017-09-17 06:58:56 5CECC5C30ACC4B3DE462792323967087CC53D947|4EADA139AC7A6EB32242BE10E662D9339A228A1F|REV|2017-09-17 06:59:03 926344F6AA5FFA5B64E677929BA118FE222D2B10|A790828A47B3C5E1AA6FFA8413998F28C105E4FD|REV|2017-09-17 06:59:23 8D2F90F1E216D5F9D9AB03B8BA7BF3167DD2D859|132AC31797DC7285E365AFDF5393C11158059CBB|FAIL|2017-09-17 06:59:35 8783261406392FFD39F41AD4D8F3293460A27EFD|A58151DB952DE7821AAB96948894D937149C301B|REV|2017-09-17 06:59:50 465E967E36285F2EB7B0683E2085829803F07C31|1399C98B3A8F90ABF7ACBFED9B38EE37CA294CF6|REV|2017-09-17 07:00:02 4110885745B673A45FDF150BE1CAC01FFAD640F1|18046895412A1185A1F3715D5FD2987CDC8C4B91|FAIL|2017-09-17 07:00:06 8352FAC3EA88A399A4F2F95CE762786944E75B06|1D503952419FF24F0764762245855DF8DC73391B|FAIL|2017-09-17 07:00:07 721F8C234700A49C6CB42B8905719C4472698EEF|44B7778B1D9A17237572A61B62F4487386BF728F|FAIL|2017-09-17 07:00:15 7A665FD6A05BB8EDD5362A7E25AEEA7D1F8122DC|92FE5D1485CCDA66822964DDFE6CCF3936218653|REV|2017-09-17 07:00:20 3CF4C6996B185090A576DB2170802FE9986F0553|1C1C275B8E9F8D0824424DDFABCA488BA24756B0|FAIL|2017-09-17 07:00:24 D665C959571041972EA8C0DD77559EF5579BA112|7DAF1969E80543C75369E4C88D32836487D6F09C|FAIL|2017-09-17 07:00:51 1702F6888757D679AFBEC9842F4B98E9B02B6D40|2DE827E0A349AEBE42E233F3B5ABE821321BFC8D|FAIL|2017-09-17 07:01:04 11FDAEE6B7F67B28A2BE88126625E21B467287EF|EBE1BDE602EC578A60B5EA5C84D996FA4052787B|FAIL|2017-09-17 07:01:18 FB8BEE7BF2606879496317BB42D0792EAA62153A|E64625ED5B01A1F0E97BCF0B5D431A432A24F408|FAIL|2017-09-17 07:01:21 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Roger Dingledine <arma@mit.edu> wrote:

On Sat, Sep 16, 2017 at 11:44:41PM +0000, dawuud wrote:

...

...

Your only option would be to ask your ISP to uncensor the internet, unfortunately. Tor requires that all relays are able to contact all other relays, and those which cannot participate in the network.

I think you meant to say: "Tor requires that all relays are able to contact all directory authorities"

Actually, no, we want it to be the case that all relays can reach all

That does not contradict what dawuud wrote, as can be clearly seen. What you want and what tor currently requires are not the same thing at all.

relays. The less true that becomes -- that is, the less clique-like the network topology becomes -- the more complicated the anonymity measurements become, and that is potentially quite bad.

That is why OutboundBindAddress values need to be published somewhere. Those of us who use packet filters in defense of our systems and/or our LANs can allow connections to our relays' ORPorts from otherwise blocked addresses if we know which of those blocked addresses have tor relays that may be trying to connect. Without that information, the only way you will ever get what you want is by turning away volunteers. Roger, you may recall our earlier discussion about this subject on this list. Since that time, I have used the information you provided then to automate the inclusion of the exit relay address list, and I have spot checked some of those addresses to make sure they were indeed landing in the TorRelays table used by my pf rules. I have not been able to tell whether or how much the exemption of exit addresses that were not published by the relays themselves has improved anything, but the change was made. If you could get tor to publish any otherwise unpublished addresses it uses to make outbound connections to other relays somewhere, those of us using packet filters could include the rest of the missing addresses in aid of the connectivity you want. One possible place to publish them might be the extra-info documents, which would avoid any alteration of the directory entry format. We relay operators could then use DownloadExtraInfo to get those documents, from which we could extract the OutboundBindAddress values and merge them in with what we already compile. However, the network load involved in downloading extra-info for all relays on a frequent basis could be avoided if that processing were done on a tor project machine and the address list posted on the project web site as is currently done for the exit relay list. However you decide the addresses should be made available, it must be included in any effort to make possible the full connectivity you envision.

...

Tor certainly does NOT require all relays can contact all relays. In fact, the network is *very* partitioned... but as of the past few months I haven't put any energy into proving this; although I do have some mostly finished twisted python code to make all two hop tor circuits and records circuit build failures and circuit build timeouts.

This is a great research area that it would be good to see some attention for.

In particular, if there are specific relays that are doing especially poorly for connectivity, we should work with them to try to get them to fix it, and if it's unfixable, downgrade their weights and/or boot them from the network.

1) It's not necessarily a relay operator's fault. 2) At least one problem can be fixed by supplying the missing data, as described above.

See also https://trac.torproject.org/projects/tor/ticket/12131 ("Measure connectivity patterns between relays") and https://trac.torproject.org/projects/tor/ticket/19068 ("Write and run a clique reachability test")

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 * **********************************************************************

Andreas Krey <a.krey@gmx.de> wrote:

On Sun, 17 Sep 2017 08:13:43 +0000, Scott Bennett wrote: ...

...

connections to other relays somewhere, those of us using packet filters could include the rest of the missing addresses in aid of the connectivity you want.

I really don't see what the point is in this filtering. Any attacker can just fire up its own relay and attack from there once its address in the consensus.

Attackers/probers, at least of my system, do not appear to be aware of tor, or of most other applications, for that matter. They assault mainly any open ports they find. The IP addresses from which such attacks connect are either direct attackers or are systems whose security is inadequately attended to and have been commandeered by attackers. The purpose of the filter rules is to deny the attackers access to *anything* on my system to the degree to which they can be identified. The source IP addresses belonging to tor relays are a special case because attacks might exit through them or might be running on those systems, but tor connectivity must be maintained. So the rules are a compromise. They allow inbound connections only to the ORPort and the DirPort from all addresses known to belong to tor relays in order to maintain that connectivity. Any such attacks on the ORPort or DirPort from those addresses are a) likely to be rare, if only because the time delays in going through tor to attack tor (or anything else) slow the attacker's automation to a degree usually not accepted by the attacker's software and b) also rare because the tor relay operator community tends to be significantly more security-conscious than the vastly broader community of Internet users at large and are therefore far less likely to allow stuff on their systems running relays to engage in such attacks in the first place. Addresses in the list of offending addresses that are not also in the list of tor relay addresses are blocked from attacking tor or any other services on my system. The problem here stems from allowing secret addresses to belong to tor relays inasmuch as connections from those secret addresses cannot be protected in the fashion described above. FWIW, I had composed two or three nights ago a fairly detailed response to teor's arguments against what I had previously posted, when my Comcast connection went down several times in rapid succession, destroying my SSH session. Unfortunately, virecover on SDF's servers does not actually produce usable recovery files, so the message, which was almost ready to be sent, was lost. I managed to copy many blocks of text from several pages of the screen buffer into a file on my system, but their order is scrambled. As soon as I can spare the time to reconstruct my arguments and proposed solutions, I will do so, but at the moment I have urgent personal matters to attend to for a few days. 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 * **********************************************************************

Am 17.09.2017 01:56 schrieb Roger Dingledine:

On Sat, Sep 16, 2017 at 11:44:41PM +0000, dawuud wrote:

...

...

Your only option would be to ask your ISP to uncensor the internet, unfortunately. Tor requires that all relays are able to contact all other relays, and those which cannot participate in the network.

I think you meant to say: "Tor requires that all relays are able to contact all directory authorities"

Actually, no, we want it to be the case that all relays can reach all relays. The less true that becomes -- that is, the less clique-like the network topology becomes -- the more complicated the anonymity measurements become, and that is potentially quite bad.

What if the relay operator knows about her connectivity issues / censorship and reflects that in her exit policy? I thought that this would be best practice in such a case, and would not hurt anonymity. (I don't know why :)

...

Tor certainly does NOT require all relays can contact all relays. In fact, the network is *very* partitioned... but as of the past few months I haven't put any energy into proving this; although I do have some mostly finished twisted python code to make all two hop tor circuits and records circuit build failures and circuit build timeouts.

This is a great research area that it would be good to see some attention for.

In particular, if there are specific relays that are doing especially poorly for connectivity, we should work with them to try to get them to fix it, and if it's unfixable, downgrade their weights and/or boot them from the network.

See also https://trac.torproject.org/projects/tor/ticket/12131 ("Measure connectivity patterns between relays") and https://trac.torproject.org/projects/tor/ticket/19068 ("Write and run a clique reachability test")

--Roger

_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

dawuud:

In fact, the network is *very* partitioned... but as of the past few months I haven't put any energy into proving this; although I do have some mostly finished twisted python code to make all two hop tor circuits and records circuit build failures and circuit build timeouts.

teor has a script [1] for this as well (and I'm also interested in this rather important question: How far are we from a complete mesh?) [1] https://github.com/teor2345/onion-graph -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

Thanks for the info, I will ask my ISP. Graeme On 17 September 2017 at 11:23, Sebastian Hahn <mail@sebastianhahn.net> wrote:

Hi there,

...

On 17. Sep 2017, at 01:19, Graeme Neilson <graeme@lolux.net> wrote:

I am running a relay but 4 out of 8 directory authorities appear to being blocked by my ISP. There is no route to the blocked authorities and the last responding tcp traceroute hop is an ISP machine. There are routes via IPv6 though.

Is there anything I can do to get my relay in the consensus?

Your only option would be to ask your ISP to uncensor the internet, unfortunately. Tor requires that all relays are able to contact all other relays, and those which cannot participate in the network.

Sorry I don't have better news, thank you for wanting to help make the Tor network stronger :/

Cheers Sebastian

_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays