should relays add some lines to torrc like reject *.fingerprint?

Am Sonntag, 1. November 2015 12:58 schrieb nusenu nusenu@openmailbox.org:

...

Here is the OrNetRadar email for that event including all FPs in the last line:

http://article.gmane.org/gmane.network.onion-routing.ornetradar/433

http://bgp.he.net/AS29119

(added the address provided in the contactinfo field to the recipients of this email)

• 11 relays on 2015-10-31 (in a new /16 network block)

total "11BX1371" relays: 142 relays

Now clients might choose more than one relay of that group to create a given circuit (no family set, non-exit + exit relays and more than one /16 network). _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Op 01/11/15 om 18:22 schreef ncl@cock.li:

tor-server-creator@use.startmail.com:

...

should relays add some lines to torrc like reject *.fingerprint?

The authorities should be rejecting the relays / dropping their traffic soon, I assume now they're trying to contact the operator before doing that.

On another note, reject allows cidr notation, so something like ExcludeNodes 185.99.184.0/22,185.45.72.0/23 should work.

Should they actually be blocked though?

I mean, it's a lot of relays, but they're also contributing actual exit bandwidth and it's not like they're spread over hundreds of /16s.

Maybe this calls for some dirauth-level patches to throttle families of servers to a certain CW?

Tom

On Sun, Nov 01, 2015 at 05:41:44PM +0000, ncl@cock.li wrote:

Tom van der Woerdt:

...

Should they actually be blocked though?

I mean, it's a lot of relays, but they're also contributing actual exit bandwidth and it's not like they're spread over hundreds of /16s.

I was just about to write a bit of clarification actually: They shouldn't be in a position to be able to really de-anon anyone via sybil, the oldest relays seem to be 3 days old, so there's still at least another 4 until they can get Guard, and that will still take a while to get users on it.

Correct. Actually, it takes 3 or so days before the bandwidth authorities will assign you a weight -- so for pretty much the whole lifetime of these relays, they had a weight of "w Bandwidth=20 Unmeasured=1" -- meaning that while they may have had 'actual exit bandwidth' to contribute, clients weren't actually taking them up on it.

I sent mail to the operator a few days ago to ask what's up, but I haven't heard an answer. It looks like it was another of those stupid Internet puzzles, where somehow the set of relays they set up was a hint in the puzzle. Around today was when they started getting measurements from the bwauths, and coincidentally a few hours ago was when we finally got the deciding vote from the dir auth operators to bump the sybil relays out of the network.

Not to mention tor doesn't build circuits with more than one node on the same /16 (although now this batch has taken on another range)

There were a bunch of them running in 185.45.72.0/24 and 185.45.73.0/24, but strangely, nearly all of them were short-lived. That is, they were around long enough to start getting measurements, but then they went away on their own. We'll see if they try to come back.

Though, they could have already set up a number of guards prior to this that may not be obviously linkable to the same entity.

Yes, this is exactly the reason to take action on them rather than waiting until they get their Guard flag to become worried.

With intentions and scenarios unknown, it could also be someone who wants to help, there /was/ a call for exits not too long ago, after all.

Yes, also agreed. This is a sad downside to our current "open network" model. We want to grow, but not too much from any one direction, and this necessarily balances "make sure to keep out the super-obvious attackers, even though many of them are probably honest people" with "grow the network as large as possible, so we can be robust against more subtle attackers".

--Roger

Should they actually be blocked though?

I mean, it's a lot of relays, but they're also contributing actual exit bandwidth and it's not like they're spread over hundreds of /16s.

Maybe this calls for some dirauth-level patches to throttle families of servers to a certain CW?

I would vote for dirauth enforced families. Dirauths could put such relays into a family that has been defined by the dirauths, so that clients won't use more than one relay of that group.