[tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension
teor
teor at riseup.net
Thu Jun 13 00:35:34 UTC 2019
Hi,
> On 12 Jun 2019, at 22:39, George Kadianakis <desnacked at riseup.net> 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.
+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 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
More information about the tor-dev
mailing list