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

Thu Jun 13 15:24:08 UTC 2019

On 12 Jun (15:39:55), George Kadianakis 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.
> 
> >
> >    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.

I went more generic in order to support future "DoS" parameters which might
not be rate-limiting specific.

I personally prefer that instead of later creating a "[02] --
<NEW_DOS_NAME>_PARAMETERS".

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

Good point. Added a section about this.

Short answer: We will be using an extra 21 bytes leaving 343 bytes unused.

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

Yes indeed! Adding discussion section!

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

Yup, service version leaking is not a big concern of mine either.

Thanks for feedback! I've pushed the above changes as a fixup commit!

Onto responding to teor! :)

Cheers!
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/3d9c7461/attachment.sig>