[tor-bugs] #15516 [Core Tor/Tor]: Consider rate-limiting INTRODUCE2 cells when under load

[Tor Bug Tracker & Wiki]

#15516: Consider rate-limiting INTRODUCE2 cells when under load
-------------------------------------------------+-------------------------
 Reporter:  special                              |          Owner:  (none)
     Type:  enhancement                          |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  SponsorU-deferred, tor-dos, tor-hs,  |  Actual Points:
  network-team-roadmap-2019-Q1Q2                 |
Parent ID:  #29999                               |         Points:  10
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-can
-------------------------------------------------+-------------------------

Comment (by arma):

 Replying to [comment:2 arma]:
 > I'd actually like to some exploration of initial throttling or dropping
 or queueing at the intro point as well. That was originally meant to be
 the first line of defense here.

 Here's my concrete proposal on this one: the intro point should see if the
 package window for the intro circuit is empty, and if so, it should nack
 the intro1 cell. That way there are at most 1000 intro2 cells in flight at
 once from that intro point.

 This design is reasonable because it takes a long while for an onion
 service to process 1000 intro2 cells, so if we queue later ones and send
 them 'eventually', they're going to arrive much later, and the client will
 likely have timed out and moved on from that rendezvous point. So we're
 not harming legitimate clients who end up in this situation, because the
 current behavior is already harming them plenty.

 The benefits are that (a) the onion service doesn't receive the excess
 intro2 cells that it wasn't going to be able to rendezvous with anyway,
 (b) clients get a much faster feedback that things aren't going to work so
 they can move to another intro point, and (c) when a DoS stops, the pain
 stops soon after: there isn't a huge queue of waiting intro2 cells that
 have to slowly drain, for no value.

 We could imagine an extension on this idea, where the intro point silently
 drops the excess intro1 cells, rather than explicitly nacking them. This
 variant will force the client to time out rather than immediately try the
 next intro point, thus slowing down attacks by clients that follow the
 protocol. (Modified clients could still use a smaller timeout, or not even
 care whether they get a response.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15516#comment:28>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online