[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:               |
-----------------------------+--------------------------

Comment (by mikeperry):

 Ok, I have pushed an updated version of the tor-dev proposal (with some
 change history) to:
 https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals
 /xxx-netflow-padding.txt?h=netflow_padding

 I also pushed new code branches that add tests and fix several issues. As
 one commit:
 https://gitweb.torproject.org/mikeperry/tor.git/commit/?h=netflow_padding-
 squashed2

 The old netflow_padding-squashed branch still preserves history, in case
 Nick wants to see the delta since last review (though it is probably
 actually larger and harder to read than the single-commit version, due to
 refactoring into channelpadding.c). I will continue to preserve history in
 netflow_padding-squashed, to ease future reviews.

 Here is a summary of the issues in the code that I'd like some input on,
 if possible. Each of these has one or more matching XXX comments in the
 patch:
  1. Still not sure if I'm setting timestamp_active_highres in the places
 that accurately reflect network activity
  2. Not sure how to best handle libevent timers. Can we check how many are
 outstanding? How? Should we remove timers in the case where traffic
 arrives before the timer expires (which eliminates the need for it), or
 will that be slower? Do we really need an auxiliary data structure?
  3. Am I actually leaking pad_event still? Do I need to free it myself in
 the callback?
  4. Am I setting has_been_used_for_nondir_circs in the right places? (And
 how/why does Chutney complete a circuit without a valid channel for it???)
  5. I still need to test this on PT bridges, to see if the is_canonical
 test fails for them.
  6. I added a ReducedConnectionPadding torrc option to reduce padding (for
 mobile users). Unfortunately, since padding is bidirectional, I don't
 currently have a way to fully disable padding that the server sends other
 than closing the OR connection earlier. With the current values, this
 should reduce the worst-case per-connection padding overhead from ~180KB
 to ~18KB (while still preventing multiple netflow records from being
 created for the duration of the shorter connection if the relay sends
 padding). Is this a problem, or a feature? The only alternative seems to
 be to create sub-fields of CELL_PADDING to communicate padding preferences
 to the relay..
  7. Do we want any more statistics (like average per-orconn padding stats)
 exported in extra-info?
  8. Karsten is still working with me to tune the rephist.c stat parameters
 for optimal information reduction.

 I think all of the other comments from nickm, Yawning, and Karsten have
 been addressed.

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