[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #5426 [Flashproxy]: Facilitator: remember client registrations

#5426: Facilitator: remember client registrations
------------------------+---------------------------------------------------
 Reporter:  dcf         |          Owner:  dcf
     Type:  task        |         Status:  new
 Priority:  normal      |      Milestone:     
Component:  Flashproxy  |        Version:     
 Keywords:              |         Parent:     
   Points:              |   Actualpoints:     
------------------------+---------------------------------------------------

Comment(by dcf):

 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,
 which is partially about using a real web server with TLS for these
 messages, reduces this risk.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5426#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs