Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[nusenu]

> 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.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[tor-server-creator]

If someone really wants to help the network she would set MyFamily 
config and/or answer requests. btw i would be happy to not see this 
topic on broader public like TWN

 

 

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".
 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[Roger Dingledine]

On Sun, Nov 01, 2015 at 05:41:44PM +, n...@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

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

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[nusenu]

> 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

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[tor-server-creator]

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

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

 

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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[n...@cock.li]

tor-server-crea...@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.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[Tom van der Woerdt]

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

tor-server-crea...@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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[Green Dream]

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


Is there somewhere we can follow the conversation and decisions of the
authorities when there are incidents like this? IRC? Another mailing list?
As an operator, I would appreciate more transparency into how
this "open" network is administered.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[n...@cock.li]

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. 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)
Though, they could have already set up a number of guards prior to this
that may not be obviously linkable to the same entity.
Assuming this is not the case, for now they just have a better advantage
at sniffing/injecting as an exit, but you should already be (trying to)
use encryption as much as possible.

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.

So, If you're a relay, you shouldn't bother trying to filter these, the
Authorities should figure it out.
If you're a client, I guess that's up to you, there might not be a whole
lot of benefit if you do.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30

[nusenu]

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)





signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays