Hi,
I looked at the suggested solutions and I think there is another approach, which is much easier.
I C it's pretty easy to encapsulate UDP segments inside TCP segments. Hence there is no need to re-organize the connection logic of tor relays. Instead it should be possible to make Guards, when receiving an UDP packet, to just add a TCP header and then it goes through the normal process. The exit nodes than removed the TCP header and pass the UDP segment on.
Regards Vilgot
tor-dev-request@lists.torproject.org tor-dev-request@lists.torproject.org schrieb am Donnerstag, 25. Januar 2024 um 18:49:
Send tor-dev mailing list submissions to tor-dev@lists.torproject.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev or, via email, send a message with subject or body 'help' to tor-dev-request@lists.torproject.org
You can reach the person managing the list at tor-dev-owner@lists.torproject.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of tor-dev digest..."
Today's Topics:
- New Proposal - UDP Application Support in Tor
(Micah Elizabeth Scott)
Message: 1 Date: Thu, 25 Jan 2024 09:49:02 -0800 From: Micah Elizabeth Scott beth@torproject.org
To: tor-dev@lists.torproject.org Subject: [tor-dev] New Proposal - UDP Application Support in Tor Message-ID: 79aa2de8-1ff9-4579-b87f-ee9792e9cbb0@torproject.org
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello tor-dev folks!
Late last year I started taking a close look at what it would take to support applications on Tor which rely on UDP networking. This was originally to be based on Nick's proposal, 339-udp-over-tor.
The scope of this work so far has been specifically focused on end-user application compatibility, and excludes fundamental changes to Tor's network structure or protocols for now.
This combination of approach and scope left me with more questions than answers, so I started looking deeper into the available solutions along with their expected benefits and risks. This proposal is the result of that investigation.
Please find the text attached, or in the torspec repo as proposal #348:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/348-udp...
Unlike a typical proposal, this does not recommend any specific change to the Tor implementation. Several possible changes are presented, but ultimately the recommended approach is to use application-specific UDP relays to achieve compatibility.
Integrated approaches are also presented, where Tor does involve itself in the transit of individual datagrams. These approaches offer advantages only when they are also part of a long-term plan to offer transport features beyond those offered by TCP. Until such a plan is in-scope, specific UDP extensions cannot be offered with confidence.
I would appreciate any feedback on this proposal, whether it's about this particular shorter-term context or about longer-term plans to achieve some kind of optional unreliable transport.
Thanks for your time!
--beth
On 2/8/24 05:02, Vilgot Bergquist via tor-dev wrote:
Hi,
I looked at the suggested solutions and I think there is another approach, which is much easier.
I C it's pretty easy to encapsulate UDP segments inside TCP segments. Hence there is no need to re-organize the connection logic of tor relays. Instead it should be possible to make Guards, when receiving an UDP packet, to just add a TCP header and then it goes through the normal process. The exit nodes than removed the TCP header and pass the UDP segment on.
Thanks for looking at the proposal.
The "normal process" of sending traffic through tor does not directly involve TCP or TCP headers, nor are there boundaries preserved which would correspond to TCP segments. Individual streams are encapsulated within multiple other layers (tor streams and circuits, then TLS) before we encounter any real TCP segments.
You're describing something which would work if we were only talking about a firewall that blocks UDP, but that's not what Tor is.
-beth
On Mon, Feb 12, 2024 at 10:34:21AM -0800, Micah Elizabeth Scott wrote:
The "normal process" of sending traffic through tor does not directly involve TCP or TCP headers, nor are there boundaries preserved which would correspond to TCP segments. Individual streams are encapsulated within multiple other layers (tor streams and circuits, then TLS) before we encounter any real TCP segments.
Right -- and this is a feature in the sense that it removes a bunch of end-to-end information that would otherwise leak.
For example, if the exit relay or the destination server can look at the TCP headers that the client generates, they could examine how they are constructed and how they respond to errors to make a good guess about which operating system, and even which kernel version, the client is running.
And there are more esoteric attacks, like knowing that the rate of clock skew change is a physical characteristic of the hardware clock and then using "change in skew" (looking at the timestamp in each TCP header) as a cookie-like feature to distinguish users: https://2019.www.torproject.org/docs/faq#RemotePhysicalDeviceFingerprinting https://www.caida.org/catalog/papers/2005_fingerprinting/KohnoBroidoClaffy05... (I bet there are many more papers published after that one, but our design means we have mercifully not needed to keep up with the remote device fingerprint literature.)
--Roger
-
Micah Elizabeth Scott -
Roger Dingledine -
Vilgot Bergquist