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

Thu Jun 13 15:50:48 UTC 2019

On 13 Jun (10:35:34), teor wrote:
> Hi,

[snip]

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

Yeah my goal was to max it out to the torrc but signed because our consensus
param are int32_t (networkstatus_get_param()).

I've pushed a fixup to clarify all this. I've actually put the INT32_MAX value
in there instead of just a "macro" :).

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

Indeed. Corrected.

> 
> >>   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've clarified.

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

Fixed.

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

If explicitely set, the torrc options always win over the consensus param.
Thus, the default values are only taken if the consensus param aren't present.

I've clarified.

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

Fixed.

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

Yes good idea. And this is how we did things with the DoS subsystem as well to
match both in the consensus and torrc.

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

We do, it is just part of another piece of work from ticket #15516.

Everything has been fixed and pushed!

Thanks!
David

-- 
NYhJAL29Sx8P3VP6lGX7k5jnjujtvQexLKt/rMno1u8=
-------------- 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/20190613/a1da59b8/attachment.sig>