RFC: Mitigation of Web Transport Throttling

[Javier Fernandez]

Hi,

Back in 2021 Chrome implemented a throttling mechanism for Web Transport
in an effort to prevent DoS and port-scanning attacks via this emerging
feature. It's worth mentioning that this measures are not defined in the
official draft of the Web Transport specification and are not
implemented in Firefox, which is the other browser implementing the spec
and that recently landed the serverCertificateHashes option in its
implementation (available in nightly since last week).

The bug 1172046 is perhaps the first of many that relate undesirable
consequences of these preventive measures, which I admit are
understandable and addressing actual challenges and risks that the Web
Transport feature may bring into the Web Platform.

I've been working on a proposal to try to mitigate these undesirable
consequences, especially in the context of P2P applications but not
exclusively to them; I think there are other apps and use cases of the
Web Transport feature that may by hit buy an excessive restrictive
throttling like the one Chrome has implemented.

https://docs.google.com/document/d/1u2kcv3YjvxMc91xylGAyhP1UhxAr2ZobgvCaL37AOUM/edit

I'd appreciate any feedback on the proposal that I'd like to eventually
send as an official intent-to-prototype, once we agree this is something
we really want to pursue.

Thanks.

--

javi

[Javier Fernandez]

Sorry, this is the correct link to the proposal

https://docs.google.com/document/d/1j2NJqLQyAHSBZArW6Iwg8uVId3NGQxnBV7b9LYbd8FM/edit

[Adam Rice]

Great document! I'm really happy to see good design discussion.

--
You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/932783a5-d2cf-4f6a-b7a0-88d7212d9ec1%40igalia.com.

[Adam Rice]

For reference, here is the original design doc for the WebTransport throttling: https://docs.google.com/document/d/1u2kcv3YjvxMc91xylGAyhP1UhxAr2ZobgvCaL37AOUM/edit

I don't think I envisioned the P2P use case.

[Javier Fernandez]

Hi,

On 19/3/24 16:55, Adam Rice wrote:

For reference, here is the original design doc for the WebTransport throttling: https://docs.google.com/document/d/1u2kcv3YjvxMc91xylGAyhP1UhxAr2ZobgvCaL37AOUM/edit

I don't think I envisioned the P2P use case.

I believe that for the P2P use case the implementation of fine-grained penalties is the measure that would have more impact. We can agree that sending multiple connection requests to unrelated targets (different subnet) is not an attack and could be considered as a legit scenario, even if the failure rate is high.  We can discuss in the design document about the numbers or different strategies, but I think we can start prototyping the idea and iterate from that.

About the rest of the mitigation strategies defined in the document, we can implement it independently and evaluate later how they work together and their impact on the P2P use cases and the demos we have.

Best,

--

javi

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/CAC_ixdwnpaa156XDoJfnrnVQe82qdU_R_xfxfDO2jXc34bk8KA%40mail.gmail.com.

[Javier Fernandez]

Hi,

I tried to reply the questions and incorporate the suggestions to the
design document; not sure whether we would need more time to discuss it.

I'd like to start prototyping at least the measures to discriminate the
penalties based on the target ip / subnet. I think that idea has been
mentioned already in the bug and received positive feedback. I can
iterate on the design document as I get some progress with the
prototype. Does this sound reasonable ?

Regards,

--
javi

On 18/3/24 11:57, Javier Fernandez wrote:

[Adam Rice]

Thanks Javier,

That sounds good to me. Please keep in mind as you are developing that we will initially need to land the new algorithm guarded by a base::Feature in accordance with the flag guarding guidelines (https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md). I usually find it easiest to add the base::Feature at the beginning before I write the code. Depending on which you prefer, you could either just put if (base::FeatureList::IsEnabled(kNewWebTransportThrottling) around the sections that are different, or you could change WebTransportThrottleContext to be an abstract base class and have a static WebTransportThrottleContext::Create() method that chooses the implementation based on whether the kNewWebTransportThrottling feature is enabled or not, and returns a std::unique_ptr<WebTransportThrottleContext>.

Before shipping, the feature will have security and privacy reviews. I'm not confident that the "Too many connections" exception will make it through privacy review, so it might be a good idea to make that part easily separable so it can be removed if needed.

Thanks for your work on this,

Adam

--
You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/c6e381ad-7ea7-4511-a81d-c9d10160f10a%40igalia.com.