Transporting UDP-based protocols through an exit node would require significant design and implementation effort for an ‘exit policy’ for each UDP-based protocol that is to be supported.
Transporting UDP-based protocols cannot provide a performance improvement unless relays are permitted to reorder and/or drop cells. This would make end-to-end tagging attacks much easier (they would no longer be limited to relays), and would be incompatible with Tor's current relay crypto and the currently proposed new relay crypto protocols.
Transporting UDP-based protocols cannot provide a performance improvement unless relays are permitted to reorder and/or drop cells. This would make end-to-end tagging attacks much easier (they would no longer be limited to relays), and would be incompatible with Tor's current relay crypto and the currently proposed new relay crypto protocols.
For me, the most important argument for transmitting UDP over Tor is that it would support existing UDP-based protocols and applications. I think that would be useful even without a performance improvement. Would it be safe (as safe as Tor's existing support of TCP streams) to transmit UDP datagrams between guards and exit nodes if the reordering or dropping of cells were not permitted?
Transporting UDP-based protocols cannot provide a performance improvement unless relays are permitted to reorder and/or drop cells. This would make end-to-end tagging attacks much easier (they would no longer be limited to relays), and would be incompatible with Tor's current relay crypto and the currently proposed new relay crypto protocols.
For me, the most important argument for transmitting UDP over Tor is that it would support existing UDP-based protocols and applications. I think that would be useful even without a performance improvement. Would it be safe (as safe as Tor's existing support of TCP streams) to transmit UDP datagrams between guards and exit nodes if the reordering or dropping of cells were not permitted?
I'm not certain how this will work on the exit end, and it seems a bit nightmarish at a first glance. How many exits would be comfortable not only letting the tor process bind to arbitrary UDP ports, but accepting inbound UDP traffic from what essentially would be the entire Internet to said arbitrary UDP ports (Behavior that's different from this would be possible, but would likely require work on the client side).
And how would congestion control work? What's to stop someone from causing the outbound link on the exit end to collapse due to congestion by having it spit out UDP packets as fast as it can?
Calling this wontfix for now: that doesn't mean "never" but it means "not any time soon".
It remains on our radar, but there's no real work to track here. The big problem is that supporting arbitrary IP traffic in a meaningful way would require fundamental research improvements in onion routing-style anonymity networks, if we want to actually anonymize the IP traffic and the computer generating it.
Probably the best way to more forward here is not on trac, but in the research literature and/or a series of design proposals or tor-dev threads.
Trac: Status: new to closed Resolution: N/Ato wontfix