Some of the issues your proposal describes are addressed by tor's circuitmux implementation, and by the KIST scheduler implementation. Another answer may be that TCP is a proven technology that works acceptably well for the Tor use case. It has a number of cross-platform implementations, stable interfaces, and decent security properties.
It's unclear whether your proposal is to: * replace Tor's client to relay and relay to relay TCP links with QUIC, or * allow Tor to carry arbitrary IP traffic, in addition to streams via a SOCKS proxy. These are two very different goals, they're both referred to in the proposal, but they're not described separately or prioritised. Tor likely contains a number of implementation assumptions that make arbitrary IP traffic difficult, and there are security implications in moving from a stream-based proxy to an arbitrary IP traffic proxy. And there's currently no mechanism for tor to accept arbitrary IP traffic from clients, so you'd have to build that, too. (The transparent proxy support might be a good place to start.)
Read torguts, it describes the abstraction layers within tor:
I typically use chutney for smoke tests. Others use shadow for simulations: https://shadow.github.io/Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev