[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



Hi,

> On 12 Jun 2019, at 22:39, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
> 
> David Goulet <dgoulet@xxxxxxxxxxxxxx> 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.

+1

>> 
>>   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

This is ambiguous:
* the value is 8 bytes long
* the length of the maximum is unspecified: is it 4 bytes, 8 bytes, signed, or
  unsigned?
* the torrc default is unsigned 4 bytes: UINT32_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.

Let's say "any value has precedence over the network wide consensus
parameter". Otherwise it's unclear if 0 is a special value or not.

>>   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.

What happens if burst is less than rate?

> 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

if the intro point protocol supports them

>> regardless of
>>         what the consensus enables it or not. The value will be taken from

* values will be taken from

the HiddenServiceEnableIntroDoSRatePerSec and
HiddenServiceEnableIntroDoSBurstPerSec torrc options, then

>>         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)

Doesn't the default come from the consensus, and then the hard-coded
default?

Also see my notes about ambiguous size/signed maximums above.

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

Doesn't the default come from the consensus, and then the hard-coded
default?

Also see my notes about ambiguous size/signed maximums above.

>>   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

* parameter

>>   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"

Can we just call it HiddenServiceEnableIntroDoSDefense?

It's weird naming some DoS consensus parameters in snake_case, and
others in CamelCase. And it's also weird having different names for
torrc options and consensus parameters.

>>         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

HiddenServiceEnableIntroDoSDefense?

>> 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.

I think we also need consensus parameters for HiddenServiceEnableIntroDoSRatePerSec and
HiddenServiceEnableIntroDoSBurstPerSec.

>> 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@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev