[tor-talk] Help setting up tor dos defense

David Goulet dgoulet at torproject.org
Tue Jan 14 12:55:02 UTC 2020


On 07 Jan (15:38:46), s7r wrote:
> David Goulet wrote:
> > Tor relays supporting the HS DoS defense (intro points) at this point in time
> > are not in majority. Basically >= 0.4.2.1-alpha relays do support it which
> > currently represents ~36% in bandwidth weight so roughly 1/3 of the network.
> > 
> > If a service enables the defenses (like you did above), it will NOT
> > specifically pick intro points supporting the defenses but will normally pick
> > intro points as it did before and _if_ they happen to support the HS defenses
> > (via protocol version "HSIntro=5"), then they are used. Yes, I agree, not
> > ideal but there is a valid reason.
> > 
> > This is in part to prevent partitionning onion services using the HS defenses
> > to a specific set of relays (those who support it). Bottom line is: if the set
> > of relays that can only be used by an onion service is reduced, attack surface
> > gets bigger.
> > 
> > As the relay in the network upgrades to latest stables, the network naturally
> > move towards supporting these defenses in majority. This is another
> > _extremely_ important reason why relay operators should stay up to date with
> > their tor application so the network can be more agile in deploying defenses
> > and improvements.
> > 
> 
> Sure - the best move to prevent onion services partitioning using this
> HS defense. However, there is something unclear I'd like to understand.
> From the manual:
> 
> **HiddenServiceEnableIntroDoSDefense** **0**|**1**::
> Enable DoS defense at the intropoint level. When this is enabled, the
> rate and burst parameter (see below) will be sent to the intro point
> which will then use them to apply rate limiting for introduction request
> to this service.
> 
> The introduction point honors the consensus parameters except if this is
> specifically set by the service operator using this option. The service
> never looks at the consensus parameters in order to enable or disable
> this defense. (Default: 0)
> 
> So the service hosting the HS does not look at this consensus param.
> Right now e do not have a consensus  param for this at all, but what
> will happen if the directory authorities will vote this consensus param
> as HiddenServiceEnableIntroDoSDefense 1? In this case, the introduction
> points will see that, and use the default values of 25 introductions per
> second with a burst of 200 / sec. In this case, if a HS operator wants
> to _disable_ this protection totally, he should set
> HiddenServiceEnableIntroDoSRatePerSec 0 which according to the manual:
> 
> "If this option is 0, it is considered infinite and thus if
> **HiddenServiceEnableIntroDoSDefense** is set, it then effectively
> disables the defenses."?

Correct. A burst or rate that is 0 or crossing the upper limit, the intro
point will disable the defenses because the parameters received are unusable,
it does not fallback to the defaults.

The good news is that the torrc config parser should prevent you from putting
insane values but at the protocol level, it is still possible of course.

> 
> Or should he just set HiddenServiceEnableIntroDoSDefense 0, which is
> already 0 by default for _services_?  (this is the confusing part).

Just setting "HiddenServiceEnableIntroDoSDefense 0" is enough to disable the
defense even if the consensus set it to 1.

The intro point always use what the service specifies. If nothing present,
then the consensus param is used.

So for the case that the service sets "HiddenServiceEnableIntroDoSDefense 0",
then that value is sent to the intro point indicating to disable the defense.

Hope this answer your question
David

-- 
wlQW8e6zy9BjPFoNUszA+ip0Fa+lseCuCGd+6jzB1KI=
-------------- 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-talk/attachments/20200114/cd606094/attachment.sig>


More information about the tor-talk mailing list