[Freedombox-discuss] How decentralized is PageKite?

[Bjarni Rúnar Einarsson]

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 <dr at jones.dk> 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/