On 12 Jun (15:39:55), George Kadianakis 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. > > > > > 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=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev