Resolve TODO related to REQ-8 in RFC4787

I looked at this a bit more and I'm still not sure what specific
circumstance the claim is alluding to. I replaced the TODO with a more
permanent description of the claim as well as my skeptical take.

1 files changed, 5 insertions, 13 deletions

diff --git a/proposals/XXX-udp-app-support.md b/proposals/XXX-udp-app-support.md
index 386037f..54b0e41 100644
--- a/proposals/XXX-udp-app-support.md
+++ b/proposals/XXX-udp-app-support.md
@@ -32,8 +32,8 @@ there was no agreement on a way to avoid facilitating new attacks against anonym
 
 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.)
+The focus of this document is on the link between Tor relays, but there is considerable overlap between the attack space explored here and the potential risks of any application-level UDP support.
+Attacks that are described here, such as drops and injections, may be applied by malicious exits or some types of third parties even in an implementation using only present-day reliable Tor transports.
 
 [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 stream 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.
@@ -165,21 +165,13 @@ We can gain some additional insight by looking at requirements that come from ou
 
   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:
+  The intended benefits of this approach versus the port-dependent filtering below are unclear, and may no longer be relevant. In theory they 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.
-    ```
+    Any application using ICE should be outside this category, as each port would have its own connectivity check datagrams exchanged in each direction.
 
-    TODO: Is this actually true? I haven't worked out how port-independent filtering is what makes this succeed.
+  - REQ-8 in RFC4787 claims the existence of a scenario in which this approach facilitates ICE connections with a remote peer that disregards REQ-1 (the peer does not use **Endpoint-Independent Mapping**). It is not clear that this claim is still relevant.
 
   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.