Opened 7 years ago

Closed 7 years ago

#6133 closed enhancement (worksforme)

bwauths need to let us know when they've been running long enough

Reported by: arma Owned by: aagbsn
Priority: Medium Milestone:
Component: Core Tor/Torflow Version:
Severity: Keywords:
Cc: mikeperry Actual Points:
Parent ID: #2286 Points:
Reviewer: Sponsor:

Description

With #2286, if any three directory authorities vote one Measured line, potentially all the relays will get capped to some small constant weight.

So the bwauths need to let the directory authority know when they have 'enough' measurements, so the directory authority can only admit to having Measured lines when it has enough.

But the threshold shouldn't just be a simple fraction of relays, since then an adversary can flood the network with new relays to drive down the fraction and put us under the threshold.

One simple answer is to pick some parameter n where n is enough days for us to comfortably measure most relays, and output a bit "have we been running for most of the last n days or not".

We could put that bit into the V3BandwidthsFile file and have Tor read it. Or we could look at the bit ourselves and not update the V3BandwidthsFile file until the bit is true. Or some other smart thing. Whatever is easiest from bwauth's side.

Child Tickets

Change History (5)

comment:1 Changed 7 years ago by mikeperry

We have a timestamp at the top of the file already. The time value there is the measurement timestamp of the most recently measured relay. The authorities ignore the file if the timestamp is more than 3 days old.

Not exactly what you want, I guess, but also note that the bandwidth authorities also don't output a measurements file in the first place if they don't have measurements for some percentage of the current consensus (MIN_REPORT = 60 in aggregate.py).

Are these two enough? Should we tweak these parameters?

comment:2 in reply to:  1 ; Changed 7 years ago by arma

Replying to mikeperry:

We have a timestamp at the top of the file already. The time value there is the measurement timestamp of the most recently measured relay. The authorities ignore the file if the timestamp is more than 3 days old.

Not exactly what you want, I guess, but also note that the bandwidth authorities also don't output a measurements file in the first place if they don't have measurements for some percentage of the current consensus (MIN_REPORT = 60 in aggregate.py).

Are these two enough? Should we tweak these parameters?

Sounds like we want slightly different behavior. For example, if the bandwidths file was last written within 3 days ago, but bwauth decides it's not comfortable providing opinions right now, does that mean the dir auths use the old opinions? I think it does, and if bwauth isn't comfortable because it doesn't feel it has enough opinions, then using the outdated opinions for days is probably even worse.

Also, it looks like we *are* vulnerable currently to the "flood the network with new relays so the bwauths will all stop providing Measured opinions" attack.

I can see the ">=60% threshold" being there as a defense mechanism against a bug. But ultimately we should try to get rid of it I think.

comment:3 in reply to:  2 Changed 7 years ago by arma

Replying to arma:

Sounds like we want slightly different behavior. For example, if the bandwidths file was last written within 3 days ago, but bwauth decides it's not comfortable providing opinions right now, does that mean the dir auths use the old opinions? I think it does, and if bwauth isn't comfortable because it doesn't feel it has enough opinions, then using the outdated opinions for days is probably even worse.

How about if the bwauth clobbers the output file if it's running but doesn't think it has enough opinions for this round?

I guess that might mess up the cron jobs that check if bwauth is on track. But it would accomplish the goal here?

comment:4 Changed 7 years ago by arma

This ticket and #6131 are holding up the #2286 merge, which fixes arguably a pretty big security vulnerability. At this point I am happy with any sort of kludge here.

comment:5 Changed 7 years ago by arma

Resolution: worksforme
Status: newclosed

Ok. I opened #6800 for the "but the bad guy could flood us with relays" concern, since that isn't this ticket.

I believe that means we are good to go at closing this ticket -- the bwauths already do let us know when they've got enough recent opinions, by only writing an opinion file when they have enough, and by putting a timestamp in it which the dir auths already honor.

I'm going to close this ticket then. Reopen if I got something wrong.

Note: See TracTickets for help on using tickets.