Opened 9 years ago

Closed 2 years ago

#1774 closed task (wontfix)

how much of exit policies can we squeeze into microdescriptors?

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Current server descriptors have full-fledged exit policies -- they can describe not just ports but also IP addresses and netmasks.

The new microdescriptor design (#1748) uses the idea from proposal 141 of just summarizing the ports from the exit policy, to compress things better.

But the problem is that we lose some functionality here.

So the first step is: what functionality exactly do we lose? Exit enclaving? More precise control over what websites you'll reach? We should make a list so we know what we're trading off.

The second step is: how much information can we salvage and put back into the p lines? I imagine a lot of the problem is that when we're fetching microdescriptors one at a time, the current exit policies compress poorly. There are several idioms (like rejecting all internal networks, and rejecting our own IP address) that we could denote very compressedly. How bad is it if we do the exit summary for all the ones that we can, and include more precise policy lines only for the relays that set unusual lines?

Backward compatibility if we add new shorthand will be exciting. I'm not sure how much of a hassle it will be, say if we make a change down the road where everybody has six new reject netmask lines in their default exit policy. We could certainly complexify things by defining our shorthand in an exit-policy-option-list or something, so it's all extensible, but that may just be a big hassle. I don't want us to design the complexifieder version for Sep2010.

Child Tickets

Attachments (1) (4.4 KB) - added by nickm 9 years ago.
script to analyze the exit policies in your cache and see how weird they are

Download all attachments as: .zip

Change History (9)

Changed 9 years ago by nickm

Attachment: added

script to analyze the exit policies in your cache and see how weird they are

comment:1 Changed 9 years ago by nickm

What we lose:

We lose exit enclaving, but almost nobody uses it. Looking at the desriptors in my cache, we have ONE that does accept "$my_ip/32:anything," and many that do "reject $my_ip/32:*". Further, thanks to having to resolve addresses before you use them, most users wouldn't have wound up with an exit enclave anyway. If we want exit enclaving to work in the future, that's a good goal, but it doesn't work so well and isn't much used now.

[Here and in the rest of this message, I'm using a definition of "exit" == "Has at least one accept *:port entry." You can reproduce my findings with the script I'll attach with this.)

We won't miss private network support, since connecting to private networks never made sense unless you specified an address explicitly.

We lose the ability to say "I reject nearly everything on port X, except for these addresses" in such a way that clients will use it without being told to do so explicitly. Right now 6 exits in my cache seem do that: che (2 addresses), NSAFortMeade (27), lapiste (19), PotatoPalace (34), blahblahblah (2), and brazoslink (1).

We lose the ability to say "Don't even bother trying to connect to this single address X from me" in a way that clients won't try. (Arguably, since clients need to DNS lookup, we never had this ability in a reliable way.) 22 exits in my cache do this.

Finally, we lose the ability for exits to tell clients in advance that they do (or don't) support big carve-outs of IP space with a portmask other than /32 and /0. The clients need to connect, fail, and find out if reject lots of weird carve-outs... and if we accept lots of weird carve-outs, clients might never try at all. There are right now only 27 exits that reject portions of netspace, and only 5 that accept portions of netspace.

comment:2 Changed 8 years ago by arma

On the one hand, we could look at the rarity of these exit policies as a reason why we can remove the options.

On the other hand, we could look at this rarity as a reason why there would be little overall increase in overhead if we put the exceptions into microdescriptors.

So: what is the increase in total size of microdescriptor set if we put back the exception lines?

One problem that comes to mind is that most relays reject their own IP address, and many relays change IPs once a day, so their microdescriptor would thus change daily when it otherwise doesn't need to. That's a big argument against.

comment:3 Changed 8 years ago by nickm

Milestone: Deliverable-Sep2010Tor: 0.2.3.x-final

Looks like the right move here is to look into more expressive summary methods, and see if we can come up with anything that regains the lost functionality without making microdescs horribly bloated.

comment:4 Changed 8 years ago by nickm

Parent ID: #1748

comment:5 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

Changes are not likely to get designed and implemented here by the appropriate 0.2.3.x deadlines.

comment:6 Changed 7 years ago by nickm

Keywords: tor-client added

comment:7 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:8 Changed 2 years ago by nickm

Resolution: wontfix
Severity: Normal
Status: newclosed

In practice, this does not seem to have caused us actual issues. Closing.

Note: See TracTickets for help on using tickets.