Re: [tor-bugs] #30440 [Core Tor/Tor]: sendme: Service introduction circuit ignore flow control

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

#30440: sendme: Service introduction circuit ignore flow control
----------------------------+------------------------------------
 Reporter:  dgoulet         |          Owner:  (none)
     Type:  defect          |         Status:  new
 Priority:  High            |      Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor    |        Version:
 Severity:  Normal          |     Resolution:
 Keywords:  tor-hs, sendme  |  Actual Points:
Parent ID:  #15516          |         Points:  2
 Reviewer:                  |        Sponsor:  Sponsor27-can
----------------------------+------------------------------------

Comment (by dgoulet):

 After much discussions with armadev and asn, the ideal path forward is to
 use prop289 here.

 The service can know (with protover `FlowCtrl=1`) if the introduction
 point supports SENDME v1 and if it does, the service should then start
 emitting them on the intro circuit.

 For this to work, we need also the intro point to handle SENDME v1 which
 means decrease its `package_window` as INTRO2 cell comes in (not the
 current behavior). However, because the IP doesn't know if the service
 uses SENDME, it would only start accepting them once we switch on SENDME
 v1 in the network (`sendme_accept_min_version`) which could be some years
 down the road... But at least, in the meantime, service can start right
 now emitting SENDMEs v1 for any relay advertising `FlowCtrl=1`.

 1. There could be an argument for a new consensus param that control the
 usage of SENDMEs on the intro circuit which would be turned on much later
 since once we force that on the intro circuit, every service *NOT* sending
 SENDMEs on the circuit will stop working after 1000 cells because the
 intro point will reject anything due to flow control.

 2. Another approach is to make intro points right now start decreasing the
 package window and if it ends up to 0 and it doesn't get the SENDME at
 that point, the IP can deduce the service is not supporting it and thus we
 should continue operating like before. And this behavior will at some
 point fade out itself once every HS out there start using SENDME v1. I
 currently don't see much of a gain for a service to game this in the
 future, except maybe voluntarily allow the intro point to route a LOT of
 INTRO2 cells without flow control...? Again, we could switch off that
 feature with the consensus or simply by starting releasing a new stable
 not supporting this.

 Overall, this will introduce an information leak: the intro point will
 know that the service behind an intro circuit is >= "tor_version" ... asn
 and I aren't too worried about that since any new HS features has that
 "leak" once deployed on the network (ex: client auth).

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