Work in progress on application-driven design goals for UDP

1 files changed, 367 insertions, 16 deletions

diff --git a/proposals/339-udp-over-tor.md b/proposals/339-udp-over-tor.md
index 12de0c6..289e962 100644
--- a/proposals/339-udp-over-tor.md
+++ b/proposals/339-udp-over-tor.md
@@ -11,7 +11,8 @@ Status: Accepted
 Tor currently only supports delivering two kinds of traffic to the
 internet: TCP data streams, and a certain limited subset of DNS
 requests. This proposal describes a plan to extend the Tor protocol so
-that exit relays can also relay UDP traffic to the network?.
+that exit relays can also relay some additional types of UDP traffic
+to the network.
 
 Why would we want to do this?  There are important protocols that use
 UDP, and in order to support users that rely on these protocols, we'll
@@ -31,7 +32,16 @@ implemented some version of
 (relay fragment cells) so that we can transmit relay messages larger
 than 498 bytes.
 
-# Overview
+With the above in mind, the goal of this proposal is specifically to enable compatibility with more applications.
+We will analyze some of those applications below, in order to choose an appropriate subset of UDP to implement which achieves our compatibility goals.
+These compatibility goals will need to be weighed against any anonymity hazards or opportunities for abuse.
+
+We expect that work to improve round-trip time and jitter characteristics, such as Conflux, will benefit both TCP and UDP applications.
+Many applications already support both transport protocols, and will perform similarly with or without this proposal.
+
+# UDP Traffic Models
+
+## User Datagram Protocol (RFC768)
 
 UDP is a datagram protocol; it allows messages of up to 65536 bytes,
 though in practice most protocols will use smaller messages in order to
@@ -41,21 +51,342 @@ UDP messages can be dropped or re-ordered.  There is no authentication
 or encryption baked into UDP, though it can be added by higher-level
 protocols like DTLS or QUIC.
 
-When an application opens a UDP socket, the OS assigns it a 16-bit port
-on some IP address of a local interface.  The application may send
-datagrams from that address:port combination, and will receive datagrams
-sent to that address:port.
+The "User Interface" suggested by RFC768 for the protocol is a rough sketch, suggesting that applications have some way to allocate a local port for receiving datagrams and to transmit datagrams with arbitrary headers.
+
+Despite UDP's simplicity as an application of IP, we do need to be aware of IP features that are typically hidden by TCP's abstraction.
+UDP applications typically try to obtain an awareness of the path MTU, using some type of path MTU discovery (PMTUD) algorithm.
+On IPv4, this requires sending packets with the "Don't Fragment" flag set, and measuring when those packets are lost or when ICMP "Fragmentation Needed" replies are seen.
+
+Note that many applications have their own requirements for path MTU. For example, QUIC and common implementations of WebRTC require an MTU no smaller than 1200 bytes, but they can discover larger MTUs when available.
+
+## Socket Layer
+
+In practice the straightforward "User Interface" from RFC768, capable of arbitrary local address, is only available to privileged users.
+
+BSD-style sockets support UDP via `SOCK_DGRAM`.
+UDP is a stateless protocol, but sockets do have state.
+Each socket is bound, either explicitly with 'bind()' or automatically, to a source IP and port.
+
+At the API level, a socket is said to be _connected_ to a remote address:port if that address is the default destination.
+A _connected_ socket will also filter out incoming packets with source addresses different from this default destination.
+
+A socket is considered _unconnected_ if 'connect()' has not been called.
+These sockets have no default destination, and they accept datagrams from any source.
+
+There does not need to be any particular mapping between the lifetime of these application sockets and any higher-level "connection" the application establishes.
+It's better to think of one socket as one allocated source port.
+A typical application may allocate only a single port (one socket) for talking to many peers.
+Every datagram sent or received on the socket may have a different peer address.
+
+## Network Address Translation (NAT)
+
+Much of the real-world complexity in UDP applications comes from their strategies to detect and overcome the effects of NAT.
+
+Many RFCs have been written on NAT behavior and NAT traversal strategies.
+RFC4787 establishes best practices for NAT.
+RFC8445 describes the Interactive Connectivity Establishment (ICE) protocol, which has become a very common application-level technique for building peer to peer applications that work through NAT.
+
+There are multiple fundamental technical issues that NAT presents:
+
+1. NAT must be stateful in order to route replies back to the correct source.
+   This directly conflicts with the stateless nature of UDP itself.
+   The NAT's mapping lifetime, determined by a timer, will not necessarily match the lifetime of the application-level connection.
+   This necessitates keep-alive packets in some protocols.
+   Protocols that allow their binding to expire may be open to a NAT rebinding attack, when a different party acquires access to the NAT's port allocation.
+2. Applications no longer know an address they can be reached at without outside help.
+   Chosen port numbers may or may not be used by the NAT.
+   The effective IP address and port are not knowable without observing from an outside peer.
+3. Filtering and mapping approaches both vary, and it's not generally possible to establish a connection without testing several alternatives and choosing the one that works.
+   This is the reason ICE exists, but it's also a possible anonymity hazard.
+
+We can use the constraints of NAT both to understand application behavior and to model Tor's behavior as a type of NAT.
+In fact, Tor's many exit nodes already share similarity with some types of carrier-grade NAT.
+Applications will need to assume very little about the IP address their outbound UDP originates on, and we can use that to our advantage in implementing UDP for Tor.
+
+TODO: More specifics here, more references.
+
+TODO: Maybe a whole section on the anonymity hazards from ICE. Not just the IP leak, but also the simultaneous sends on different interfaces.
+
+## Common Protocols
+
+Applications that want to use UDP are increasingly making use of higher-level protocols to avoid creating bespoke solutions for problems like NAT traversal, connection establishment, and reliable delivery.
+
+We will analyze how these protocols affect Tor's UDP traffic requirements.
+
+### QUIC
+
+RFC9000 defines QUIC, a multiplexed secure point-to-point protocol which supports reliable and unreliable delivery. The most common use is as an optional HTTP replacement, especially among Google services.
+
+QUIC does not normally try to traverse NAT; as an HTTP replacement, the server is expected to have a routable address.
+
+TODO: Look closer at the NAT rebinding attack described in the RFC, check how applicable that is for us.
+
+TODO: Is it a problem that NAT traversal plus QUIC effectively lets folks run a clearnet QUIC server on an exit node's IP?
+
+### WebRTC
+
+WebRTC is a large collection of protocols tuned to work together for media transport and NAT traversal.
+It is increasingly common, both for browser-based telephony and for peer to peer data transfer.
+Non-browser-based apps often implement WebRTC or have components in common with WebRTC.
 
-With most (all?) IP stacks, a UDP socket can either be _connected_ to a
-remote address:port (in which case all messages will be sent to that
-address:port, and only messages from that address will be passed to the
-application), or _unconnected_ (in which case outgoing messages can be
-sent to any address:port, and incoming messages from any address:port
-will be accepted).
+See RFC7734, RFC8825, RFC8445, RFC5389, others.
 
-In this version of the protocol, we support only _connected_ UDP
-sockets, though we provide extension points for someday adding
-_unconnected_ socket support.
+TODO: Organize and expand references here.
+
+Of particular importance to us, WebRTC uses the Interactive Connection Establishment (ICE, RFC8445, RFC8838) protocol to establish a bidirectional channel between endpoints that may or may not be behind a NAT with unknown configuration.
+
+TODO: More about the specifics of how ICE effects us. More about privacy concerns.
+
+## Common Applications
+
+Some applications we've analyzed, in alphabetical order.
+
+### BitTorrent
+
+TODO: Analyze this (Incompatibility, abuse potential)
+
+### BigBlueButton
+
+TODO: Need to test. (probably in a similar boat to Jitsi)
+
+### 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
+```
+
+## Malicious traffic
+
+TODO: Various kinds of traffic we want to avoid
+
+- Amplification attacks against arbitrary target (protocol contains reply addr, like SIP)
+- Amplification attacks against exit relay (similar to attacks against NAT)
+- Malicious fragmented traffic
+- Excessive sends to a host that has never replied (DoS)
+- Excessive number of peers (makes port scanning too much easier)
 
 
 # Tor protocol specification
@@ -63,6 +394,8 @@ _unconnected_ socket support.
 
 ## Overview
 
+TODO
+
 We reserve three new relay commands: `CONNECT_UDP`, `CONNECTED_UDP` and
 `DATAGRAM`.
 
@@ -115,6 +448,8 @@ can be mixed on the same circuit, but not on the same stream.
 
 ## Discussion on "too full"
 
+TODO
+
 (To be determined!  We need an algorithm here before we implement, though
 our choice of algorithm doesn't need to be the same on all exits or for
 all clients, IIUC.)
@@ -188,6 +523,8 @@ cell.
 
 ### CONNECT_UDP
 
+TODO: Source port cookie, if we choose to have multiple streams per source port. (Under discussion still; see below) Flags for transmit/receive allowed.
+
 ```
 /* Tells an exit to connect a UDP port for connecting to a new target
    address.  The stream ID is chosen by the client, and is part of
@@ -220,6 +557,8 @@ cell behave with regards to the hostname given.
 
 ### CONNECTED_UDP
 
+TODO: Do we need this at all? If a NAT is involved the info won't be correct. Even if it's correct, existing apps (connected via a VPN) wouldn't be able to make use of it. They would still talk to a STUN server. Do we care about UDP apps written directly to the Arti API? Are there non-malicious uses for this?
+
 A CONNECTED_UDP cell sent in response to a CONNECT_UDP cell has the following
 format.
 
@@ -242,6 +581,8 @@ the cell is considered malformed.
 
 ### DATAGRAM
 
+TODO: This would need an additional byte or two of 'peer ID' if we choose to implement streams as 1:1 with local port allocations. This is still being discussed and a conclusion hasn't been reached, see below.
+
 ```
 struct datagram_body {
    /* The datagram body is the entire body of the message.
@@ -256,8 +597,14 @@ We explicitly allow all END reasons from the existing Tor protocol.
 
 We may wish to add more as we gain experience with this protocol.
 
+TODO: What does it mean for a stream to end here? This depends on how we choose to do port allocations, which needs more discussion. Should the stream lifetime and port allocation lifetime match, or should there be a separate timer system?
+
 ### Extensions for unconnected sockets
 
+TODO: This is flawed, the "connected/unconnected" idea is just a UNIX'ism and we should be thinking about streams and about how we allocate source ports. Also, limiting connections to a single peer breaks 100% of P2P connections, since they require using STUN (or similar) first.
+
+TODO: Right now beth and mike have different ideas for how this could work, and we need to discuss more.
+
 Because of security concerns I don't suggest that we support unconnected
 sockets in the first version of this protocol.  But _if we did_, here's how
 I'd suggest we do it.
@@ -307,6 +654,8 @@ their exit policies did not say so.
 
 # MTU notes and issues
 
+TODO: Revise this section. Nearly everything assumes the MTU is larger, and we are driving this design based on app compatibility.
+
 Internet time.  I might have this wrong.
 
 The "maximum safe IPv4 UDP payload" is "well known" to be only 508 bytes
@@ -324,13 +673,13 @@ restrict their datagram size to fit into a transport this small.
 we'll probably be breaking a bunch of stuff, and creating a great deal
 of overhead.)
 
-
 # Integration issues
 
 I do not know how applications should tell Tor that they want to use this
 feature.  Any ideas?  We should probably integrate with their MTU discovery
 systems too if we can.  (TODO: write about some alternatives)
 
+TODO: "Application" here being the VPN or the end-user app? We've discussed having a per-app opt-in for UDP, enforced at the VPN layer.
 
 # Resource management issues
 
@@ -343,6 +692,8 @@ idea?
 
 # Security issues
 
+TODO: update this
+
 - Are there any major DoS or amplification attack vectors that this
   enables? I *think* no, because we don't allow spoofing the IP
   header. But maybe some wacky protocol out there lets you specify a