[tor-dev] Adding a NotDir router status flag
teor2345 at gmail.com
Tue Jun 2 15:33:11 UTC 2015
> Date: Fri, 29 May 2015 14:24:33 +0300
> From: s7r <s7r at sky-ip.org>
> Signed PGP part
> Hi Matt,
> Nice to hear there's ongoing work for this proposal.
> I also see the NotDir flag as useful for migration, because for quite
> some time after prop 237 is implemented we will still have relays in
> the consensus which will have DirPort open (separate from ORPort). A
> client needs to know to make directory requests on DirPort for the
> relays with V2Dir flag, and know to make directory requests on ORPort
> for the relays which only have ORPort open and NotDir flag.
> After (hopefully) medium time we can drop the V2Dir flag (we are way
> passed from V2 directory anyway) and after longer time we can also
> drop NotDir. I guess this depends if directory requests on ORPort will
> be only implemented in new Tor releases or also backport?
It's unlikely we'd backport a feature of this magnitude - we already ran into issues (mainly with hidden services) when the authorities assumed that relays with only an ORPort would answer directory requests, but the relays weren't actually doing so.
> I guess we
> can say it's safe to drop both flags when over 95% of the relays
> respond to directory requests on ORPort. We will just need Valid flag
> to make sure we can separate the relays which try to poison directory
When relays have AccountingMax set, they disable their DirPort to maximise the bandwidth used for relaying Tor cells.
This implies that they should also ask for the NotDir flag, and refuse to
respond to directory requests on both the DirPort and ORPort. (We don't want relays that are already bandwidth-constrained receiving directory requests that we know they'll refuse - this is a waste of their bandwidth.)
Does this need to be part of prop 237?
Since the NotDir flag is still useful in with AccountingMax, we should reconsider the plan to drop NotDir in a few releases' time.
teor2345 at gmail dot com
teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the tor-dev