Reduce application notes to a table

1 files changed, 24 insertions, 242 deletions

diff --git a/proposals/339-udp-over-tor.md b/proposals/339-udp-over-tor.md
index 3415890..3395b0b 100644
--- a/proposals/339-udp-over-tor.md
+++ b/proposals/339-udp-over-tor.md
@@ -203,248 +203,30 @@ TODO: More about the specifics of how ICE effects us. More about privacy concern
 
 ## Common Applications
 
-Some applications we've analyzed, in alphabetical order.
-
-### BitTorrent
-
-TODO: Analyze this (Incompatibility, abuse potential)
-
-### BigBlueButton
-
-BigBlueButton supports TURN over UDP and over TLS in the default configuration as of version 2.6.
-
-https://docs.bigbluebutton.org/administration/turn-server
-
-Confirmed this myself, and verified that BBB works over Tor already.
-
-### Discord
-
-Discord is a popular chat app. Here I was testing a voice and video call directly between two users.
-
-The protocol is proprietary. UDP appears to be mandatory. Without UDP, the "RTC Connecting" status turns into "No Route" and the call fails.
-
-The communication I've observed is point to point UDP traffic to one server.
-A server-reflexive IP address is visible as a string, suggesting behavior similar to STUN.
-
-We expect that UDP compatibility in Tor will likely make Discord usable.
-
-TODO: More testing could give us some confidence. Try running Discord over a UDP-capable tunnel that has latency/jitter characteristics similar to Tor.
-
-TODO: organize notes
-
-```
-  - First try, UDP and P2P unblocked. I'm only seeing point to point UDP with port 50007 on a server.
-  - STUN-like messages early on, reflexive IP address appears as a text string
-  - After some time, still seeing no other checks and no p2p traffic. Just talking to that single addr and port 50007.
-  - Enabling UDP filter. Status at the top of "Connecting..." screen goes from "RTC Connecting" to "No Route"
-  - Retrying. Still "No Route". Call signaling goes through and I can join on the other side. Both sides fail to connect their real-time stream to the server.
-  - Disabling UDP filter, and discord immediately connects.
-```
-
-### DNS
-
-We would like to support arbitrary DNS queries.
-
-TODO: More detail here. NAT traversal isn't an issue, but we have others:
-
-- How this interacts with MTUs
-- How we want to write exit policies for this
-- Potential for abuse
-
-### FaceTime
-
-TODO: organize notes
-
-```
-  - Trying to test the Android side specifically, with the remote end on macOS Monterey
-  - Link is of the form "https://facetime.apple.com/join#v=1&p=<>&k=<># where <> is a string possibly base64
-  - Tried mobile firefox. Rejected by browser sniffing. Asks specifically for chrome or edge.
-  - I'm not getting direct P2P traffic in this setup, presumably because of strict firewall on the other end. This end is WebRTC of course.
-Wireshark can see the STUN, DTLS, and SRTCP. Actual call traffic is point to point with apple's server, max size ~1170. Single peer.
-  - Filtering UDP and trying again.
-  - Now it's speaking TCP with the same IP address from earlier. TCP/80 specifically. Looks like TURN-over-TCP.
-  - Connection is good.
-  - Plaintext portion of STUN/TURN packets include text reference to WebRTC
-  - Retrying with Orbot on phone side. Mac is still behind the same restrictive NAT.
-  - Seems stable. Running ~30 mins fine, using 15-25 kB/sec
-```
-
-### Google Meet
-
-TODO: organize notes
-
-```
-  - With UDP available, call very quickly sets up peer-to-peer UDP over the wifi.
-  - Even with local call data over wifi, uses UDP to send short messages over TURN to an external STUN/TURN server. (rtt pings?)
-  - Signaling over QUIC. Uses STUN/TURN extensively. Uses TURN even when the p2p channel is available.
-  - Connectivity checks start early in calling UI flow
-  - With UDP filtered, uses plaintext TURN over TCP (no SSL)
-  - Trying Orbot. Looks fine. Quality is smoothly adapting down. High latency but stable. Tested for >10min, no deterioration.
-```
-
-### Jitsi Meet
-
-Jitsi is an open source audio and video conferencing app, based on web technologies.
-It uses WebRTC, with support for STUN and TURN, including UDP, TCP and TLS transports for TURN.
-
-The centrally hosted server (meet.jit.si) is configured with TCP support.
-On a network with UDP blocked, it still functions.
-However over Tor it has compatibility problems that seem unrelated to UDP. (HTTP 403 reported by the XMPP client)
-
-Self-hosted Jitsi instances often do not have TURN support.
-Deploying a TURN server at all requires extra steps, and securing it with time-limited credentials requires additional customization at this time.
-
-We expect that UDP compatibility in Tor would allow many self-hosted Jitsi instances to host calls over Tor when they previously could not. We don't expect any change in the behavior at the centralized instance.
-
-TODO: organize notes
-
-```
-  - First try, UDP and P2P unblocked. It's using both TURN and P2P (local wifi) traffic, seemingly for different streams.
-  - meet-jit-si-turnrelay.jitsi.net UDP/443. Messages in STUN extensions tell us this is Coturn-4.6.2
-  - Retry with UDP filtered. Same server, switches to TCP/433 TURN-over-SSL for server connection.
-  - It notices that only the NAT'ed UDP is filtered, and starts doing UDP directly over the wifi for some of the traffic. The other portion keeps using TURN-over-SSL.
-  - Connection seems okay but didn't test extensively. Noticed 'bad signal' icon on one end.
-  - Trying with Orbot, expect to avoid local udp and to add tor latency.
-  - Over orbot, I get a "You have been disconnected" message suspiciously quickly. Switching to one-side-orbot to make this easier to debug.
-  - This is weird, wondering if something else is going on like possibly an intentional block. Look closer at this.
-  - When I have one side on orbot and one not, the non-orbot side reaches "You are the only one in the meeting" and it can hang out there. At this stage there's no stream traffic.
-  - Noticing some traffic to rtcstats-server.jitsi.net in the working trace at around the point where the orbot'ed side fails. This is all TCP/443 stuff though.
-  - Trying a new identity in orbot.
-  - Still immediate "You have been disconnected". Either tor is blocked or this is a problem with the stream that was going over local wifi before.
-  - Trying no orbot, UDP dropped, call hosted on phone and joined with desktop browser (chrome)
-  - This works! Smooth video call between desktop chrome jitsi webapp (unfiltered) and the UDP-filtered phone. Uses TURN-over-TLS for the entire call. Audio and video both work and stable.
-  - Can I add tor to this setup? Orbot and UDP filter phone hosting the call, browser joining?
-  - Same immediate "You have been disconnected".
-  - Ok, looks a lot like their TURN server has tor blocked. Need a different monitoring position to verify for sure.
-
-  - Trying again with UDP blocked, and the TURN server is fine and the call is fine. Need to get access to trace in-between jitsi and tor.
-  - Can we try this using a transparent tor proxy on the openwrt side?
-    https://openwrt.org/docs/guide-user/services/tor/client
-  - Hmm. Trying to ignore the noise from other apps, and the re-connection attempt in jitsi that fails so quickly does not try to establish 
-any new connections, it's just a message exchanged with the main tcp/443 channel.
-  - Theory: the app is blocking based on IP address, either the fake addr used by the transproxy or the tor exit
-  - Can I repro that in another environment?
-  - Is there anything on logcat?
-     - Yes. JitsiMeetSDK messages are useful, as is filtering by PID.
-  - Is there anything useful in the public source code?
-     - lots here, would like to know where to start
-
-11-29 14:54:48.307  5948  5990 E JitsiMeetSDK: [modules/xmpp/strophe.util.js] Strophe: request id 258.1 error 403 happened
-11-29 14:54:48.307  5948  5990 W JitsiMeetSDK: [modules/xmpp/strophe.util.js] Strophe: request errored, status: 403, number of errors: 1
-11-29 14:54:48.307  5948  5990 I JitsiMeetSDK: [modules/xmpp/xmpp.js] (TIME) Strophe disconnecting:      4123159.764245
-11-29 14:54:48.320  5948  5990 I JitsiMeetSDK: [modules/xmpp/xmpp.js] (TIME) Strophe disconnected:       4123163.070091
-11-29 14:54:48.321  5948  5990 I JitsiMeetSDK: [modules/xmpp/xmpp.js] {"environment":"meet-jit-si","envType":"prod","releaseNumber":"4517","shard":"meet-jit-si-us-ashburn-1-s6","region":"us-east-1","userRegion":"us-east-1","crossRegion":0,"id":"deployment_info"}
-11-29 14:54:48.321  5948  5990 E JitsiMeetSDK: [modules/xmpp/xmpp.js] XMPP connection dropped!
-11-29 14:54:48.321  5948  5990 I JitsiMeetSDK: [modules/statistics/statistics.js] {"type":"operational","action":"connection.failed","attributes":{"error_type":"connection.droppedError","error_message":"connection-dropped-error","shard_changed":true,"suspend_time":0,"time_since_last_success":null}}
-
-That 403 error looks important. Can we find that on the server side? Any indications of exactly what triggered this?
-Just after this line which is fine but may indicate call preparatory info that could include IP addrs:
-
-11-29 14:59:52.934  5948  5990 D JitsiMeetSDK: [modules/RTC/RTCUtils.js] Available devices:  [ { kind: 'videoinput',
-
-Can I check whether the behavior is the same using chrome? firefox? I need this to be easier to debug.
-Uh. In browser (chrome + firefox) i'm getting a cloudflare popup that is not immediately succeeding.
-Several retries with cloudflare...
-And it's eventually working. audio is coming through. TURN over TLS.
-Video still all black. Will it adapt down?
-Trying again with chrome and video works.
-
-- Jitsi with local server (docker-compose)
-
-  - Default setup uses centralized STUN server, doesn't support TURN
-  - I'm seeing all traffic going to the video bridge on udp/10000. no p2p traffic even on same wifi network.
-  - Needs further debug
-```
-
-### Signal
-
-Signal is a popular chat, voice, and video calling app with end to end encryption.
-It is open source.
-The protocol is based on WebRTC, implemented using a fork of Google's libwebsocket.
-
-Signal has good support for TCP over TURN.
-Video and voice calls can be placed over Tor already, although it may take multiple attempts to establish a stable call.
-
-We expect that UDP compatibility in Tor would not have much effect on Signal.
-We might improve latency slightly by removing the TURN-related hops, but the latency savings is expected to be small compared to the overall latency and jitter in Tor.
-
-### SIP
-
-TODO: Lots more detail here.
-
-- Overview/history of SIP
-- Which configurations won't work
-- Which configurations will
-- How does this relate to Tor
-
-I'm still researching this but it looks like modern mobile-friendly SIP clients behave a lot like WebRTC. Historical SIP can require long lived port bindings with paired allocations, but I think any apps that require this would be broken for other reasons too.
-
-Looking for specific apps to test, I tried Linphone. It uses SIP over TLS for signaling, and it uses STUN and TURN for NAT traversal. However, there's no TCP support. Calls establish quickly, proceed with no audio for about 30 seconds while the app sends UDP packets that don't arrive, and then the call quietly ends.
-
-Expected that UDP support for Tor would likely allow some level of functionality from Linphone and other modern SIP softphones.
-Any app that requires long-lived IP assignment or can't demultiplex RTP/RTCP on the same port will have trouble unless we take extraordinary measures to support these apps.
-
-### Skype
-
-TODO: organize notes
-
-```
-  - Trying without any filtering. Quickly establishes direct p2p connection over wifi.
-  - Seems to be using STUN along with custom parts. Wireshark decodes some things and fails elsewhere.
-  - Peers: One local port talking to multiple peers, for NAT punching and for connectivity checks. (at least two stun-like servers in use)
-  - Trying with UDP filtered.
-  - Noticed STUN is happening while call is ringing, before it's been answered.
-  - With external UDP filtered, clients still find the local wifi p2p route.
-  - Turning on wifi client isolation.
-  - Now it's using TLS over TCP/443. Each call peer is talking to a different remote server.
-  - Seems like TURN-over-TLS. Starts this quickly after the STUN over UDP fails.
-  - Let's try over Orbot.
-  - Taking a while to establish a connection, quality is bad, but video and audio do come through.
-  - Trying again
-  - Quality still pretty bad, only using 10 kB/sec according to orbot. Might be an issue with skype's flow control?
-  - Letting it run to test stability. Running fine over orbot for 1hr. 20-40 kB/sec
-```
-
-### WhatsApp
-
-TODO: organize notes
-
-```
-  - Already works with Orbot. Quality is pretty good.
-  - network traces show STUN, including STUN over TCP. unclear whether it uses ICE or WebRTC.
-  - This analysis claims it's not webrtc but SIP, also uses STUN: https://webrtchacks.com/whats-up-with-whatsapp-and-webrtc/
-  - it's usage of STUN queries many servers in parallel using one local port. 
-```
-
-### WiFi Calling
-
-TODO: I don't expect this to work, but we should make sure it's not breaking too badly. These are usually IPsec tunnels, not UDP.
-
-TODO: organize notes
-
-```
-  - Noticed that these phones I'm testing (Verizon/Tracfone/BLU) are trying to do VPN traffic to wo.vzwwo.com which seems to be related to wifi calling. I don't have the accounts to test this, but if it continues to fail this may be a problem.
-```
-
-### Zoom
-
-TODO: organize notes
-
-```
-  - Video call uses UDP if it can, but works with UDP firewalled off.
-  - Doesn't immediately look like STUN/TURN, but a custom thing with similar properties
-  - Not sure if it's trying to do NAT hole punching? Seems to be point-to-point UDP, it isn't even trying multiple servers.
-  - Disabling wifi client isolation, rebooting, and trying again to encourage a p2p conn.
-  - Does not appear to attempt a peer-to-peer connection at first. Simple 1:1 UDP with its server.
-  - zoompaoal220mmr.pao.zoom.us UDP/8801, TCP/443
-  - AH. Eventually does switch to peer-to-peer, asynchronously. Two high UDP ports, using wlan local IP addrs.
-  - Handoff is managed using a custom protocol, signaling over their main TCP/443 channel, UDP connectivity checks with an all-caps UUID string visible inside. Stream handoff happens after connectivity checks finish, without interrupting stream.
-  - Various plaintext elements visible in UDP packets: UUID, strings like "detection_pkt_seq_no". Plaintext sequence numbers in the padding. Lots of padding, despite this padding being unencrypted and highly compressible.
-  - Video call goes over TCP/443 (and SSL)
-  - Trying Orbot. Quality is good! High latency but consistent video quality and audio is fine.
-  - Orbot bandwidth shows 80-200 kB/s each way.
-  - Connection seems stable, tested for 20 mins with no prob
-```
+With applications exhibiting such a wide variety of behaviors, how do we know what to expect from a good implementation?
+How do we know which compatibility decisions will be most important to users?
+For this it's helpful to look at specific application behaviors.
+This is a best-effort analysis conducted at a point in time.
+It's not meant to be a definitive reference, think of it as a site survey taken before we plan a building.
+
+In alphabetical order:
+
+| Application            | Type           | Protocol features                 | Current behavior   | Expected outcome                                   |
+| ---------------------- | -------------- | --------------------------------- | ------------------ | -------------------------------------------------- |
+| BitTorrent             | File sharing   | Many peers per local port         | Fails without UDP  | Works, new source of nuisance traffic              |
+| BigBlueButton          | Telecom        | WebRTC, TURN, TURN-over-TLS       | Works              | Slight latency improvement                         |
+| Discord                | Telecom        | Proprietary, client/server        | Fails without UDP  | Starts working                                     |
+| DNS                    | Infrastructure | Might want IP fragmentation       | Limited            | Full DNS support, for better and worse             |
+| FaceTime               | Telecom        | WebRTC, TURN, TURN-over-TCP       | Works              | Slight latency improvement                         |
+| Google Meet            | Telecom        | STUN/TURN, TURN-over-TCP          | Works              | Slight latency improvement                         |
+| Jitsi (meet.jit.si)    | Telecom        | WebRTC, TURN-over-TLS, Cloudflare | Fails on Tor       | No change, problem does not appear UDP-related     |
+| Jitsi (docker-compose) | Telecom        | WebRTC, centralized STUN only     | Fails without UDP  | Starts working                                     |
+| Linphone               | Telecom (SIP)  | SIP-over-TLS, STUN, TURN          | Fails without UDP  | Starts working                                     |
+| Signal                 | Telecom        | WebRTC, TURN, TURN-over-TCP       | Works              | Slight latency improvement                         |
+| Skype                  | Telecom        | P2P, STUN, TURN-over-TLS          | Works              | Slight latency improvement                         |
+| WhatsApp               | Telecom        | STUN, TURN-over-TCP. Multi server | Works              | Slight latency improvement                         |
+| WiFi Calling           | Telecom        | IPsec tunnel                      | Out of scope       | Still out of scope                                 |
+| Zoom                   | Telecom        | client/server or P2P, UDP/TCP     | Works              | Slight latency improvement                         |
 
 ## Malicious traffic