#30992: circpadding: Circsetup machines give out warnings when client-side intro gets NACKed ----------------------------------------+---------------------------------- Reporter: asn | Owner: mikeperry Type: defect | Status: assigned Priority: Medium | Milestone: Tor: | 0.4.1.x-final Component: Core Tor/Tor | Version: Tor: | 0.4.1.1-alpha Severity: Normal | Resolution: Keywords: wtf-pad circpad 041-should | Actual Points: Parent ID: | Points: 0.4 Reviewer: | Sponsor: ----------------------------------------+----------------------------------
Comment (by mikeperry): I am most concerned about the second case in comment:7. The other two cases are degenerate and the machines were shutting down anyway. Possible fixes include: 1. Add a sequence number, packet number, or padding machine instantiation counter to the commands, so we can appropriately match the most recent ones. This requires a new padding protocol version. We can use the field's absence to mean "yolo, accept it always" because this bug is not that severe. 2. Not start up a machine until the STOP response comes back from the previous one. I don't especially like 2. The optimization that got us into this mess is supposed to let us immediately replace one machine with another depending on circuit conditions. That should include tearing the same machine down and spinning it back up in succession. I think that leaves option 1: a sequence number check of some kind. Any other ideas? -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30992#comment:11> 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