#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 asn): Replying to [comment:11 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. > Thanks for the investigation here. That was a good dig up of bugs. > 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. > 2. Instead of a protocol version bump, we can use the field's absence (aka "0" value) to mean "yolo, accept it always" because this bug is not that severe. > 3. Not start up a machine until the STOP response comes back from the previous one. > > I don't especially like 3. 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 admit I don't understand exactly our "machine replace" ideal behavior and what goals we have for it. Can you please expand on the above and what other goals we have here? > I think my preference is for 2, but maybe a protover bump is cleaner anyway, since we already have to mess with it for #31356, and bumping it to 2 would avoid the need for any 0.4.0 patching. I agree that '2' seems like a plausible solution here. Are the PADDING_NEGOTIATE(D) cells extensible enough to add such a thing? Or how do we go about it? Also, can you explain how the "machine counter" logic of '2' would work with multiple desynched START/STOP commands flying in the air like in comment:7 and comment:10? Would we ignore any START/STOP commands that don't correspond to our latest state? And how would that work for the issue in comment:10? Could that create more issues? -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30992#comment:12> 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