mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-24 04:13:28 +01:00
clean up my microdescriptors proposals now that i've slept on it
svn:r18171
This commit is contained in:
parent
1c70922491
commit
18eba0073d
@ -13,14 +13,16 @@ Status: Open
|
||||
circuit-building protocol to fetch a server descriptor inline at each
|
||||
circuit extend, we instead put all of the information that clients need
|
||||
either into the consensus itself, or into a new set of data about each
|
||||
relay called a microdescriptor.
|
||||
relay called a microdescriptor. The microdescriptor is a direct
|
||||
transform from the relay descriptor, so relays don't even need to know
|
||||
this is happening.
|
||||
|
||||
The goal is that descriptor elements that are small and frequently
|
||||
changing should go in the consensus itself, descriptor elements that
|
||||
are small and relatively static should go in the microdescriptor,
|
||||
and if we ever end up with descriptor elements that aren't small yet
|
||||
clients need to know them, we'll need to resume considering some design
|
||||
like the one in proposal 141.
|
||||
Descriptor elements that are small and frequently changing should go
|
||||
in the consensus itself, and descriptor elements that are small and
|
||||
relatively static should go in the microdescriptor. If we ever end up
|
||||
with descriptor elements that aren't small yet clients need to know
|
||||
them, we'll need to resume considering some design like the one in
|
||||
proposal 141.
|
||||
|
||||
2. Motivation
|
||||
|
||||
@ -37,12 +39,14 @@ Status: Open
|
||||
their votes (and thus in the consensus) what relay descriptor elements
|
||||
are included in the microdescriptor, and also list the expected hash
|
||||
of microdescriptor for each relay. Second, directory mirrors will serve
|
||||
microdescriptors. Third, clients will ask for them and then cache them.
|
||||
microdescriptors. Third, clients will ask for them and cache them.
|
||||
|
||||
3.1. Consensus changes
|
||||
|
||||
V3 votes should include a new line:
|
||||
microdescriptor-elements bar baz foo
|
||||
listing each descriptor element (sorted alphabetically) that authority
|
||||
included when it calculated its expected microdescriptor hashes.
|
||||
|
||||
We also need to include the hash of each expected microdescriptor in
|
||||
the routerstatus section. I suggest a new "m" line for each stanza,
|
||||
@ -65,10 +69,13 @@ Status: Open
|
||||
seemed like it should be relatively static, so putting it in the
|
||||
microdescriptor is smarter than trying to fit it into the consensus.)
|
||||
|
||||
We could imagine a config option "family,onion-key" so authorities
|
||||
could change their voted preferences without needing to upgrade.
|
||||
|
||||
3.1.2. Computing consensus for microdescriptor-elements and "m" lines
|
||||
|
||||
One approach is for the consensus microdescriptor-elements line to
|
||||
include all elements listed by a majority of authorities, sorted. The
|
||||
include every element listed by a majority of authorities, sorted. The
|
||||
problem here is that it will no longer be deterministic what the correct
|
||||
hash for the "m" line should be. We could imagine telling the authority
|
||||
to go look in its descriptor and produce the right hash itself, but
|
||||
@ -89,7 +96,7 @@ Status: Open
|
||||
|
||||
(If there's a tie, use the smaller hash. But really, if there are
|
||||
multiple such votes and they differ about a microdescriptor, we caught
|
||||
one of them being lying or buggy. We should log it to track down why.)
|
||||
one of them lying or being buggy. We should log it to track down why.)
|
||||
|
||||
If there are no such votes, then we leave out the "m" line for that
|
||||
relay. That means clients should avoid it for this time period. (As
|
||||
@ -110,13 +117,15 @@ Status: Open
|
||||
has a consensus from the previous period, then it should use the
|
||||
consensus preferred-microdescriptor-elements when computing its votes
|
||||
for microdescriptor-elements and the appropriate hashes in the upcoming
|
||||
period. (If it has no previous consensus, then it just puts down its
|
||||
period. (If it has no previous consensus, then it just writes its
|
||||
own preferences in both lines.)
|
||||
|
||||
3.2. Directory mirrors serve microdescriptors
|
||||
|
||||
Directory mirrors should then read the microdescriptor-elements line
|
||||
from the consensus, and learn how to answer requests.
|
||||
from the consensus, and learn how to answer requests. (Directory mirrors
|
||||
continue to serve normal relay descriptors too, a) to serve old clients
|
||||
and b) to be able to construct microdescriptors on the fly.)
|
||||
|
||||
The microdescriptors with hashes <D1>,<D2>,<D3> should be available at:
|
||||
http://<hostname>/tor/micro/d/<D1>+<D2>+<D3>.z
|
||||
@ -128,23 +137,23 @@ Status: Open
|
||||
to name every microdescriptor it's looking for.
|
||||
|
||||
The format of a microdescriptor is the header line
|
||||
"microdescriptor 1"
|
||||
"microdescriptor-header"
|
||||
followed by each element (keyword and body), alphabetically. There's
|
||||
no need to mention what hash it is, since you can hash the elements
|
||||
to learn this.
|
||||
no need to mention what hash it's for, since it's self-identifying:
|
||||
you can hash the elements to learn this.
|
||||
|
||||
(Do we need a footer line to show that it's over, or is the next
|
||||
microdescriptor line or EOF enough of a hint? A footer line wouldn't
|
||||
hurt much. Also, no fair voting for the microdescriptor-element
|
||||
"microdescriptor".)
|
||||
"microdescriptor-header".)
|
||||
|
||||
The hash of the microdescriptor is simply the hash of the concatenated
|
||||
elements -- not counting the header line or hypothetical footer line.
|
||||
Is this smart?
|
||||
Unless you prefer that?
|
||||
|
||||
Note that I put a "1" up there in the header line. It isn't part
|
||||
of what's hashed, though. Is there a way to put in a version that's
|
||||
more useful?
|
||||
Is there a reasonable way to version these things? We could say that
|
||||
the microdescriptor-header line can contain arguments which clients
|
||||
must ignore if they don't understand them. Any better ways?
|
||||
|
||||
Directory mirrors should check to make sure that the microdescriptors
|
||||
they're about to serve match the right hashes (either the hashes from
|
||||
@ -165,7 +174,8 @@ Status: Open
|
||||
|
||||
Clients maintain a cache of microdescriptors along with metadata like
|
||||
when it was last referenced by a consensus. They keep a microdescriptor
|
||||
until it hasn't been mentioned in any consensus for a week.
|
||||
until it hasn't been mentioned in any consensus for a week. Future
|
||||
clients might cache them for longer or shorter times.
|
||||
|
||||
3.3.1. Information leaks from clients
|
||||
|
||||
@ -188,11 +198,9 @@ Status: Open
|
||||
be relatively easy to do.
|
||||
|
||||
Phase two, directory mirrors should learn how to serve them, and learn
|
||||
how to read the consensus to find out what they should be serving. It
|
||||
would be great if we can squeeze this in during 0.2.1.x also, so once
|
||||
clients start to fetch them there will be many mirrors to choose from.
|
||||
|
||||
(Are there reasonable ways to build only part of phase two in 0.2.1.x?)
|
||||
how to read the consensus to find out what they should be serving. This
|
||||
phase could be done either in 0.2.1.x or early in 0.2.2.x, depending
|
||||
on how messy it turns out to be and how quickly we get around to it.
|
||||
|
||||
Phase three, clients should start fetching and caching them instead
|
||||
of normal descriptors. This should happen post 0.2.1.x.
|
||||
|
Loading…
Reference in New Issue
Block a user