Bit more writing

1 files changed, 82 insertions, 37 deletions

diff --git a/proposals/XXX-udp-app-support.md b/proposals/XXX-udp-app-support.md
index ce30bda..350f91b 100644
--- a/proposals/XXX-udp-app-support.md
+++ b/proposals/XXX-udp-app-support.md
@@ -10,32 +10,37 @@ Status: Draft
 
 This proposal takes a fresh look at the problem of implementing support in Tor for applications which require UDP/IP communication.
 
+This work is being done with the sponsorship and goals of the [Tor VPN Client for Android project](https://gitlab.torproject.org/groups/tpo/-/milestones/32).
+
 We start out by defining how this proposal compares to previous work, and the specific problem space we are addressing.
 This leads into an analysis that references appropriate standards and proposes some specific solutions with properties we can compare.
 
 ## History
 
-There have been multiple attempts within Tor to define some type of UDP support.
-
-Proposal 100 by Marc Liberatore in 2006 suggested a way to "add support for tunneling unreliable datagrams through tor with as few modifications to the protocol as possible." This proposal extends the existing protocol with a DTLS link mode alongside the existing TLS+TCP. The focus of this work was on a potential way to support unreliable traffic, not necessarily on UDP itself or on UDP applications.
+There have been multiple attempts already within Tor to define some type of UDP support.
 
-In proposal 100, a Tor "Stream" is used for one pairing of local and remote address and port, copying the technique used by Tor for TCP. This works for some types of UDP applications, as we detail below, but for many peer-to-peer use cases it's unhelpful to allocate local ports that can only be used with a single remote peer.
+[Proposal 100](https://spec.torproject.org/proposals/100-tor-spec-udp.html) by Marc Liberatore in 2006 suggested a way to "add support for tunneling unreliable datagrams through tor with as few modifications to the protocol as possible." 
+This proposal suggested extending the existing TLS+TCP protocol with a new DTLS+UDP link mode.
+The focus of this work was on a potential way to support unreliable traffic, not necessarily on UDP itself or on UDP applications.
 
-Furthermore, no additional large-message fragmentation protocol is defined, so the MTU in proposal 100 is limited to a one Tor cell, a value that we will see is unusably small for most applications.
+In proposal 100, a Tor *stream* is used for one pairing of local and remote address and port, copying the technique used by Tor for TCP. This works for some types of UDP applications, as we detail below, but for many peer-to-peer use cases it's unhelpful to allocate local ports that can only be used with a single remote peer.
 
-It's possible these UDP protocol details would have been elaborated during design, but this proposal hit a snag elsewhere: there was no agreement on a way to avoid causing new attacks against anonymity.
+Furthermore, no additional large-message fragmentation protocol is defined, so the MTU in proposal 100 is limited to a one Tor cell. This value we will see is unusably small for most applications.
 
-In 2018, Nick Mathewson and Mike Perry wrote this summary of the general issues with unreliable transports for Tor:
+It's possible these UDP protocol details would have been elaborated during design, but the proposal hit a snag elsewhere:
+there was no agreement on a way to avoid facilitating new attacks against anonymity.
 
-https://research.torproject.org/techreports/side-channel-analysis-2018-11-27.pdf
+In 2018, Nick Mathewson and Mike Perry wrote a 
+[summary of the side-channel issues with unreliable transports for Tor](https://research.torproject.org/techreports/side-channel-analysis-2018-11-27.pdf).
 
 TODO: Look closer at this, some of the attacks described might overlap with non-datagram-transport ways of encapsulating UDP. (i.e. a malicious exit may always cause drops/injections regardless of what the rest of the anonymity network does.)
 
-TODO: There has got to be a section here for new risks with malicious exits. Some protocols may see increased risk vs. their existing TCP fallbacks.
+[Proposal 339](https://spec.torproject.org/proposals/339-udp-over-tor.html) by Nick Mathewson in 2020 introduced a simpler UDP encapsulation design which had similar stream mapping properties as in proposal 100, but with the unreliable transport omitted. Datagrams are tunneled over a new type of Tor circuit using a new type of Tor message.
+As a prerequisite, it depends on [proposal 319](https://spec.torproject.org/proposals/319-wide-everything.html) to support messages that may be larger than a cell, extending the MTU to support arbitrarily large UDP datagrams.
 
-Proposal 339 by Nick Mathewson in 2020 introduced a simpler UDP encapsulation design which had similar stream mapping properties as in proposal 100, but with the unreliable transport omitted. Datagrams are tunneled over a new type of Tor circuit using a new type of Tor message. As a prerequisite, it depends on proposal 319 to support messages that may be larger than a cell, extending the MTU to support arbitrarily large UDP datagrams.
-
-In proposal 339 the property of binding a stream both to a local port and to a remote peer is described in UNIX-style terminology as a "connected socket". We dive deeper into this idea below and supply an alternate formulation based on RFC4787, NAT behavior requirements for UDP. This single-peer behavior would be referred to as an "endpoint-dependent mapping" in RFC4787. It works fine for client/server apps but precludes the use of peer-to-peer techniques.
+In proposal 339 the property of binding a stream both to a local port and to a remote peer is described in UNIX-style terminology as a *connected socket*. We dive deeper into this idea below and supply an alternate formulation based on [RFC4787](https://www.rfc-editor.org/rfc/rfc4787), *NAT behavior requirements for UDP*.
+The single-peer *connected socket* behavior would be referred to as an *endpoint-dependent mapping* in RFC4787.
+This type works fine for client/server apps but precludes the use of NAT traversal for peer-to-peer transfer.
 
 ## Scope
 
@@ -43,21 +48,32 @@ This proposal aims to allow Tor applications and Tor-based VPNs to provide compa
 
 We don't have a specific list of applications that must be supported, but we are currently aiming for broad support of popular applications while still respecting and referencing all applicable Internet standards documents.
 
-Changes to the structure of the Tor network are out of scope, as are specific performance optimizations. We expect to rely on common optimizations to the performance of Tor circuits, rather than looking to make specific changes to optimize for unreliable datagram transmission.
+Changes to the structure of the Tor network are out of scope, as are most performance optimizations. We expect to rely on common optimizations to the performance of Tor circuits, rather than looking to make specific changes that optimize for unreliable datagram transmission.
 
 We will discuss the design implications of UDP on onion services below.
 It's worth planning for this as a way to evaluate the design space, but in practice we are not aiming for UDP to onion services yet.
 This will require changes to most applications that want to use it, as it implies that any media negotiations will need to understand onion addressing in addition to IPv4 and IPv6.
 
 We do not rigidly define the subset of UDP traffic that will be allowed.
-There are several options discussed below using the framework of RFC4787 NAT recommendations.
+There are several options discussed below using the RFC4787 framework.
+
+We require support for DNS clients. Tor currently only supports a limited subset of DNS queries, and it's desirable to support more. This will be analyzed in detail as an application below. DNS is one of very few applications that still rely on fragmented UDP datagrams, though this may not be relevant for us since only servers typically need to control the production of fragments.
 
-We do expect support for voice/video telecommunications apps. Even without an underlying transport that supports unreliable datagrams, we expect a tunnel to provide a usable level of compatibility. This design space is very similar to the TURN (RFC8656) specification, already used very widely for compatibility with networks that filter UDP. See the analysis of specific applications below.
+We require support for voice/video telecommunications apps. Even without an underlying transport that supports unreliable datagrams, we expect a tunnel to provide a usable level of compatibility. This design space is very similar to the TURN ([RFC8656](https://www.rfc-editor.org/rfc/rfc8656)) specification, already used very widely for compatibility with networks that filter UDP. See the analysis of specific applications below.
 
-We do expect support for DNS clients. Tor currently only supports a limited subset of DNS queries, and it's desirable to support more. This will be analyzed in detail as an application below. DNS is one of very few applications that still rely on fragmented UDP datagrams, though this may not be relevant for us since only servers typically need to control the production of fragments.
+We require support for peer-to-peer UDP transfer without additional relaying, in apps that use ICE ([RFC8445](https://www.rfc-editor.org/rfc/rfc8445)) or similar connection establishment techniques.
+Video calls between two Tor users should transit directly between two exit nodes.
+This requires that allocated UDP ports can each communicate with multiple peers:
+*endpoint-independent mapping* as described by RFC4787.
+
+We do not plan to support applications which accept arbitrary incoming datagrams, for example a DNS server hosted via Tor.
+RFC4787 calls this *endpoint-independent filtering*.
+It's unnecessary for running peer-to-peer apps, and it facilitates an extremely easy traffic injection attack.
 
 # UDP Traffic Models
 
+To better specify the role of a UDP extension for Tor, we will look at a few frameworks for describing UDP applications.
+
 ## User Datagram Protocol (RFC768)
 
 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.
@@ -233,36 +249,26 @@ In alphabetical order:
 | 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
-
-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)
-
-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?
-
 # Design approaches
 
+TODO
+
 ## Datagram routing
 
+TODO
+
 ### 3rd party implementations
 
+TODO
+
 ### Hybrid approaches
 
+TODO: Idea about splitting UDP and TCP traffic. Applicable to clearnet (Tor/3rd-party split) and to onion (Exit/Rend split)
+
 ### Making room for a future Tor implementation
 
+TODO: Consider whether datagram message types could realistically carry over to a future Tor protocol that supports unrealiable delivery. Would we be building a foundation for real or is it not useful yet?
+
 ## Tunneling
 
 ### Using TURN (RFC8656) encapsulated in a Tor stream
@@ -385,4 +391,43 @@ In this approach, a single Tor stream is used for all UDP traffic.
 
   - Establish a stream as a connection to the exit relay's built-in (or configured) TURN server.
   - RFC8656 requires authentication before data can be relayed, which is a good default best practice for the internet perhaps but is the opposite of what Tor is trying to do. We would either modify the specification to relax this auth requirement, or we would provide a way for clients to discover credentials: either by fixing them ahead of time or by including them in the relay descriptor.
-  
\ No newline at end of file
+
+# Risks
+
+## Performance and compatibility regressions
+
+TODO: By implementing UDP at all, we open ourselves up to bugs and performance regressions vs any existing TCP compatibility support present in applications.
+
+## Additional 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)
+
+See also RFC 7675, on the concept of "Send consent".
+
+## Additional high-bandwidth application traffic
+
+TODO: Analyze bittorrent and friends
+
+## Additional exposure to malicious exit nodes
+
+TODO: There may be new cases where an exit node could modify or inspect UDP-tunneled traffic that would otherwise have been unavailable, e.g. by bypassing tor or by using a secure TURN-over-TLS tunnel.
+
+## Additional risks to anonymity
+
+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?
+
+## Port allocation risks
+
+TODO: Without a way to limit port allocations, exits can quickly run out.
+
+TODO: Incorporate a mitigation in the form of Port Overlapping