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

[Tor Bug Tracker & Wiki]

#30365: prop289: Update tor-spec.txt with authenticated SENDME spec
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  task                                 |         Status:
                                                 |  needs_review
 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 dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:4 nickm]:
 > 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.

 Good catch! I've actually re-used this paragraph your wrote which I think
 explains it great!

 >
 > 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".

 Fixed.

 >
 > 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?

 Yes, it is `RELAY_DATA` cell. I've clarified.

 >
 > 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.

 Added!

 >
 > 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.

 Wow! that is true lol, ordering matters for them... Ok I went in
 alphabetical order, I'll just put my name at the end, will save us all the
 troubles :). For me, this is mostly useful to know "who to contact" if any
 questions ;).


 See the fixup commit `b8b6bb938f3238e5`.

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