Opened 11 months ago

Last modified 2 months ago

#31223 new defect

Research approaches for improving the availability of services under DoS

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, tor-dos, network-team-roadmap-2020Q1, network-health, 043-deferred
Cc: Actual Points:
Parent ID: #33703 Points: 15
Reviewer: Sponsor: Sponsor27-can

Description

We've been improving the health of the network during onion service DoS, but not the onion service availability. This is a task for looking at this angle.

During the related Stockholm session we looked into various approaches that could help us towards that goal. Here are some of them:

  • Introducing application-layer anonymous tokens that allow legit clients to get priority over DoS attacker
  • PoW approaches like argon2
  • CAPTCHA approaches like introducing a token server giving reCAPTCHA tokens
  • Hiding introduction points by rate limiting how quickly clients can find them. Valet nodes?
  • Having intros check that clients don't use the same IP over and over. Proof-of-existence?
  • Pay bitcoin to introduce

Each of the above solutions has problems and this is a ticket to investigate at least the most promising of them, and attempt to move forward with something.

Child Tickets

TicketStatusOwnerSummaryComponent
#33712newDesign a PoW scheme for HS DoS defenceCore Tor/Tor

Change History (14)

comment:2 Changed 11 months ago by asn

Parent ID: #29999

comment:3 Changed 9 months ago by vinay

Things to consider:

Last edited 9 months ago by vinay (previous) (diff)

comment:4 Changed 6 months ago by asn

Relevant feature #32511.

comment:5 Changed 6 months ago by asn

Parent ID: #29999
Sponsor: Sponsor27-mustSponsor27-can

Moving this to -can for the purposes of sponsor time tracking.

comment:6 Changed 6 months ago by asn

Just to expand on the Introducing application-layer anonymous tokens that allow legit clients to get priority over DoS attacker from the top post. This would be introducing some sort of anonymous credentials system for onion services, where onions can give some tokens to their good clients in an out-of-band fashion and these tokens are used during the introduction protocol to prioritize them over the swarm of unknown clients.

With regards to primitives that can be used for such anonymous tokens there is a whole literature on anonymous credentials that we should look into. Here are some more links that have been sent to me and I have noted them for future reading: https://eprint.iacr.org/2019/877.pdf
https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki#Blind_Signatures
https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs
https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs

Further questions is how these tokens will be passed to legit clients in the first place, if the onion service is unreachable. And what's the difference between this approach and the onion service just making more onion addresses for good clients instead of tokens.

comment:7 Changed 6 months ago by gaba

Keywords: network-team-roadmap-2020Q1 added

comment:8 Changed 5 months ago by gk

Keywords: network-health added

comment:9 Changed 4 months ago by nickm

Keywords: 043-deferred added

All 0.4.3.x tickets without 043-must, 043-should, or 043-can are about to be deferred.

comment:10 Changed 4 months ago by nickm

Milestone: Tor: 0.4.3.x-finalTor: unspecified

comment:11 Changed 3 months ago by asn

Here is another possible improvement with its own tradeoffs (HTTP channel for killing circuits): https://lists.torproject.org/pipermail/tor-dev/2019-December/014097.html

Also let's not forget the still unresolved intro-point-rotation-issue:
https://trac.torproject.org/projects/tor/ticket/26294

Last edited 3 months ago by asn (previous) (diff)

comment:12 Changed 2 months ago by asn

Parent ID: #33703

comment:13 in reply to:  3 ; Changed 2 months ago by mikeperry

Replying to vinay:

Unfortunately, we only have about 253 bytes max to use if we want to send the proof in the intro circuit itself... MTP proofs are ~187KB with their recommended L=70 parameter (see Section 4.6). This is far too large to use without a secondary validator server that hands out tokens in exchange for proofs, which is a lot more complexity :/

Other potential ideas from the MTP paper's references:

comment:14 in reply to:  13 Changed 2 months ago by asn

Replying to mikeperry:

Replying to vinay:

Unfortunately, we only have about 253 bytes max to use if we want to send the proof in the intro circuit itself... MTP proofs are ~187KB with their recommended L=70 parameter (see Section 4.6). This is far too large to use without a secondary validator server that hands out tokens in exchange for proofs, which is a lot more complexity :/

Other potential ideas from the MTP paper's references:

FWIW, I made child ticket #33712 for more exploration of this particular avenue. Let's use this ticket for more brainstorming kind of things, and use #33712 to get deeper into pow/anon credentials.

Note: See TracTickets for help on using tickets.