- tor-relays - lists.torproject.org

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Welcome. This event led to my discovering the Unmeasured=1 flag in the cached-*consensus files (was wondering where it was). That new BWauth is badly needed. See about 460 unmeasured relays and from an unscientific sample it seems like many of them are stuck-at-20 exit nodes--valuable resources that should be utilized. At 15:17 7/30/2015 -0500, you wrote: >On 30 July 2015 at 12:14, Tom Ritter <tom(a)ritter.vg> wrote: >> Thanks for the heads up! >> >> A fifth bwauth is expected to start >> voting "real soon now", and I'm >> not sure why maatuska didn't vote >> on bwauth data last vote, but I've >> pinged some folks so hopefully we >> can get this resolved quickly. > >Aaaand we're back! =) Sorry for the outage. > >Bandwidth scanner status > >maatuska 6890 Measured values in w lines >gabelmoo 6444 Measured values in w lines >moria1 6754 Measured values in w lines > >-tom

1 0

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Much of Tor traffic is from long-term circuits moving bulk data, so apparently it will take many hours or even days for rebalancing to fully take effect. Is not clear whether it will cause serious trouble or not. My thought is that one BWauth in a consensus is better than self-measure, as BWauths are trusted entities and a single rouge BWauth in some kind of attack taking out the rest would be dealt with via manual intervention or the closing down of Tor. Perhaps the self-measure cap of 10k should be raised as well. Was an anti-gaming mitigation from the pre- BWauth days and may have even preceded the arrival of super-fast relays. At 12:14 7/30/2015 -0500, you wrote: >Thanks for the heads up! > >A fifth bwauth is expected to start voting "real >soon now", and I'm not sure why maatuska didn't >vote on bwauth data last vote, but I've pinged >some folks so hopefully we can get this resolved >quickly. > >-tom > >On 30 July 2015 at 12:04, <starlight.2015q2(a)binnacle.cx> wrote: >> FYI list >> >> https://trac.torproject.org/projects/tor/ticket/16696 >> >> Description >> >> At present both 'longclaw' and 'maatuska' have >> dropped out of the BW consensus ('longclaw' >> is restarting with new version, not sure >> about 'maatuska'). >> >> This has caused the BW consensus logic to revert >> to using relay self-measurement for BW weightings >> due to fewer than three BW authorities participating. >> >> The 10000 cap placed on self-measure values >> is causing super-fast relays serious demotion >> and slower relays corresponding promotion >> in the consensus weighting. >> >> Possibly this may result in network >> unbalance issues. Some adjustment >> of the logic seems in order. >>

1 0

Giving away some "pre-warmed" relay keys for adoption
by Roman Mamedov 29 Jul '15

29 Jul '15

Hello, If anyone is planning to spin up a new VM or dedi to run a Tor relay and want it to be put instantly into good use (without wasting couple of weeks to a month for the whole "unmeasured relay/measured/guard/stable" cycle to complete) or if you are having trouble with your current relay being measured properly, in a few days I'm considering to give away several fingerprints+keys from my relays that I will be shutting down. If you install Tor on a new machine and unpack one of these into your /var/lib/tor, it starts up something like this (see below); i.e. in a couple of hours to a full 100% utilization. eth0 16:59 ^ t | t t rt rt rt rt | rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt -+---------------------------------------------------------------------------> | 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) 17 0 0 01 0 0 09 34135840 34964598 18 0 0 02 0 0 10 37991652 38890814 19 0 0 03 0 0 11 38710878 39749495 20 0 0 04 0 0 12 39168357 40164982 21 0 0 05 50433 1472 13 42351426 43626118 22 0 0 06 10904079 10927593 14 42826283 43928095 23 0 0 07 15691530 15839439 15 41240931 42507372 00 0 0 08 27079433 27403035 16 41941981 43139517 Drop me an E-Mail if you want one of these (probably about 2-3 available for now). -- With respect, Roman

8 14

Re: [tor-relays] pinning relay keys to IPs (or not)
by starlight.2015q2＠binnacle.cx 29 Jul '15

29 Jul '15

>(where a lot of IPs changed their AS from >IANA to Digital Ocean) A couple of minor notes regarding ASNs: 1) many IPs fall under a hierarchy of ASs where a large core-network provider (e.g. Level3) advertises a block and a second client leaf-AS advertises a sub- block. Sometimes the core AS advertises the smaller blocks though that has diminished with the CIDR route consolidation initiative. Also some ASs advertise bocks and sub-blocks. This shows up often with the CYMRU lookup data dig +short D.C.B.A.origin.asn.cymru.com txt and DNS will rotate the multiple advertisements, so one should sort the list by CIDR size and select the smallest block (i.e. largest CIDR "/" value). Possibly MaxMind takes care of all this in their data. 2) one can likely ignore AS changes when the IP has not changed, thus avoiding problems caused by network restructuring 3) perhaps many dynamic allocations where the IP changes to different AS can be detected by examining the AS owner identifiers and looking for a match I agree guards are special and perhaps should not be allowed to change ASs at all without loosing the flag, maybe even should stay glued to one IP to avoid any failed client connections and the negative impact that may have on anonymity. It seems reasonable to allow dynamic-IP middle and exit relays.

2 2

pinning relay keys to IPs (or not)
by nusenu 29 Jul '15

29 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [split from 'Giving away some "pre-warmed" relay keys for adoption'] > I'm of the opinion that it may be worth adding code to pin relay > identities to IP addresses on the DirAuth side so that consensus > weight and flag assignment gets totally reset if the ORPort IP > changes, but if there's too much churn already it may cause more > trouble than it's worth. I hope such code will not be added, because it renders relays on dynamic IPs basically useless. In the past ~week only there were >1000 fingerprints (<3% cw fraction) using more than one IP address (in that timeframe) > I'm somewhat torn on the whole key pinning thing, because I think > an individual operator moving their relay around is sort of ok > (though in an ideal world the consensus weight should get reset and > rapidly re-measured), but giving away the private component of a > relay's identity key is putting users at risk, and is behavior that > should be discouraged if not outright prohibited if possible (and > key pinning would be a heavy handed way to rule out this sort of > stupidity). -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVtOqsAAoJEFv7XvVCELh0N2oQAJYXVGM0hHJzBl3i7tkfZx8E hEd9PgyX0v+nXnlAU06lsFltK12VaCkXp9Gft8TlmshP6NqsdHk+KPrtumUE7IA4 MmYmmVi5Tb8AyN241nr/RbYOUS+9nz2VvtkhaikkvbFxwzua678I13P1PC/QPki3 S4KwQ0YYYlUrG529GhLaGkm5byX3N+MAdGQn04xzCDzBW/j3GxbZYBj4+tqgHONR 9iAs5/p00MFVGp3Ex8xJKBVRW0NRT//fKRrZtRDBaNxduUg7F0EccO4zlPjTUBAM e+g8tergT4ICixddhRih0iGA3ysw3/mI1KyvOMegZXkUQ0Yo+puR4O7S2w4WoWRh 1tkkbcFWAh4sCKDPLlD/sqWKFDkHLtP3AOG+KGgybkhULNU1GgAftV39QVrsABx/ oP/dhC9d+MablSZg6qS8dxTV3L+E5EdE2RX226+BPjRkUSqphojEYjDpiaR3/COU 2BmACmPIuiS60DfaiqygKQaCwvgDl6q96o5oZEmPHem2SIxh5o3DD1wLJgKKEsiL WgmoRHTLfqc2Uq0442oi7KMhgGcIffS8xKbb1xw/9yIF2WiKrluFFWau5k6cQYA2 0buDAz7WWi7kxUCnn39NcyrtWoOWMziRH+rjv5esoRN7W5k2GNtBcylZ6kyzcudr hy7j6rYMLpUHsVc2NHKd =8W7p -----END PGP SIGNATURE-----

5 9

Very unbalanced in/out connection ratio
by mattia 29 Jul '15

29 Jul '15

Hello, I've been running a middle relay [1] for months and I have always noticed an unbalance between incoming and outgoing connections (monitored through arm). The incoming connections were always in between 0-10% more than the outgoing ones. This morning though the unbalance has reached so far unseen levels: arm reports more than 2500 incoming connections while outgoing are little more than 200. Is this normal and, if so, why? Thank you, Mattia [1] https://globe.torproject.org/#/relay/0D14A4498E7D1854696CC07548653EA4CD3CB2…

2 2

Re: [tor-relays] longclaw BWauth is broken -- no measurements since 7/22
by starlight.2015q2＠binnacle.cx 28 Jul '15

28 Jul '15

Longclaw is broken again. Has not updated 55% of the the relay BS measurments for forty hours. Updated the ticket below with details and raise it to "major" issue. At 16:42 7/25/2015 -0400, you wrote: >Realized not everyone monitors this >list so I opened a Trac ticket: > >https://trac.torproject.org/projects/tor/ticket/16667 > > > >At 11:19 7/25/2015 -0700, you wrote: >>Interesting. Thanks starlight for the head's up! I'm not >>aware of any known issues with longclaw right now >>so looping in its operator. >> >> >>On Sat, Jul 25, 2015 at 10:09 AM, >><starlight.2015q2(a)binnacle.cx> wrote: >>> Subject says it. >>> >>> Thought it was strange that its measurement >>> of my relay has not been moving. Pulled the >>> vote history and grep'ed a dozen relay >>> measurements and none of them have changed. >>>

1 0

pinning relay keys to IPs (or not)
by starlight.2015q2＠binnacle.cx 26 Jul '15

26 Jul '15

Perhaps a way to do it is reset the consensus for a relay if its IP address moves to a different Autonomous System. Is rare that dynamic IP causes relays to hop ASs (e.g. possibly SBC/ATT), and list of exceptions could be created for the few cases where it causes trouble. CYMRU has a dynamic service for looking up AS from IP.

3 2

Re: [tor-relays] longclaw BWauth is broken -- no measurements since 7/22
by starlight.2015q2＠binnacle.cx 25 Jul '15

25 Jul '15

Realized not everyone monitors this list so I opened a Trac ticket: https://trac.torproject.org/projects/tor/ticket/16667 At 11:19 7/25/2015 -0700, you wrote: >Interesting. Thanks starlight for the head's up! I'm not >aware of any known issues with longclaw right now >so looping in its operator. > > >On Sat, Jul 25, 2015 at 10:09 AM, ><starlight.2015q2(a)binnacle.cx> wrote: >> Subject says it. >> >> Thought it was strange that its measurement >> of my relay has not been moving. Pulled the >> vote history and grep'ed a dozen relay >> measurements and none of them have changed. >>

1 0

longclaw BWauth is broken -- no measurements since 7/22
by starlight.2015q2＠binnacle.cx 25 Jul '15

25 Jul '15

Subject says it. Thought it was strange that its measurement of my relay has not been moving. Pulled the vote history and grep'ed a dozen relay measurements and none of them have changed.

2 1