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