Re: [tor-bugs] #30992 [Core Tor/Tor]: circpadding: Circsetup machines give out warnings when client-side intro gets NACKed

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs