Opened 3 years ago

Last modified 3 years ago

#22308 new enhancement

Consider resetting wfu/mtbf/tk values for relays when they switch IP addresses

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 032-unreached
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


The proposal would be to track the IP address of each relay in the router-stability file, and when the IP address changes for a given relay identity, start fresh on tracking the weighted-fractional-uptime, mean-time-between-failure, and time-known.

The benefit is that if some bad person seizes a relay and gets the identity key, then puts that identity key online somewhere else, clients won't immediately resume using it as their guard. We would have at least a week to notice that it's back. This feature in turn would make it less critical to blacklist identity fingerprints of seized relays, e.g.

The drawback is that we make less good use of relays on dynamic IP addresses, since they will spend a lot of their time not having the Guard or Stable flags.

Note that this change wouldn't impact the bandwidth authority numbers, so it wouldn't make relays need to wait until the bwauths have measured them before getting traffic again.

Child Tickets

#22309taskclosedmetrics-teamHow many relays change IP addresses a lot and also get the Guard flag?

Change History (7)

comment:1 Changed 3 years ago by arma

I think the benefit is clear, but the cost is less clear. How many relays do we have now that are on dynamic IP addresses and also get the Guard flag?

This part sounds like a job for the metrics team! :) I have opened #22309.

comment:2 Changed 3 years ago by arma

Depending on the complexity of the analysis, we might need a proposal here.

comment:3 Changed 3 years ago by arma

cypherpunks replied to this ticket on #22309, but I am answering here so things don't get confused.

Replying to cypherpunks:

I hope you are not punishing guards for changing their IP by reseting their reputation

That is indeed the question at hand.

  • attackers can keep the same IP address (making this safeguard ineffective)

Well, sometimes attackers could, but also sometimes they couldn't. For example, if the cops seize a relay, they're going to have a tougher time putting it back online at the place they took it from.

  • this would negate the protection operators get by running in OfflineMasterKey mode

Tell me more about this one? I'm guessing you won't be happy with "if they need to get the offline master, maybe they can keep using the same IP address" or "maybe resetting the reputation is an acceptable loss, since it won't happen all that often"?

comment:4 Changed 3 years ago by cypherpunks

As I understand the recovery time is 7 days? (not 3 months as I thought before), so it is fine if you accept the fact that you will potentially lose guard capacity.

A guard currently changing its IP ~4 time a month will practically no longer be a guard after this is implemented. A guard changing its IP twice a month will be a guard only for 1/2 of the month.

comment:5 Changed 3 years ago by arma

Right, a relay needs to be (among other things) in the top half of relays by time-known, or they automatically qualify wrt time-known if their value is at least 8 days. But, it isn't *really* 8 days, because the time-known value for each relay decays over time. The comment next to it in the code says it's around 20 days, but I think that's probably wrong.

You can see the various thresholds that each directory authority is using, from the flag-thresholds lines in their votes:

There is some debugging of the time-known tracking in #19162, but I think it's safe to say there are some dragons there. But bigger picture, yes, it's a matter of days, not months.

comment:6 Changed 3 years ago by arma

In summary from #22309, most relays that get the Guard flag keep their same IP address for many many weeks.

So the downside of doing this change is low, and the upside is also low except in the case where somebody steals a guard key and tries to put it online somewhere else, and then we'll wish we'd implemented this ticket.

comment:7 Changed 3 years ago by nickm

Keywords: 032-unreached added
Milestone: Tor: 0.3.2.x-finalTor: unspecified

Move some 0.3.2 items (fewer than I had expected for now) into Unspecified.

Note: See TracTickets for help on using tickets.