[tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension
David Goulet
dgoulet at torproject.org
Wed Jun 19 17:37:18 UTC 2019
On 12 Jun (08:18:33), David Goulet wrote:
After some days on tor-dev@ and a round of review, this is now a Draft in
tor-spec.txt.
https://gitweb.torproject.org/torspec.git/tree/proposals/305-establish-intro-dos-defense-extention.txt
Cheers!
David
> 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
>
> 0. Abstract
>
> We propose introducing a new cell extension to the onion service version 3
> ESTABLISH_INTRO cell in order for a service operator to send directices to
> the introduction point.
>
> 1. Introduction
>
> The idea behind this proposal is to provide a way for a service operator to
> give to the introduction points Denial of Service (DoS) defense parameters
> through the ESTABLISH_INTRO cell.
>
> We are currently developing onion service DoS defenses at the introduction
> point layer which for now has consensus parameter values for the defenses'
> knobs. This proposal would allow the service operator more flexibility for
> tuning these knobs and/or future parameters.
>
> 2. Proposal
>
> We introduce a new extention to the ESTABLISH_INTRO cell. The EXTENSIONS
> field will be leveraged and a new protover will be introduced to reflect
> that change.
>
> As a reminder, this is the content of an ESTABLISH_INTRO cell (taken from
> rend-spec-v3.txt section 3.1.1):
>
> AUTH_KEY_TYPE [1 byte]
> AUTH_KEY_LEN [2 bytes]
> AUTH_KEY [AUTH_KEY_LEN bytes]
> N_EXTENSIONS [1 byte]
> N_EXTENSIONS times:
> EXT_FIELD_TYPE [1 byte]
> EXT_FIELD_LEN [1 byte]
> EXT_FIELD [EXT_FIELD_LEN bytes]
> HANDSHAKE_AUTH [MAC_LEN bytes]
> SIG_LEN [2 bytes]
> SIG [SIG_LEN bytes]
>
> 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.
>
> 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
>
> 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.
>
> 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.
>
> 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
--
7gvISGYHFNIK7QwNC3ESEsvXh8l/OzdFYlwyc0G7WWQ=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190619/29180f36/attachment.sig>
More information about the tor-dev
mailing list