From 759f97875b3789469d64f07aadf7b50e0dc32283 Mon Sep 17 00:00:00 2001 From: Micah Elizabeth Scott Date: Wed, 10 Jan 2024 10:52:22 -0800 Subject: 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. --- proposals/XXX-udp-app-support.md | 18 +++++------------- 1 file 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. -- cgit v1.2.3-54-g00ecf