#22934: PADDING cells can't be sent immediately after a VERSIONS cell ---------------------------------+------------------------------------ Reporter: teor | Owner: nickm Type: defect | Status: accepted Priority: Medium | Milestone: Tor: 0.3.1.x-final Component: Core Tor/Tor | Version: Tor: 0.3.1.1-alpha Severity: Normal | Resolution: Keywords: tor-spec, tor-relay | Actual Points: Parent ID: #18856 | Points: 0.5 Reviewer: | Sponsor: ---------------------------------+------------------------------------ Changes (by nickm):
* owner: (none) => nickm * status: new => accepted Comment: So, two issues here: "can this happen on clients that are doing padding" and "what behavior should we allow"? I am fairly confident that the answer to the first question is "no". The function `channelpadding_send_padding_cell_for_callback()` is where the code sends its cells, and it is always checks whether the channel state is CHAN_STATE_OPEN. We only set the channel to that state when the OR connection enters OR_CONN_STATE_OPEN. The same check is performed in channelpadding_decide_to_pad_channel(). So we won't trigger this today from the channel padding code. Hooray! So, what _should_ we be doing? It's sure desirable to allow PADDING and VPADDING after the VERSIONS cell, but we can't actually do that until some Tors allow it, and we need some means to signal that they will. I suggest that for 0.3.2, we just fix the spec to note that this doesn't work, and for 0.3.3 we write a proposal and implement it. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22934#comment:4> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs