[tor-dev] [prop305] Introduction Point Behavior

[George Kadianakis]

David Goulet <dgoulet at torproject.org> writes:

> Greetings,
>
> This is part of the many discussions about proposal 305 which is the
> ESTABLISH_INTRO DoS defenses cell extension.
>
> Implementation is close to done and under review in ticket #30924. However,
> there is one part that is yet to be cleared out. asn and I thought it would be
> better to bring it to tor-dev@ to get a more informed decision.
>
> As a reminder, the service operator will be able set torrc options that are
> the DoS defenses parameters. Those values are validated (bound check) and then
> sent to an introduction point, supporting the extension (protover HSIntro=5),
> in the ESTABLISH_INTRO cell. The intro point then gets them and apply them
> only to that specific circuit. If no cell extension is seen, the intro point
> will honor the consensus parameters for these DoS defenses.
>
> What we want to discuss is what happened when the introduction points receives
> bad values. What does it do with the circuit? Below is the list of possible
> bad values and the proposed behavior:
>
> 1) One of the paramater (at this point in time, only 2 exists) is out of bound
>    that is above INT32_MAX.
>
>    Behavior: We propose to ignore the cell extension, and fallback to follow
>              the consensus parameters. Keeping the circuit alive and working.
>
>    The reason for this is because if let say the intro point would close the
>    circuit due to "bad protocol", then the service would open a new circuit to
>    an intro point supporting the extension and it would fail again.
>    Effectively turning the service into a "zombie" and "DoS" weapon itself ;).
>
>    At this point, there is really no reason on why the service would send bad
>    values since torrc options are validated and then sent to the intro point.
>    But this doesn't protect us from our future-developer-self making coding
>    or protocol mistake ;).
>
> <snip>
>
> I'm leaning towards not closing the circuit and falling back on the consensus
> parameters. And at some point in time, we'll be able to implement the
> INTRO_ESTABLISHED response. In the meantime, there is little chances that tor
> vanilla start sending bad values since they are validated from the torrc file.
>

Hello David,

I agree with your evaluation about keeping the circuit open on bad
values and going with the consensus parameters!

That said, let's also make a ticket about the INTRO_ESTABLISHED
enhancement that will allow us to send back status messages. Same goes
for a ticket that allows us to send multiple ESTABLISH_INTRO in the same
circuit, so that we can update the values in a hotplug way.

Finally, this is off-topic but another intro<->service communication we
might want to add in the future, is a message from the intro informing
the service that the rate-limiting parameters have been hit.

Cheers! :)