Re: [quicwg/base-drafts] Document request forgery (#3996)

[David Schinazi <[e-mail]>]

@DavidSchinazi commented on this pull request.



> +frames in packets prior to completing address validation. Note that this does
+not prevent an attacker from using the Destination Connection ID field for an
+attack.
+
+Endpoints are not expected to have specific information about the location of
+servers that could be vulnerable targets of a request forgery attack. However,
+it might be possible over time to identify specific UDP ports that are common
+targets of attacks or particular patterns in datagrams that are used for
+attacks. Endpoints MAY choose to avoid sending datagrams to these ports or not
+send datagrams that match these patterns prior to validating the destination
+address. Endpoints MAY retire connection IDs containing patterns known to be
+problematic without using them.
+
+Note:
+
+: Modifying endpoints to apply these protections is more efficient than

It's definitely possible that I'm the one confused. In my understanding, we have two ways of solving the "QUIC endpoint is sending attacker-controlled data to unvalidated address" issue:
1. the QUIC endpoint limits what it sends before validation
2. a magical network appliance verifies that the QUIC endpoint isn't sending evil packets where it shouldn't

I do agree with you that we want (1) instead of (2), but saying that (1) is more *efficient* than (2) isn't necessarily true if you measure efficiency as QUIC performance, because (1) can add a round trip but (2) doesn't

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3996#discussion_r480319780