Re: [tor-bugs] #30365 [Core Tor/Tor]: prop289: Update tor-spec.txt with authenticated SENDME spec

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

#30365: prop289: Update tor-spec.txt with authenticated SENDME spec
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  task                                 |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.1.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-spec, prop289, sendme,           |  Actual Points:  0.2
  041-should                                     |
Parent ID:  #26288                               |         Points:  0.2
 Reviewer:  nickm                                |        Sponsor:
                                                 |  SponsorV
-------------------------------------------------+-------------------------
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 This mostly lgtm but I would like Roger to have a look at it before we
 merge, since he's likeliest to remember anything that it gets wrong about
 the flow control algorithm.

 There are a few points where I would like clarification:

 1.
 {{{
 +   Note that these limits do NOT apply to cells that tor receives from
 one
 +   host and relays to another. Circuit-level flow control is end-to-end
 so
 +   both ends track these windows, never the middle points.
 }}}
 This text above is a little misleading. Because of our leaky pipe
 topology, ''every'' relay on the circuit has a pair of windows, and the OP
 has a pair of windows for every relay on the circuit.  These windows do
 not apply to relayed cells, however, and a relay that is never used for
 streams will never decrement its window or cause the client to decrement a
 window.

 2.
 {{{
 +   An OR or OP (depending of the stream direction), is willing to receive
 more
 +   cells when its deliver window goes down below a full increment (100).
 For
 +   example, if the window started at 1000, it should send a RELAY_SENDME
 when
 +   it reaches 900.
 }}}
 Instead of saying "is willing" I'd suggest saying "sends a RELAY_SENDME
 cell to indicate that it is willing".

 3.
 {{{
 +         The DIGEST is the rolling digest value from the cell that
 immediately
 +         preceded this RELAY_SENDME. This value is matched on the other
 side
 +         from the previous cell sent that the OR/OP must remember.
 }}}
 When you say "the cell that immediately preceded", let's clarify what kind
 of cell. I think you mean "the RELAY cell on the same circuit from the
 same sender that immediately preceded", but maybe you mean only
 RELAY_DATA?

 4.
 Does anything in this text say that if you get a RELAY_DATA cell when your
 deliver window is 0, you should kill the circuit?  If not, it should.

 5.
 Also, a suggestion:
 {{{
 -Author: Rob Jansen, Roger Dingledine
 +Author: Roger Dingledine, David Goulet, Rob Jansen
 }}}
 Sometimes people in academia try to send important social signals through
 author ordering. Please check with Rob and Roger before re-ordering the
 authors here.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30365#comment:4>
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