<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">(Going back a bit in this thread...)</div><div dir="auto" class=""><br class=""><div class="">On 7 Dec 2017, at 19:56, Scott Bennett <<a href="mailto:bennett@sdf.org" class="">bennett@sdf.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">teor <<a href="mailto:teor2345@gmail.com" class="">teor2345@gmail.com</a>> wrote:</span><br class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On 6 Dec 2017, at 19:13, Scott Bennett <<a href="mailto:bennett@sdf.org" class="">bennett@sdf.org</a>> wrote:</span></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span></blockquote></blockquote><span class=""></span><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">(Snip)</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> A script similar to the one used to reveal and make available the</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">otherwise unidentified source IP addresses of exits could be run by the</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">project to gather the hidden addresses of currently running relays, and</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">a list of such addresses could be made available on a compromise basis,</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">e.g., by having a relay at the project that would serve those lists only</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">over tunneled directory connections *from relays*, were it not for obstinacy.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Such a list could then be included into our packet filters' "free pass"</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">lists without putting the list up on the project's web site like the exit</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">list is.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Outbound addresses aren't secret, because they are used for connections.</span><br class=""></blockquote><span class=""></span><br class=""><span class=""> Roger has claimed here that some of them are indeed secret in the sense</span><br class=""><span class="">that their owners do *not* want them to be published</span></div></blockquote><div class=""><br class=""></div><div class="">Then maybe you should respect their wishes?</div><div class=""><br class=""></div><div class="">Or provide a compelling argument in a proposal that the Tor network and</div><div class="">Tor users will be improved by your proposal.</div><br class=""><blockquote type="cite" class=""><div class=""><span class="">one possible reason for</span><br class=""><span class="">which being that they do not want their relays blocked successfully by</span><br class=""><span class="">governments, e.g., China, Iran. (How hiding the source address of a published</span><br class=""><span class="">relay would evade the Great Firewall escapes me somehow, except perhaps for</span><br class=""><span class="">hidden services based inside China that might be reached via those hidden</span><br class=""><span class="">source addresses.</span></div></blockquote><div class=""><br class=""></div><div class="">That isn't how hidden services work: they connect out to guards.</div><div class="">Only exit and relay to relay connections use relay outbound addresses.</div><br class=""><blockquote type="cite" class=""><div class=""><span class="">Given that most source addresses of relays *are* published,</span><br class=""><span class="">the chances of getting a circuit into China seem rather slim anyway.)</span></div></blockquote><div class=""><br class=""></div><div class="">That's not how relays work, either: they need mutual connectivity.</div><div class=""><br class=""></div><div class="">We typically ask users to configure their clients with bridges or meek in</div><div class="">these countries.</div><div class=""><br class=""></div><div class="">So this could only ever have been about exit connections to websites</div><div class="">in China. And that doesn't make too much sense to me.</div><br class=""><blockquote type="cite" class=""><div class="">(Snip)</div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class="">Anyone is free to volunteer to create and maintain a list of outbound</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">relay addresses. It is technically feasible: </span>it requires a few thousand Tor</blockquote></div></blockquote><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class="">connections per day, one via each relay, to a relay that reports the</span><br class=""></blockquote><span class=""></span><br class=""><span class=""> Ideally, per hour, but that is why it should only be done by one site.</span><br class=""></div></blockquote><div class=""><br class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Scanning every hour increases the cost to the network significantly.</span></div><div class="">Do you really think relays change their outbound addresses that often?</div><div class=""><br class=""></div><div class="">I would also encourage you to work out how much relay capacity this costs</div><div class="">the network, and develop a plan to provide at least that much.</div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">A cost-benefit analysis would be an important part of the proposal.</span></div><div class=""><br class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">If you don't want to do this, use 24 hours, which is the exitmap interval.</span></div><br class=""><blockquote type="cite" class=""><div class=""><span class="">Note that Exit relays might be skippable because their outbound addresses</span><br class=""><span class="">are already identified by one site, namely, the tor project, and published.</span><br class=""><span class="">IOW, only entry/middle and non-Exit exit nodes need be tested, which would</span><br class=""><span class="">shrink the list by several hundred to a thousand or so.</span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">There are separate OutboundBindAddressOR and OutboundBindAddressExit</div><div class="">torrc options. This means that connections to relays and connections to</div><div class="">websites may come from different addresses.</div><div class="">(My relays are set up like this - it allows the provider to null-route exit DoS</div><div class="">attacks, with less disruption to users.)</div><div class=""><br class=""></div><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Here's an alternative scheme:</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Run a relay that attempts to maintain an inbound connection from each</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">other relay.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Each hour, report the last address seen on the last inbound </span><span style="background-color: rgba(255, 255, 255, 0);" class="">connection</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">from </span><span style="background-color: rgba(255, 255, 255, 0);" class="">each other relay, whether that connection is still active or not.</span></div></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Each hour, try to re-establish inbound connections from each other relay.</span></div><div class=""><br class=""></div><div class="">Here's why this works:</div><div class=""><br class=""></div><div class="">As long as the original TCP connection stays up, the relay has the same</div><div class="">outbound address.</div><div class="">Whenever the connection breaks, it is possible that the outbound address</div><div class="">has changed.</div><div class="">Rate-limiting reconnection attempts decreases network load.</div><div class=""><br class=""></div><div class="">(Snip)</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="">It just needs to be done safely, in a way that doesn't collect client</blockquote><blockquote type="cite" class=""><span class="">addresses, and avoids attaching a timestamp or order to relay connections.</span><br class=""></blockquote><span class=""></span><br class=""><span class=""> Why would client addresses ever be involved? What would be gathered</span><br class=""><span class="">are the addresses from which *relays* connect to other relays (N.B. *not* to</span><br class=""><span class="">destinations).</span></div></blockquote><div class=""><br class=""></div><div class="">You could easily collect and publish client and bridge addresses if you run a</div><div class="">relay and dump all inbound connections. You need to understand the</div><div class="">difference between inbound client, bridge, and relay connections.</div><div class=""><br class=""></div><div class="">Relays authenticate, clients and bridges don't.</div><div class=""><br class=""></div><div class="">It's not sufficient to rely on (not having) the Guard flag, because:</div><div class="">* bridge clients use the bridge as their Guard</div><div class="">* most current Tor versions have a bug that assigns a non-zero probability</div><div class=""> to excluded relay flags</div><div class="">* some clients don't use Guards</div><br class=""><blockquote type="cite" class=""><div class=""><span class="">The only timestamps that I see might be relevant would be</span><br class=""><span class="">the starting and ending times for each script run, so that an administrator's</span><br class=""><span class="">own script(s) for incorporating those addresses into his "free pass" list</span><br class=""><span class="">might easily discern out-of-date script output files from current script</span><br class=""><span class="">output files.</span></div></blockquote><div class=""><br class=""></div><div class="">You will need to sort outputs to destroy order.</div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">(Snip)</blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Here's how someone could work on this feature:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Create a scanner, publish a list, and show that it has value.</span><br class=""></blockquote><span class=""></span><br class=""><span class=""> Because such a list would include addresses whose owners might not be</span><br class=""><span class="">pleased about those addresses being published (see above), such a list</span><br class=""><span class="">should *not* be published, but perhaps could be sent to someone in the tor</span><br class=""><span class="">project.</span></div></blockquote><div class=""><br class=""></div><div class="">I personally would not handle a list created against the wishes of a group of</div><div class="">relay operators.</div><br class=""><blockquote type="cite" class=""><div class=""><span class="">Better still, the generating script could be sent to someone in</span><br class=""><span class="">the tor project to enable the project to run the script, rather than</span><br class=""><span class="">encouraging many relay operators all to duplicate the network load of</span><br class=""><span class="">running it.</span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">I don't know if anyone would expend resources on this.</div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class="">Or start with a proposal, ask for advice, then create the scanner.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class="">(Snip)</blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">And try to have list downloads rely on existing Tor features, like onion</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">services. They'll be faster to deploy that way.</span><br class=""></blockquote><span class=""></span><br class=""><span class=""> AFAIK, tor has no such feature. If a relay is to download nothing more</span><br class=""><span class="">than a file of IP addresses, which feature are you suggesting will do that</span><br class=""><span class="">upon demand by a relay (and only an identified relay)?</span></div></blockquote><div class=""><br class=""></div><div class="">Tor relays submit signed descriptors.</div><div class="">But there is no feature in Tor that only answers signed requests.</div><div class="">That would require another proposal.</div><div class=""><br class=""></div><div class="">But relay keys are public, so you could create a server that only accepts</div><div class="">signed relay requests. And a client that signs requests using relay private</div><div class="">keys. Signing requests with relay private keys introduces potential security</div><div class="">holes, so I don't know how many operators would run a client like this.</div><div class="">(A better design would be to include another signing key in relay</div><div class="">descriptors, cross-certify it, and use that for requests.)</div><div class=""><br class=""></div><div class="">Then you could run the server as an onion service, which provides</div><div class="">authentication of the server.</div><div class=""><br class=""></div><div class="">This looks like a lot of work, and cryptography is notoriously hard to get</div><div class="">right.</div><br class=""><blockquote type="cite" class=""><div class=""><span class="">Yes, a relay can ask</span><br class=""><span class="">for a directory download (and so can a client). Yes, a relay can ask for a</span><br class=""><span class="">directory update download (and so can a client). Yes, a relay can ask for</span><br class=""><span class="">ExtraInfo document downloads. How does a relay ask to download a kind of</span><br class=""><span class="">file that doesn't yet exist? Is there already some undocumented, generic</span><br class=""><span class="">feature that a identified relay (but nothing else) can ask a directory mirror</span><br class=""><span class="">or authority to "give me your latest version of file x"?</span><br class=""><span class=""> If you mean that the downloading process could be spun off to a worker</span><br class=""><span class="">thread, then yes, of course, it should be, but the actual implementation in</span><br class=""><span class="">tor would be up to the tor developers, not to me.</span></div></blockquote><div class=""><br class=""></div><div class="">We accept patches, that's how people become tor developers.</div><div class=""><br class=""></div><div class="">But I'm not sure if we would merge a patch over the objections of a group</div><div class="">of existing relay operators.</div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class=""></span></blockquote><blockquote type="cite" class=""><span class="">Here's a description of the proposal process:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt" class="">https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt</a></span></blockquote></div></blockquote><div class=""><br class=""></div><div class="">I think we've reached the point in this discussion where we need to move to</div><div class="">something more structured than email.</div><div class=""><br class=""></div><div class="">If you want to make this happen, and are willing to put some work in, write a</div><div class="">proposal.</div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">(Snip)</blockquote></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">You will also see your</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Fast and HSDir flags come and go at random, depending upon how many</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">authorities creating testing circuits to reach and test your node(s)</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">go through a node that used a hidden outbound address as the source</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">address that fails your filter to connect to your node.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">If you set the connection limit at or above 512 connections per /24, it will</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">be impossible for well-behaved consensus relays to go above the limit:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">2 relays per IPv4 * 256 IPv4 addresses per /24 = 512 connections</span><br class=""></blockquote><span class=""></span><br class=""><span class=""> Apparently, the aforementioned effort to limit each relay pair to a</span><br class=""><span class="">single connection does not apply to hidden service connections, as can be</span><br class=""><span class="">readily seen on a Fast HSDir relay when bursts of connections occur.</span></div></blockquote><div class=""><br class=""></div><div class="">There are multiple resource limits in Tor.</div><div class="">Are you sure it's the connection limit that's being hit?</div><div class="">We often see bandwidth and circuit limits being hit in these cases.</div><br class=""><blockquote type="cite" class="">(Snip)<br class=""></blockquote><blockquote type="cite" class=""><div class=""><span class=""> My relay is a relatively</span><br class=""><span class="">low-capacity relay, yet when it has the Fast flag, and especially with an</span><br class=""><span class="">additional HSDir flag, it often has several thousand connections at any</span><br class=""><span class="">given time.</span></div></blockquote><div class=""><br class=""></div><div class="">There are several thousand relays, so several thousand connections is normal.</div><div class="">And an additional few thousand client or many thousand exit connections is</div><div class="">also normal.</div><br class=""><blockquote type="cite" class=""><div class=""><font color="#00afcd" class="">(Snip)</font></div></blockquote><br class=""><div class="">T</div></div></body></html>