Some more on NAT behavior, some application notes

1 files changed, 77 insertions, 9 deletions

diff --git a/proposals/339-udp-over-tor.md b/proposals/339-udp-over-tor.md
index 289e962..3415890 100644
--- a/proposals/339-udp-over-tor.md
+++ b/proposals/339-udp-over-tor.md
@@ -83,8 +83,9 @@ Every datagram sent or received on the socket may have a different peer address.
 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.
+RFC4787 and later RFC7857 offer best practices for implementing NAT.
+Carrier-grade NAT requirements are addressed by RFC6888.
+RFC8445 describes the Interactive Connectivity Establishment (ICE) protocol, which has become a common and recommended application-level technique for building peer to peer applications that work through NAT.
 
 There are multiple fundamental technical issues that NAT presents:
 
@@ -99,13 +100,78 @@ There are multiple fundamental technical issues that NAT presents:
 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.
+We can use the constraints of NAT both to understand application behavior and as an opportunity 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.
+This body of IETF work is invaluable for understanding the scope of the problem and for defining common terminology.
+We must take inspiration from these documents while also keeping in mind that the analogy between Tor and a NAT is imperfect.
+For example, in analyzing Tor as a type of carrier-grade NAT, we may consider the "pooling behavior" defined in RFC4787: the choice of which external addresses map to an internal address.
+Tor by necessity must carefully limit how predictable these mappings can ever be, to preserve its anonymity properties.
+A literal application of RFC6888 would find trouble in REQ-2 and REQ-9, as well as the various per-subscriber limiting requirements.
+
+Some edge cases must be carefully considered.
+RFC4787 defines a framework for understanding the behavior of NAT by analyzing both its "mapping" and "filtering" behavior separately.
+Mappings are the NAT's unit of state tracking.
+Filters are layered on top of mappings, potentially rejecting incoming datagrams that don't match an already-expected address.
+Both RFC4787 and the demands of peer to peer applications make a good case for always using an "Endpoint-Independent Mapping".
+
+Choice of filtering strategy is left open by the BEHAVE-WG recommendations.
+RFC4787 defines three types with different properties, and does not make one single recommendation for all circumstances.
+We can gain some additional insight by looking at requirements that come from outside RFC4787.
+
+- **Endpoint-Independent Filtering** allows incoming datagrams from any peer once a mapping has been established.
+  
+  RFC4787 recommends this approach, with the concession that it may not be ideal for all security requirements.
+  
+  In the context of Tor, we can likely rule out this technique entirely.
+  It makes traffic injection attacks possible from any source address, provided you can guess the UDP port number used at an exit.
+  It also makes possible clearnet hosting of UDP servers using an exit node's IP, which may have undesirable abuse properties.
+  
+  It precludes "Port overlapping" behavior as defined in RFC7857 section 3, which may be necessary in order to achieve sufficient utilization of local port numbers on exit nodes.
+  
+  It is still common for present-day applications to *prefer* endpoint-independent filtering, as it allows incoming connections from peers which cannot use STUN or a similar address fixing protocol.
+  Choosing endpoint-independent filtering would have *some* compatibility benefit, but among modern protocols which use ICE and STUN there would be no improvement.
+  The cost, on the other hand, would be an uncomfortably low-cost traffic injection attack and additional risks toward exit nodes.
+
+- **Address-Dependent Filtering**
+
+  This is a permitted alternative according to RFC4787, in which incoming datagrams are allowed from only IP addresses we have previously sent to, but any port on that IP may be the sender.
+
+  The intended benefits of this approach would be:
+  
+  - To support a class of applications that rely on, for a single local port, multiple remote ports achieving filter acceptance status when only one of those ports has been sent a datagram.
+    We are currently lacking examples of applications in this category.
+    Any application using ICE will be outside this category, as each port would have its own connectivity check datagrams exchanged in each direction.
+
+  - To support peers using firewalls that are not compliant with RFC4787. This claim from the spec:
+  
+    ```
+      However, if NAT-A uses Endpoint-Independent Filtering
+      or Address-Dependent Filtering, ICE will ultimately find
+      connectivity without requiring a UDP relay.
+    ```
+
+    TODO: Is this actually true? I haven't worked out how port-independent filtering is what makes this succeed.
+
+  One security hazard of address-dependent and non-port-dependent filtering, identified in RFC4787, is that a peer on a NAT effectively negates the security benefits of this host filtering.
+  In fact, this should raise additional red flags as applied to either Tor or carrier grade NAT.
+  If we are intending to support peer to peer applications, it should be commonplace to establish UDP flows between two tor exit nodes.
+  When this takes place, non-port-dependent filtering would then allow anyone on Tor to connect via those same nodes and perform traffic injection.
+  The resulting security properties really become uncomfortably similar to endpoint-independent filtering.
+
+- **Address and Port-Dependent Filtering**
+
+  This is the strictest variety of filtering, and it is an allowed alternative under RFC4787.
+  It provides opportunities for increased security and opportunities for reduced compatibility, both of which in practice may depend on other factors.
+
+  For every application we've analyzed so far, port-dependent filtering is not a problem.
+  Usage of ICE will open all required filters during the connectivity check phase.
+
+  This is the only type of filtering that provides any barrier at all between cross-circuit traffic injection when the communicating parties are known.
+
+RFC4787 recommends that filtering style be configurable.
+We would like to implement that advice, but we are also looking for opportunities to make design decisions that give us the best network and end-user behaviors.
 
 ## Common Protocols
 
@@ -121,8 +187,6 @@ QUIC does not normally try to traverse NAT; as an HTTP replacement, the server i
 
 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.
@@ -147,7 +211,11 @@ TODO: Analyze this (Incompatibility, abuse potential)
 
 ### BigBlueButton
 
-TODO: Need to test. (probably in a similar boat to Jitsi)
+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