[tor-dev] monitoring significant drops of flags in dirauth votes

[nusenu]

Damian Johnson:
>> thanks for implementing the new check so fast.
> 
> No problem! Thanks for suggesting it.
> 
>> This is also very useful but slightly different from what I had in mind,
>> because it would not trigger if dirauths upgrade from A to B in the
>> same hour and most exits, guards or hsdirs are gone due to a bug in version B.
> 
> This should catch a bug with B unless every authority upgrades to B in
> the same hour. Otherwise we'd get an alert - either because the
> majority is B and the remaining A votes are out of band, or the
> consensus is made with A and authorities that upgraded to B are
> different.
> 
> Is there another check in particular that you'd like?

Yes, but not directly related to this thread. I will file it via trac.tpo.

> One gotcha is
> that checks that require state (such as comparing with the last hour's
> consensus) is a bit more work.

Yes, that is what I was wondering if DocTor keeps any state at all already.

>> I tried to find something related to this in the 0.3.3.x changelogs
>> because moria1 (the affected dirauth) is the only one running tor alpha
>> but I didn't find anything related to a change in what is required
>> to earn the HSDir flag. Has there been any change related to how
>> HSDir is assigned that would explain that significant difference?
> 
> For what it's worth I started with alarming when authorities differed
> more than 20% from the consensus but it was a bit noisier...
> 
> [consensus-health] NOTICE: longclaw had 3100 HSDir flags in its vote
> but the consensus had 2583
> [consensus-health] NOTICE: moria1 had 756 HSDir flags in its vote but
> the consensus had 2583
> [consensus-health] NOTICE: moria1 had 1397 Guard flags in its vote but
> the consensus had 1761

I assume this has not been deployed - 50% or maybe 40% are fine I guess. 
To come up with good threshold values
one would need to look at historic data for the past few months.



-- 
https://mastodon.social/@nusenu
twitter: @nusenu_

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180212/2859077d/attachment.sig>