You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can monitor BW events in bandguard and emit messages if there's a spike over an hour period in the past X hours, or the past day in the past Y days.
This is a tricky thing to do, as spikes are relative to both activity on the service, as well as activity in the Guard's extra-info. We should look at the slowest Guard relay and try to decide thresh holds from there.
The hour resolution is relevant to netflow logging attacks, and the day resolution is relevant to https://metrics.torproject.org attacks.
The text was updated successfully, but these errors were encountered:
This is looking like we don't have enough CONN_BW event info to do properly. It gives a connection ID and no fingerprint. GETINFO orconn-status only gives fingerprints and no ID.
So if vanguards attaches after the orconns are made by Tor, it will have no idea what is used where. Worse, it can't tell if they are guard or relay connections..
I think we need to wait on this and fix the tor-side when we add the fields for #74
We can monitor BW events in bandguard and emit messages if there's a spike over an hour period in the past X hours, or the past day in the past Y days.
This is a tricky thing to do, as spikes are relative to both activity on the service, as well as activity in the Guard's extra-info. We should look at the slowest Guard relay and try to decide thresh holds from there.
The hour resolution is relevant to netflow logging attacks, and the day resolution is relevant to https://metrics.torproject.org attacks.
The text was updated successfully, but these errors were encountered: