Hey guys! :-) I changed the subject because we are pretty off-topic for the "what do you want to use FB for" thread.
Jonathan asked: > How resilient would the rest of the relays be if your service happened to > get taken down? Each relay stands alone, how resilient it is does not depend on my service at all. However, my users (those who use DNS names I have delegated to them) do depend on my DNS infrastructure to remain visible. People using other DNS names will depend on other DNS providers. Like the rest of the Internet. :-) But there is a twist, see below for a discussion about how things are authenticated... On Mon, May 28, 2012 at 10:35 AM, Jonas Smedegaard <[email protected]> wrote: >> Yes and no. PageKite's "central point of failure" is by design the >> exact same central point as that of the web itself: the DNS system. >> >> PageKite assumes that there are many different front-end relay servers >> available, and connections can move from one to another at any time. >> So if one relay is taken down, the website is simply routed to another >> one and DNS gets updated. This works today. > > If such rerouting happens automatic and decentralized, I agree that > there is no single point of failure. It is. The client detects that it has lots it's connection to a front-end and goes and finds another one. Currently the discovery mechanism is DNS - it looks up a DNS name and picks the best fit from a list of A (and hopefully soon AAAA) records. This mechanism could be enhanced to support other methods for discovering new front-end relays. Note that this whole thing is designed to recover from network failures and routine changes (my laptop switching networks etc.) - it not designed to resist focused attacks. In practice, PageKite services are probably easy to DDoS off the net for as long as people want, because each time you manage to trigger a fail-over, there is a period of unavailability while DNS records expire. So if you expect focused attacks, it's not going to help. But for simply making a server reachable under "normal" conditions, it works quite well and organizational/political bottlenecks (such as my little company) can be engineered around and decentralized in a relatively straightforward manner. > But if a website owner needs to explicitly pick a different pagekite > tunneling provider if the previous one stops working, then I agree with > Jonathan that pagekite becomes a central point of attack/failure. This is basically the same problem as all the other FreedomBox decentralization problems: how do you discover who is offering service? I think this is what Nick is working on, although I have not looked into how hard it would be to adapt his stuff to work with PageKite. > So how do rerouting happen? How is it assured that rerouting mechanisms > cannot be abused for hijacking? There is an challenge-response authentication protocol (piggy-backed over DNS), so the owner of foo.com can answer queries about whether someone is allowed to request PageKite tunneling for something.foo.com. Currently configuring a relay to accept traffic for a given set of domains (and configuring who handles the authentication for each) is manually specified on each front-end relay server. Maintaining the list of available front-ends in DNS is also done manually. Both of those probably need work if people want to create a community-run volunteer network of PageKite relays. (Incidentally, I'd love to work on that if I could find a way to pay the bills at the same time.) :-) Also note that updating the DNS is decoupled from the PageKite tunneling protocol - so even if you convince a front-end relay to accept your tunnel request, unless you can also update DNS records to send traffic their way, nothing much happens. -- Bjarni R. Einarsson Founder, lead developer of PageKite. Make localhost servers visible to the world: https://pagekite.net/ _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
