Opened 7 years ago

Last modified 2 years ago

#6790 new enhancement

Write proposal draft for directory mirrors to accept, aggregate and hand off descriptors to dirauths

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, tor-dos-dirauth, tor-dirauth
Cc: Actual Points:
Parent ID: #18346 Points: 3
Reviewer: Sponsor:

Description

In the event of DoS or braindead client behavior, directory authorities may need to rate limit or restrict connections. See #2665.

Under these conditions, it would be useful if directory mirrors could also accept relay descriptor data, aggregate it, and hand it off to the authorities after eliminating duplicates. This coupled with #572 should allow the dirauths to better handle sudden traffic spikes by rate limiting or firewalling, without degrading the network.

https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/147-prevoting-opinions.txt has a related idea, but we may want a push method rather than a pull?

Child Tickets

Change History (25)

comment:1 Changed 7 years ago by mikeperry

Other thoughts: The aggreation/de-dupping step should also include the usual orport tests done by the dirauths themselves, to reduce the burden on the dirauths.

The other reason to prefer a push method is that we could simply re-use the dirauth code that accepts descriptors currently, but relax it to allow descriptors to come from any valid dir mirror currently listed in the consensus.

If misbehaving dir mirrors begin participating in the DoS by submitting unreachable or otherwise bogus unverified descriptors, they could be added to the firewall or to de-listed in approved-routers in an ad-hoc fashion by the dirauth operator.

It may also be the case that this would also allow misbehaving dir mirrors to induce a form of portscan bounce through the dirauths by spoofing descriptors, but the existing two-descriptor-per-IP limits should mitigate that, I think.

comment:2 Changed 7 years ago by mikeperry

Milestone: Tor: 0.2.4.x-final

I guess I'll set the milestone on this to remind me to wrap this up into a proposal of some kind.

comment:3 Changed 7 years ago by mikeperry

Keywords: MikePerry201210 added
Summary: Directory mirrors should accept, aggregate and hand off descriptors to dirauthsWrite proposal draft for directory mirrors to accept, aggregate and hand off descriptors to dirauths

Apparently the proposal deadline is Oct 10th. I guess I'll just remake this ticket into the proposal ticket, since it will likely be filled with proposal ramblings and ideas that end up getting altered.

comment:4 Changed 7 years ago by nickm

Hm. My first thought here would be, could authorities just have a second dirport that's only used for uploading stuff?

comment:5 Changed 7 years ago by mikeperry

Keywords: proposal-needed added

comment:6 Changed 7 years ago by ioerror

Doesn't this effectively turn the entire Tor network into a remote probing system as long as someone can get a descriptor into the network?

comment:7 in reply to:  4 Changed 7 years ago by Sebastian

Replying to nickm:

Hm. My first thought here would be, could authorities just have a second dirport that's only used for uploading stuff?

The only real issue here is communication with the other directory authorities when it comes to voting, having your own port for that and making sure traffic for that is always of higher priority than anything else seems like it could solve this quite handily

comment:8 Changed 7 years ago by mikeperry

Sebastian,nickm: Actually, as I see it the root issue is eliminating dirauths as a (collective) single points of failure in terms of capacity. Having a separate port for descriptor submission from the whole Internet does not fix this.

In an ideal world, each dirauth should not need more than a cell phone's worth of uplink flying around on a quadrocopter somewhere. It's fine to have this centralization exist for consensus reasons, but it should not be exposed for anything else. That's just dangerous. I mean, how many times do we have to shoot *ourselves* in the head before we realize someone else can do it, too?

ioerror: Can you explain the backchannel that the adversary uses to get the result back in what I describe in comment 1? Or better put: What is the adversary's goal with such probes?

comment:9 Changed 7 years ago by Sebastian

The dirauths need to do reachability testing etc. Whether they're used to actually distribute the consensus to bootstrapping clients and the rest of the network is highly orthogonal I think. I don't agree with your most of your plans here on this ticket, I think, because you do not address this issue. Publication to the dirauths has never been the problem.

comment:10 Changed 7 years ago by mikeperry

I don't agree that because something has never been a problem that it can never be a DoS vector. This ticket is about a DoS defense.

Can you explain other attack vectors through reachability testing that aren't addressed in comment 1?

comment:11 Changed 7 years ago by Sebastian

I think your design is a cheap way to get a significant portion of the tor network to dos arbitrary hosts, and I don't see any advantage. The reason why I raise the point about never been a problem before is that I don't think you're solving the issue at hand with your suggestion, but rather design an extremely complex and very fragile system which won't help dirauths to actually serve their intended role, which is learning about relays, verifying they're there (along with some capabilities they might have, like the bw auths do), and providing a list of them all.

comment:12 Changed 7 years ago by mikeperry

Again: How does this plan DoS arbitrary hosts? Can't we mitigate that using the mechanisms I suggested in comment 1?

I can see that rechability testing creates network activity, but the dirauths already do that. Perhaps the dir mirrors can just use the same rate limiting mechanisms the dirauths already use today, as I describe in comment 1?

I also don't understand why you suddenly believe that the ability to protect the dirauths from unneeded load is not desirable? What happened to the Sebastian who created #3023? Do you now believe that dirauths should remain public relays and accept and relay all load that comes at them?

comment:13 Changed 7 years ago by nickm

I think that the right answer might be more roles then: not shoving functionality around among existing roles.

IOW, directory authorities must currently:

  1. Receive descriptors that routers publish
  2. Test servers
  3. Vote
  4. Produce a consensus
  5. Let mirrors fetch that consensus and the (micro)descriptors that it refers to
  6. Let clients without a valid consensus bootstrap onto the network.

Right now, we're seeing load problems from 6 and to a lesser extent 5. We hope to solve 6 with #572 or its successor. We might also try to offload 2. The functionality of 3 and 4 seems to be inherent in what directory authorities do. Solving 5 does not currently seem to have a ticket.

If we got the directory authorities role down to only 4 and 5, that would let us actually have directory servers not be relays at all, which would sure help with the load issues.

This ticket is about solving 1. I'm actually loosely in favor of decoupling the role of "receive and sanity-check descriptors" from the rest of what authorities do, but I don't think it's as critical as figuring out how to offload 5 and 6. I could chance my mind about that if data appears.

comment:14 in reply to:  13 ; Changed 7 years ago by mikeperry

Keywords: MikePerry201210d added; MikePerry201210 removed

Replying to nickm:

I think that the right answer might be more roles then: not shoving functionality around among existing roles.

IOW, directory authorities must currently:

  1. Receive descriptors that routers publish
  2. Test servers
  3. Vote
  4. Produce a consensus
  5. Let mirrors fetch that consensus and the (micro)descriptors that it refers to
  6. Let clients without a valid consensus bootstrap onto the network.

There's also "7. Participate in the relay network." That is Sebastian's #3023.

Right now, we're seeing load problems from 6 and to a lesser extent 5. We hope to solve 6 with #572 or its successor. We might also try to offload 2. The functionality of 3 and 4 seems to be inherent in what directory authorities do. Solving 5 does not currently seem to have a ticket.

Can you explain more about 5 being unsolved? I haven't been following microdesc development. You mean the only way to get microdescriptors right now is from the dirauths directly?

If we got the directory authorities role down to only 4 and 5, that would let us actually have directory servers not be relays at all, which would sure help with the load issues.

Yes. This is what I'm going for. I actually want it to be possible to at least temporarily enter into a mode where the only responsibilities for the dirauths are 3, 4, and 5, and function in a backup capacity for 2, but only for relays not already in the consensus.

This ticket is about solving 1. I'm actually loosely in favor of decoupling the role of "receive and sanity-check descriptors" from the rest of what authorities do, but I don't think it's as critical as figuring out how to offload 5 and 6. I could chance my mind about that if data appears.

Actually, I think the proposal would have to discuss roles 1 and 2 together. I will try to do so in my draft.

I think with #572 solving role 6, and #3023's goal of eliminating role 7, we're then down to my goal of a mode where the dirauths only participate in roles 3, 4 and 5, and sometimes 2.

Thanks for helping to clarify the direction on this, Nick. The main reason I started this in a trac ticket as opposed to going straight to proposal phase was so that we could get assumptions and framing like this nailed down.

comment:15 in reply to:  14 ; Changed 7 years ago by nickm

Replying to mikeperry:

Can you explain more about 5 being unsolved? I haven't been following microdesc development. You mean the only way to get microdescriptors right now is from the dirauths directly?

Not exactly.

I mean that right now, when a directory cache wants to learn a consensus, a router descriptor, or a microdescriptor, it fetches it from one of the authorities. It can't just ask another cache: there is no mechanism for *any* cache to learn this stuff right now other than asking an authority, so if all the caches asked each other, nobody would find out.

Obviously, this could be improved as a Simple Matter of Software Design.

comment:16 in reply to:  15 Changed 7 years ago by mikeperry

Replying to nickm:

Replying to mikeperry:

Can you explain more about 5 being unsolved? I haven't been following microdesc development. You mean the only way to get microdescriptors right now is from the dirauths directly?

Not exactly.

I mean that right now, when a directory cache wants to learn a consensus, a router descriptor, or a microdescriptor, it fetches it from one of the authorities. It can't just ask another cache: there is no mechanism for *any* cache to learn this stuff right now other than asking an authority, so if all the caches asked each other, nobody would find out.

Obviously, this could be improved as a Simple Matter of Software Design.

Yeah, I'm not suggesting some massive, expensive N2 layer where all the dir mirrors talk to eachother to exchange submitted relay descriptors or consensus microdescs.

My goal is the simplest possible design that allows us to reduce the roles of the dirauths to 3, 4, and 5. This means that dir mirrors (fine, even the whole current consensus) are still allowed to talk to dirauths to download and submit descriptor info. That way, if certain relays are loud/busted/broken in terms of their mirroring functionality, we can just drop them from the consensus as a last resort, or perhaps just add them to a dirport firewall.

To preserve the consensus properties for descriptor submission with minimal changes, it seems we have two options when the dirauths are operating in this mode:

  1. Relays submit descriptors to a dir mirror who submits it to all N authorities
  2. Relays submit descriptors k*N times, to the k*N dir mirrors in the current consensus with the k closest idhexes to each of the N dirauths, who then submit it forward to that dirauth.

In each case, the dir mirror should perform the same checks and rate limits that the dirauths currently do. They might also need additional IP restrictions too. It depends on what is actively enforced at the dirauths right now before performing checks.

My goal is to get a proposal for this written by Oct 10th that describes a way to support this as an optional mode of operation in extreme circumstances that we can test periodically. If we don't get it coded for 0.2.4.x because other things end up more important, that's fine. It might be the case that #572 by itself is enough to make me happy for emergency circumstances.

comment:17 Changed 7 years ago by mikeperry

Keywords: dirauth-dos-resistance added

comment:18 Changed 7 years ago by nickm

Keywords: needs-proposal added; proposal-needed removed

comment:19 Changed 7 years ago by nickm

Keywords: tor-auth added

comment:20 Changed 7 years ago by nickm

Component: Tor Directory AuthorityTor

comment:21 Changed 7 years ago by mikeperry

Keywords: MikePerry201210d removed
Milestone: Tor: 0.2.4.x-finalTor: unspecified

I'm probably not going to get this done by the 10th.

It's also slightly less urgent than #2681 and #4483, since we can always just write firewall rules to only allow existing relays to talk to the dirauths as a stopgap during DoS.

Guess we leave it for 0.2.5.x.

comment:22 Changed 4 years ago by mikeperry

Keywords: tor-dos-dirauth added; dirauth-dos-resistance removed

Canonicalize dirauth-dos to tor-dos-dirauth

comment:23 Changed 3 years ago by nickm

Points: 3
Severity: Normal

comment:24 Changed 2 years ago by dgoulet

Keywords: tor-dirauth added; tor-auth removed

Turns out that tor-auth is for directory authority so make it clearer with tor-dirauth

comment:25 Changed 2 years ago by nickm

Parent ID: #2664#18346
Note: See TracTickets for help on using tickets.