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

juanjo juanjo at avanix.es
Wed Jun 12 18:47:14 UTC 2019

Hello, this is my view of things, please be gentle as this is my first 
proposal draft :)


Client sends the INTRODUCE1 as normal.

Introduction Point checks the Current Requests Rate and checks the DoS 

-DoS check is OK: send INTRODUCE2 to Hidden Service etc...

-DoS settings/rate limit reached: then

     1.Introduction Point generates a random 8 bytes key (IPKey) and 
associates it with the client circuit. Then send INTRODUCE_POW to the 
Client with the IPKey.
     2.Client computes POW.
Generates random 8 bytes key (ClientKey).
Generates hash(sha512/256 or sha3??) of
hash(IPKey + ClientKey)
} while (hash does not start with "abcde")

     3. Client sends INTRODUCE_POWR to the I.P. with the generated POW 
and the ClientKey.
     4. I.P. checks the POW:

         -POW is correct: send INTRODUCE2 to HS.
         -POW is not correct: send INTRODUCE_POW_ERROR to client with 
new IPKey.

*I say 8 bytes for the Keys just for example.

PROS AND CONS, who needs to update Tor version?:

Only rate limit: Introduction Point and Hidden Service. No breakage.

POW: Client, Introduction Point and Hidden Service. POW will break 
compatibility with other v3 Hidden Services clients, if we implement a 
way to bypass POW for old clients then this feature won't work as intended.

A forgotten guy here: Authenticated Rends cell: where we make sure the 
Client established a connection to the Rend Point before requesting the 

On 12/6/19 14:39, George Kadianakis wrote:
> David Goulet <dgoulet at 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.
>>     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)?
>>     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.
>> 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.
>>     For the above reasons, we propose a new consensus parameters that will
>>     provide a "go ahead" for all service out there to start using this
>>     extension only if the introduction point supports it.
>>        "enable_establish_intro_dos_extension"
>>           If set to 1, this makes tor start using this new proposed extension
>>           if available by the introduction point (looking at the new protover).
>>     This parameter should be switched on when a majority of relays have
>>     upgraded to a tor version that supports this extension for which we believe
>>     will also give enough time for most services to move to this new stable
>>     version making the anonymity set much bigger.
>>     We propose to add a torrc option to ignore this parameter and force tor to
>>     select introduction points supporting this extension which will
>>     effectively, in the beginning, toss away these security considerations.
>>     We believe that there are services that do not care about anonymity on the
>>     service side and thus could benefit from this feature right away if they
>>     wish to use it.
>> References:
>> [1] https://lists.torproject.org/pipermail/tor-dev/2019-May/013837.html
>> [2] https://trac.torproject.org/15516
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190612/13dde6fa/attachment-0001.html>

More information about the tor-dev mailing list