[tor-bugs] #28634 [Core Tor/Tor]: Design a first useful padding machine (hiding client-side intro/rend circuits)

[Tor Bug Tracker & Wiki]

#28634: Design a first useful padding machine (hiding client-side intro/rend
circuits)
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,        |  Actual Points:
  padding, 041-proposed, network-team-           |
  roadmap-2019-Q1Q2                              |
Parent ID:                                       |         Points:  8
 Reviewer:  mikeperry                            |        Sponsor:
                                                 |  Sponsor2
-------------------------------------------------+-------------------------

Comment (by asn):

 Replying to [comment:28 mikeperry]:
 > Replying to [comment:26 asn]:
 > > Looks good to me! I also successfuly tested that the rate limiting
 rules apply correctly, and also cannot trigger on the current machines.
 > >
 > > One last thing we might want to fix is that I've been getting spammed
 by this log message in chutney even for machines were RTT is not enabled
 (like these ones):
 > > {{{
 > > May 14 12:25:18.162 [notice] Got two cells back to back on a circuit
 before estimating RTT.
 > > }}}
 >
 > I believe this should be fixed by #29085. While optimizing to avoid
 monotime, I added a fast-path that also has the effect of avoiding the
 branch that contains this log message if the feature is disabled.
 >

 Hm, I don't think that's the case. At least in my testing I got both the
 above msg and `Circuit sent two cells back to back before estimating RTT`
 with the branch from comment:24, plus the latest #28780 and #29085.

 > Which chutney tests are you testing with and how are you doing
 verification?
 >

 I've been testing with chutney hs-v3 template. Here are some useful
 queries:
 `grep -R relay_ip net/nodes/*/*log` to find which relay got the relay-side
 IP machine
 `$ grep marked net/nodes/008c/info.log` to check that the circuits get
 closed as intended. For example:
 {{{
 $ grep marked net/nodes/008c/info.log
 May 15 17:11:34.411 [warn] Circuit 10 is not marked for close because of a
 pending padding machine.
 ...
 May 15 17:14:53.195 [info] circuit_mark_for_close_(): Circuit 3868216775
 (id: 10) marked for close at src/core/or/circuituse.c:1509 (orig reason:
 9, new reason: 0)
 }}}
 where the above is with `MaxCircuitDirtiness 3 minutes` on the client-
 side.

 > Do you think we could add something simple to the chutney tests to check
 for any obvious weirdness automatically?

 I doubt we can test this feature automatically with chutney with a simple
 mod, but I don't know chutney enough to give a comprehensive answer.

 Mike this whole thing looks good to me, apart from the annoying RTT log
 messages. Can you fix the RTT log messages, and give it a test on chutney,
 and then we can mark as merge_ready? I will check-in online at night.

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