[tor-bugs] #9166 [Tor]: Write a UTP-based channel implementation

[Tor Bug Tracker & Wiki]

#9166: Write a UTP-based channel implementation
---------------------------+------------------------------------------------
 Reporter:  nickm          |          Owner:                  
     Type:  defect         |         Status:  new             
 Priority:  normal         |      Milestone:  Tor: unspecified
Component:  Tor            |        Version:                  
 Keywords:  tor-relay utp  |         Parent:  #9165           
   Points:                 |   Actualpoints:                  
---------------------------+------------------------------------------------

Comment(by nickm):

 As I understand it, the branch today works by adding a UTP connection "on
 the side" of every or_connection_t.  Whenever an OR connection is
 launched, so is a corresponding UTP connection.  The branch seems to want
 to use TLS for initial key setup, and does not appear to do encryption on
 the UTP connections yet.

 I think that's going to be good enough for simulation, though: the setup
 characteristics are going to be significantly different than you'd see in
 a more polished implementation, but the throughput characteristics will be
 accurate (modulo the effects of no crypto).

 For a polished, mergeable version here, I would want to see:
   * A proposal.
   * IPv6 support
   * An actual UTP-based channel, advertised in descriptors and
 microdescriptors, and implemented as its own channel_t implementation.
   * Integration with the bandwidth accounting and rate-limiting features
 in the rest of Tor.
   * Resolution for the issues noted below.
   * Encryption, obviously.  This could be with TLS-over-UTP, or something
 different.

 More fine-grained issues:

 816abfac378f979d718782e17c5185c1dba43f24     Add a uTP connection in
 parallel to the channel:

  * Got to comment the new functions, if that doesn't happen.
  * It needs rate-limiting to work somehow.
  * need to avoid magic-numbers for inet_ntop buffer lengths.
  * remove magic-address 128.232.10.129
  * needs to bind something other than INADDR_ANY.
  * autoconf needs to check for utp, make it optional
  * Cast "userdata" to channel_tls_t in a local variable; don't say
 ((channel_tls_t*)userdata) more than once per function.

 b1b18889cd4986a2d10e79137f99a9ad46006f08 -- Handle uTP reads using
 libevent

  * check all return values.

 97aa42e4f235015ebd715ba673c475c978c48e67 -- Write payload data to uTP
 connection

   * utp_is_writable should get checked.  Also, it looks like
 connection_or_write_cell_to_buf doesn't make sense when
 tlschan->utp_write_buf is actually successful.

 67589c6b4f036ca73b49135cf5f7ec5a708dce73 --     Tie up incoming uTP
 connections with the TLS counterpart

   * Aw geez.  it's using the TLS master key as some kind of key material
 for the UTP session.  That's pretty darned kludgy.  I'd really want a key
 derivation function in there at least.
   * It doesn't appear anything uses the TLS master key though.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9166#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online