aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMicah Elizabeth Scott <beth@torproject.org>2023-12-11 14:00:15 -0800
committerMicah Elizabeth Scott <beth@torproject.org>2024-01-25 08:56:48 -0800
commitaee32ef87eb76b1a0b67d2c32701c1f77772830c (patch)
tree9e4fb17adf83864248e9a08e3ed533041d1b1bf2
parentc1c238f4fa5bf318517091eab8695ba09dc3368c (diff)
downloadtorspec-aee32ef87eb76b1a0b67d2c32701c1f77772830c.tar.gz
torspec-aee32ef87eb76b1a0b67d2c32701c1f77772830c.zip
udp: quick notes on a few more areas to investigate
-rw-r--r--proposals/339-udp-over-tor.md13
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