Date: Fri, 29 May 2015 14:24:33 +0300 From: s7r s7r@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 data.
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.
teor
teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
On Wed, Jun 03, 2015 at 01:33:11AM +1000, teor wrote:
Date: Fri, 29 May 2015 14:24:33 +0300 From: s7r s7r@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.
Right. Interestingly, zero clients care about the V2Dir flag currently. It's purely a cosmetic detail of the consensus. It is useful for us, but it will be nice when Dir Auths stop voting for it.
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.
There's no need for backporting this. Old versions of Tor won't care about it.
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 data.
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?
Ah, yes, but no. It's in the implementation but not in the proposal. Good catch. I'll add this as an implementation note in the proposal.
Since the NotDir flag is still useful in with AccountingMax, we should reconsider the plan to drop NotDir in a few releases' time.
Yes, I suspect it will take a few years before enough clients and relays upgrade.
Thanks for the feedback!