Network transparent XS services - limitations and alternatives

[Martin Langhoff]

Discussing the activity installer/updater control panel and
olpc-update (a few days before) one design assumption from the XO team
was very strong: that network clients on the XO could just ignore the
XS and attempt direct connections to the desired host and service. If
the XS is there, the logic goes, it will transparently intervene.

   In this scenario, the XS is a magic MITM.

I agreed - even though I know that most TCP/IP protocols don't really
work that well, at least we could fake it with HTTP, in the great
tradition of transparent HTTP proxies.

In fact, the XS does ship with a Squid set to be a transparent proxy
(plus the required fw rules). Add jesred or something similar, and we
are sorted.

Alas, working more on this. it turns out we cannot do this in a sane
way. The magic MITM approach has a *lot* of problems

 - Limited to a few protocols. HTTP works. HTTPS does not.

 - At the protocol layer you mask a whole host:proto - not specific
resources, unless you have a very smart proxy. In the case of HTTP, we
can use squid+jesded to serve locally "just" some urls.

 - Clients still perform DNS lookups and attempt to establish direct
connections. This breaks really badly in disconnected scenarios - DNS
does not resolve, so the client will never request the URL via the
proxy. We can serve fake DNS names pointing to the XS, but that is
very ugly hack with innumerable downsides.

Providing a "local activities installation service" for
sugar-update-control is a good example. s-u-c can be told via a config
file to look for a particular url, and the intention - as discussed
with Scott - was to use the same URL for connected and disconnected
schools. However, it just does not work in disconnected schools unless
we completely fake DNS because the client wants a DNS entry for it.

So this is a heads up - in summary

   We cannot assume network transparency on XS services.

I don't yet have a definite plan for this, but here are the tracks I
will be exploring

 - For HTTP-based stuff we may be able to retain some transparency
   - If clients obey http_proxy :-) - Gecko does not, so it will have
to be set somehow.
   - If we can get http proxy settings via DHCP or something hackish like WPAD
   - Do HTTP clients using a proxy do not perform DNS lookups? My
understanding is that they do not, but I am not 100% certain of
whether this is specified, and how actual clients behave.

 - For !HTTP networking, we need to plan for XS-aware behaviour when
we are in the school network. If we can make it generic as well as
useful, even better.

 - We need a stable flag on the XO that indicates whether we are on an
XS network or not. Or perhaps a per-service flag for services where it
matters. Right now the Telepathy infra is doing some of this.

Overall, this is somewhat disappointing, but it is part of how the
network protocols we use are designed. Or rather - how they are *not*
designed to make a smart MITM easy (or even feasible) to implement.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff