diff options
author | Micah Elizabeth Scott <beth@torproject.org> | 2023-12-11 14:00:15 -0800 |
---|---|---|
committer | Micah Elizabeth Scott <beth@torproject.org> | 2024-01-25 08:56:48 -0800 |
commit | aee32ef87eb76b1a0b67d2c32701c1f77772830c (patch) | |
tree | 9e4fb17adf83864248e9a08e3ed533041d1b1bf2 | |
parent | c1c238f4fa5bf318517091eab8695ba09dc3368c (diff) | |
download | torspec-aee32ef87eb76b1a0b67d2c32701c1f77772830c.tar.gz torspec-aee32ef87eb76b1a0b67d2c32701c1f77772830c.zip |
udp: quick notes on a few more areas to investigate
-rw-r--r-- | proposals/339-udp-over-tor.md | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/proposals/339-udp-over-tor.md b/proposals/339-udp-over-tor.md index 2db0341..813531e 100644 --- a/proposals/339-udp-over-tor.md +++ b/proposals/339-udp-over-tor.md @@ -237,6 +237,19 @@ TODO: Various kinds of traffic we want to avoid - Excessive sends to a host that has never replied (DoS) - Excessive number of peers (makes port scanning too much easier) +See also RFC 7675, on the concept of "Send consent". + +# Anonymity risks + +TODO: ICE connectivity checks, as mentioned elsewhere. + +TODO: Are there plaintext identifiers in these telecom apps? + +TODO: Is there any chance we make the anonymity risk worse by providing UDP exits than it would be with an application-provided TCP relay server? + +# Alternative designs + +TODO: Comparison vs. an entirely out-of-protocol and potentially out-of-process TURN server. Is this complexity warranted? # Tor protocol design |