Re: [tor-dev] [prop305] Introduction Point Behavior
David Goulet 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 ;). > > > > 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! :) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [prop305] Introduction Point Behavior
Hi David, > On 15 Aug 2019, at 22:56, David Goulet wrote: > > I'm leaning towards not closing the circuit and falling back on the consensus > parameters. Using the consensus parameters seems like a good thing to do. We can say "valid parameters override the consensus parameters. Invalid parameters are ignored, and the circuit uses 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. Do we have a protocol warning for invalid parameters? If we do, we should be able to detect issues as they happen. I don't think there's an easy way of detecting these kinds of bugs in chutney. But maybe we want to set consensus parameters and torrc parameters on one of the chutney networks? T ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [prop305] Introduction Point Behavior
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 ;). 2) A parameter type is unrecognized. This one is mostly about forward compatibility. Behavior: Ignore the parameter type, and continue parsing the cell extension. If all the right parameters are found, apply defenses. 3) None or 1 parameter out of 2 is given. Behavior: This would be considered bad protocol so it would be like (1) where the intro point uses the consensus parameters. 4) So, for (1) and (3), there lies mostly the discussion. There is no way to send feedback to the service if a problem occurred and that the DoS defenses weren't applied due to reason X. If we had that, we could not only try to warn the operator (log or control event) but make tor smarter when an error is returned so it doesn't try to infinity other intro points with values that makes them fail. One avenue there is to pass down such error code into the INTRO_ESTABLISHED cell with probably a new extension. That requires more work and likely either extending prop305 or a new proposal. Thus, what is the minimal viable product here we are ok with? 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. Cheers! David -- eHE50zZRZOX3zLNHdPwN5gGQBUvDnfGyOuYr/afK2XY= signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
