Facilitator: remember client registrations

The flash proxy facilitator forgets a client registration after giving it to a proxy. If the client wants another proxy, it has to register again. This strains the assumption that (covert, low-bandwidth) client registrations have to be done infrequently. Rather, the facilitator should make an educated guess as to how long a client address still needs service. Ideally, a client need register only once per Tor session.

added archived-closed-2018-07-04 component::archived/flashproxy owner::dcf parent::10711 priority::high resolution::wontfix severity::normal status::closed type::task labels

In https://crypto.stanford.edu/flashproxy/flashproxy.pdf, we describe a system where the facilitator keeps track of how many proxies are serving a particular client. It seeks to provide each client with some number (say, 5) simultaneous proxies. If all known clients are fully satisfied, then newly arriving proxies get nothing.

This is hard to do using our current facilitator protocol because the information about which proxies are serving which clients is not made explicit. The facilitator may assume, for example, that a proxy to which it has given a particular client will continue to serve that client until the proxy or the client goes offline. The facilitator can sense when a proxy goes offline when it stops polling. It doesn't know when a client goes offline, except by estimating it by a reasonable timeout, or by receiving a message from a proxy saying "I wasn't able to connect to this client."

I did some experiments using a model like this. I implemented a "done" message from the proxy to explicitly indicate when it had stopped serving a particular client. What I found was that there were some old long-running proxies that didn't send the "done" message. If they got a client address and failed to connect for some reason, they would never report the failure, and in effect would permanently uselessly occupy one of the 5 proxy slots for that client. When this happened 5 times, the client was cut off from getting service. This denial of service wasn't even using malicious proxies, just old ones, so a mroe robust model is needed.

I have thought about having the proxies, in their poll messages, sending a list of the clients they are currently serving. The facilitator can read this list and check that it matches its own idea of reality (and deny proxies that seem to be misbehaving). However client addresses are a kind of sensitive information: though we hand them out to any proxy that asks, it should still be hard for someone to find out all of them. I don't like the idea of sending them in cleartext in a repeating poll message. #5425 (closed), which is partially about using a real web server with TLS for these messages, reduces this risk.

Trac:
Priority: normal to major

Trac:
Parent: N/A to #10711 (closed)

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

Close all tickets in archived components

Trac:
Resolution: N/A to wontfix
Keywords: N/A deleted, archived-closed-2018-07-04 added
Status: new to closed

closed

mentioned in issue #6330 (closed)

mentioned in issue #7167 (moved)

mentioned in issue #9964 (closed)