[tor-bugs] #16861 [Tor]: Pad Tor connections to collapse netflow records

[Tor Bug Tracker & Wiki]

#16861: Pad Tor connections to collapse netflow records
-----------------------------+--------------------------
     Reporter:  mikeperry    |      Owner:  mikeperry
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------
Changes (by mikeperry):

 * status:  new => needs_review


Comment:

 Ok, the squashed version of my branch lives here:
 https://gitweb.torproject.org/mikeperry/tor.git/commit/?h=netflow_padding-
 squashed

 Current head is 0c29e83ede329728d4b606a9a2af1a858b517880. My plan is add
 fixup commits there and then squash again before merge.

 I've tested it on Chutney testing networks, and appears to be behaving
 fine, at least based on loglines.

 My questions are highlighted in the patch with "XXX:" comments, but here
 is also a brief summary.

 Questions for Karsten/Roger:
 1. Are the rephist.c stats enough information to graph the overhead for
 this and other padding defenses? Note that I only output exactly 24 hours
 worth of data, and no history.
 2. Do you want other stats, such as the average lifespan of client OR
 connections, in case we want to tune that aspect of the defense, too?

 Questions for Athena/Nickm:
 1. I had to create a high-res version of channel_t::timestamp_active
 (channel_t::timestamp_active_highres). Am I setting it in the right places
 to correspond to when packets are actually being sent/received on the
 channel, or should I set it elsewhere?
 2. Should I completely replace timestamp_active with my version? I had to
 remove a timestamp in channel_timestamp_drained() though, because that
 definitely could get called when no packets were actually sent.
 3. In Chutney testing networks, I sometimes saw circuits manage to open
 without a current channel. This is marked with XXX in
 circuit_send_next_onion_skin(). Is this a bug?
 4. I also had to create a channel_t::used_for_nondir_circs member to
 indicate that a channel was being used for something other than tunneled
 dirconns. Did I set this one in the right place, or is there a better
 place?

 Yawning, you're on the Cc to tell me how much my C sucks (and also answer
 any other questions above :).

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