Opened 5 years ago

Last modified 2 years ago

#13705 new enhancement

Allow relays to promise in their descriptor that their IP address won't change

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay, needs-proposal, theft-resistance, intro
Cc: Actual Points:
Parent ID: Points: 5
Reviewer: Sponsor:

Description

Imagine the following scenario: Oscar runs a fast relay that gets the Guard flag and accumulates some users, including a user Alice. Then some attacker does a guard enumeration attack to identify that his victim is using Oscar's relay as her guard. He can get a warrant to collect Oscar's computer, but for whatever reason he's not allowed to tap the relay in-place. So he steals the computer, takes it to his location, turns it back on, and the relay starts up again. Alice then says "oh good, my guard is back online" and moves back to using it.

One straightforward option to reduce the risk of this scenario happening in practice is for relays that intend to have a static IP address to set a line in their descriptor that tells the directory authorities to refuse them if they show up from a different IP address. The implementation on the directory authority side would be to add the IP address to fingerprint mapping to the router-stability file or equivalent, and then check whether there's a mapping when considering newly published descriptors.

This idea wouldn't handle the attack when done on relays with dynamic or varying IP addresses.

Another avenue for addressing the attack is the encrypted identity key proposal and friends. I'm not sure if they handle this issue, or are orthogonal, or would supersede this idea.

Child Tickets

Change History (15)

comment:1 Changed 5 years ago by arma

Andrea points out that if directory authorities keep this mapping forever, it will just grow and grow. Whereas if they don't keep it forever, they're opening clients up to this risk.

Maybe we should keep a last-seen timestamp, and we can discard the mapping if it hasn't been seen in so long that clients should have discarded it from their guard list anyway?

comment:2 Changed 5 years ago by Sebastian

Or we re-evaluate what the whole idea buys us. Can't police just force the hoster to forward IP traffic, and nobody wins anything from the added complexity?

comment:3 Changed 5 years ago by bastik

How would Oscar tell the authorities about an IP address change? Maybe due to a contract change or maybe the ISP disables IPv4 and Oscar get a new IPv6 address. I don't expect this to be the case very often, but there has to be a way to handle it.

How much of a risk is the above scenario compared to getting a warrant to force the ISP to mirror the traffic of the relay? Wiretapping without Oscar even knowing.

comment:4 in reply to:  3 ; Changed 5 years ago by Sebastian

Replying to bastik:

How would Oscar tell the authorities about an IP address change? Maybe due to a contract change or maybe the ISP disables IPv4 and Oscar get a new IPv6 address. I don't expect this to be the case very often, but there has to be a way to handle it.

That part's easy, make a new key.

comment:5 in reply to:  4 Changed 5 years ago by bastik

Replying to Sebastian:

Replying to bastik:

How would Oscar tell the authorities about an IP address change?

That part's easy, make a new key.

Unless I'm mistaking this would make it a "new" relay, which has to go through the life-cycle before being as useful as it was before. Anyway, the question if it is worth it is much more on-topic for this ticket. If it's not worth it... then there is no need to worry about what it entails.

comment:6 in reply to:  4 Changed 5 years ago by arma

Replying to Sebastian:

Replying to bastik:

How would Oscar tell the authorities about an IP address change?

That part's easy, make a new key.

Right. And the relay operator should only enable this feature when they expect their IP address to be 'sufficiently' stable.

Moving to a new identity key isn't so bad, especially when running a running a big stable relay, compared to the risk of somebody grabbing and misusing your key.

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

Replying to Sebastian:

Or we re-evaluate what the whole idea buys us. Can't police just force the hoster to forward IP traffic, and nobody wins anything from the added complexity?

I think I can paraphrase this as "but what about this other type of attacker, which wouldn't be addressed by the proposed defense". That by itself isn't a reason to do it.

But you are right to wonder if the attack that I describe is sufficiently common / plausible / likely to warrant the added complexity.

comment:8 Changed 5 years ago by teor

Does this need to be in 0.2.6? Is it a current attack?

comment:9 Changed 5 years ago by teor

Keywords: needs-proposal added
Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

comment:10 Changed 5 years ago by teor

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

comment:11 Changed 4 years ago by teor

Severity: Normal

(If we get this implemented and widely adopted, it would be a useful extra filter for fallback directory candidates.)

comment:12 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:13 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:14 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:15 Changed 2 years ago by nickm

Keywords: theft-resistance intro added
Points: 5
Note: See TracTickets for help on using tickets.