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

[Christian Huitema <[e-mail]>]

@huitema commented on this pull request.



> +lack proper authentication. Endpoints MAY prevent connection attempts or
+migration to a loopback address. Endpoints SHOULD NOT allow connections or
+migration to a non-loopback address if the same service was previously
+available over a different interface or the address was provided by a service
+at a non-loopback address. Endpoints that depend on these capabilities could
+offer an option to disable these protections.
+
+Similarly, endpoints could regard a change in address to link-local address
+{{?RFC4291}} or an address in a private use range {{?RFC1918}} from a global,
+unique-local {{?RFC4193}}, or non-private address as a potential attempt at
+request forgery. Endpoints could refuse to use these addresses entirely, but
+that carries a significant risk of interfering with legitimate cases. Endpoints
+SHOULD NOT refuse to use an address unless they have specific knowledge about
+the network that indicates that sending datagrams to unvalidated addresses in a
+given range is not safe.
+

There is indeed a valid scenario for client and server discovering that they are behind the same NAT. Wasn't that scenario addressed in Web-RTC using a discovery protocol involving temporary names, in an attempt at privacy? 

-- 
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#pullrequestreview-466846714