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