[tor-bugs] #1826 [Tor Relay]: Sending packets after RELAY_END

[Tor Bug Tracker & Wiki]

#1826: Sending packets after RELAY_END
-----------------------+----------------------------------------------------
 Reporter:  mwenge     |       Owner:                    
     Type:  defect     |      Status:  new               
 Priority:  normal     |   Milestone:  Tor: 0.2.2.x-final
Component:  Tor Relay  |     Version:  Tor: unspecified  
 Keywords:             |      Parent:                    
-----------------------+----------------------------------------------------

Comment(by nickm):

 Interesting!

 If these cells are getting sent after the RELAY_END  arrives at an exit
 node, they are probably coming because [case 1] they're already in the
 cell queue or [case 2] in the connection_or's outbuf.  Unless [case 3]
 data in the connection_edge's inbuf is somehow getting packaged even after
 a the RELAY_END cell arrives.

 It's also possible [case 4] that some of the cells are already in transit
 (queued somewhere between the exit node's SSL and the client's Tor) when
 the client sends the RELAY_END cell.  We can't really do anything about
 those.

 So, breaking down the cases:
 case 1: cells already on the cell_queue) We don't have a good way to
 remove cells from a circuit's cell queue now at all.  By the time they get
 there, they're encrypted and ready for delivery.  Removing them would
 throw of the circuit's stream cipher.  Furthermore, the cells are already
 packed at that point, so figuring out what streams they went with would be
 nontrivial.

 We could mitigate this by lowering how full we're willing to fill a cell
 queue with cells from streams before we stop reading from the streams.
 This might help stream fairness.  I don't know what it would do to
 performance.

 In Tor 0.2.3.x, we're going to have to change the point at which we
 encrypt cells on queues in order to implement #1479.  When we do this, we
 can revisit the possibility of removing already-queued cells for a dead
 stream.

 case 2: cells already in the connection_or's outbuf) This is way too late
 to remove the cells.

 We could mitigate this by lowering how much we're willing to fill an
 connection_or's outbuf.

 case 3: packaging cells from an exit connection even after getting a
 relay_end) That would be a bug.  If it's happening, we should fix it.

 case 4: the cells are in transit on the net) There's nothing we can do
 about that with our current protocol.

 So IMO the right thing to do is make sure that case 3 isn't happening, and
 think about what tuning we could do to mitigate 1 and 2, and whether it's
 a net win or not.

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