Re: [tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension

On 12 Jun (15:39:55), George Kadianakis wrote:

David Goulet dgoulet@torproject.org writes:

...

Filename: 305-establish-intro-dos-defense-extention.txt Title: ESTABLISH_INTRO Cell DoS Defense Extension Author: David Goulet, George Kadianakis Created: 06-June-2019 Status: Draft

Thanks for this proposal, it's most excellent and an essential building block for future work on intro point related defences.

...

We propose a new EXT_FIELD_TYPE value:

  [01] -- DOS_PARAMETERS.

          If this flag is set, the extension should be used by the
          introduction point to learn what values the denial of service
          subsystem should be using.

Perhaps we can name it "rate-limiting parameters"? But no strong opinion.

I went more generic in order to support future "DoS" parameters which might not be rate-limiting specific.

I personally prefer that instead of later creating a "[02] -- <NEW_DOS_NAME>_PARAMETERS".

...

The EXT_FIELD content format is:

  N_PARAMS    [1 byte]
  N_PARAMS times:
     PARAM_TYPE  [1 byte]
     PARAM_VALUE [8 byte]

The PARAM_TYPE proposed values are:

  [01] -- DOS_INTRODUCE2_RATE_PER_SEC
          The rate per second of INTRODUCE2 cell relayed to the service.

  [02] -- DOS_INTRODUCE2_BURST_PER_SEC
          The burst per second of INTRODUCE2 cell relayed to the service.

The PARAM_VALUE size is 8 bytes in order to accomodate 64bit values (uint64_t). It MUST match the specified limit for the following PARAM_TYPE:

  [01] -- Min: 0, Max: INT_MAX
  [02] -- Min: 0, Max: INT_MAX

How would this new addition to the cell impact the size of the cell? How much free space do we have for additional features to this cell (e.g. to do the PoW stuff of the other thread)?

Good point. Added a section about this.

Short answer: We will be using an extra 21 bytes leaving 343 bytes unused.

...

A value of 0 means the defense is disabled which has precedence over the network wide consensus parameter.

In this case, if the rate per second is set to 0 (param 0x01) then the burst value should be ignored. And vice-versa, if the burst value is 0, then the rate value should be ignored. In other words, setting one single parameter to 0 disables the INTRODUCE2 rate limiting defense.

I think it could be cool to add a discussion section where we introduce a new cell from the intro to the service which informs the service that rate limiting limits have been hit. So that there is a way for the service to get feedback that it's under attack or capped by limits. Otherwise, there is simply no way to learn it.

This can be a later feature fwiw.

Yes indeed! Adding discussion section!

...

3. Protocol Version

   We introduce a new protocol version in order for onion service that wants to specifically select introduction points supporting this new extension. But also, it should be used to know when to send this extension or not.

   The new version for the "HSIntro" protocol is:

   "5" -- support ESTABLISH_INTRO cell DoS parameters extension for onion service version 3 only.

4. Configuration Options

   We also propose new torrc options in order for the operator to control those values passed through the ESTABLISH_INTRO cell.

   "HiddenServiceEnableIntroDoSDefense 0|1"

     If this option is set to 1, the onion service will always send to the
     introduction point denial of service defense parameters regardless of
     what the consensus enables it or not. The value will be taken from
     the consensus and if not present, the default values will be used.
     (Default: 0)
   
   

   "HiddenServiceEnableIntroDoSRatePerSec N sec"

     Controls the introduce rate per second the introduction point should
     impose on the introduction circuit.
     (Default: 25, Min: 0, Max: 4294967295)
   
   

   "HiddenServiceEnableIntroDoSBurstPerSec N sec"

     Controls the introduce burst per second the introduction point should
     impose on the introduction circuit.
     (Default: 200, Min: 0, Max: 4294967295)
   
   

   They respectively control the parameter type 0x01 and 0x02 in the ESTABLISH_INTRO cell detailed in section 2.

   The default values of the rate and burst are taken from ongoing anti-DoS implementation work [1][2]. They aren't meant to be defined with this proposal.

5. Security Considerations

   Using this new extension leaks to the introduction point the service's tor version. This could in theory help any kind of de-anonymization attack on a service since at first it partitions it in a very small group of running tor.

   Furthermore, when the first tor version supporting this extension will be released, very few introduction points will be updated to that version. Which means that we could end up in a situation where many services want to use this feature and thus will only select a very small subset of relays supporting it overloading them but also making it an easier vector for an attacker that whishes to be the service introduction point.

Interesting idea.

I'm not that worried about the service leaking its version to the intro, but I am worried about all attacked services saturating the few upgraded intro points, so I agree that such a switch makes sense.

Yup, service version leaking is not a big concern of mine either.

Thanks for feedback! I've pushed the above changes as a fixup commit!

Onto responding to teor! :)

Cheers! David