[tor-bugs] #17857 [Core Tor/Tor]: Create a consensus param to disable (netflow) padding if RSOS is enabled

[Tor Bug Tracker & Wiki]

#17857: Create a consensus param to disable (netflow) padding if RSOS is enabled
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:
                                                 |  mikeperry
     Type:  enhancement                          |         Status:
                                                 |  needs_information
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.1.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, single-onion, review-        |  Actual Points:
  group-20                                       |
Parent ID:                                       |         Points:  1
 Reviewer:  dgoulet                              |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by mikeperry):

 * status:  needs_revision => needs_information


Comment:

 Replying to [comment:36 dgoulet]:
 > Wait. I have a question here before we merge this.
 >
 > Why is `channel_do_open_actions()` looking at the consensus param by
 itself but yet we have a dedicated function that updates static value with
 the param values `channelpadding_new_consensus_params()` and then we have
 `channelpadding_decide_to_pad_channel()` that basically do the checks that
 are done in `channel.c`.
 >
 > Could `channel_do_open_actions()` just use that decide function which
 would remove duplicated code and make channel ask the "padding subsystem"
 directly instead of taking decision on its own?

 Well, the decide function also will schedule and/or send padding, which we
 should not be doing upon open.. But, we could remove the channel.c checks
 entirely an rely only on the channelpadding_decide_to_pad_channel() logic
 getting called about a second after channel open.. There is some chance
 that this would mean that the relay side might send a padding packet or
 two before the client side decides to send a disable command in that case,
 but a single packet doesn't matter all that much.. If we'd rather keep
 channel_do_open_actions() short and fast for some reason, we can rip the
 checks out of it.

 Let me know what you think. I don't care either way, so long as the
 bikeshed is magenta :).

 I also need to defer testing any change to this code for a bit so I can
 test some other stuff for researchers before PETS, so if we want to change
 it again, it won't be my top priority.

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