Network transparent XS services - limitations and alternatives

[Martin Langhoff]

On Wed, Aug 27, 2008 at 10:48 AM, C. Scott Ananian <cscott at laptop.org> wrote:
> On Tue, Aug 26, 2008 at 4:43 PM, Martin Langhoff
> <martin.langhoff at gmail.com> wrote:
>>> HTTPS has many problems.  None of the basic XO protocols use HTTPS.
>>
>> Will we never care for end-user privacy?
>
> We do.  We just don't use HTTPS.  You should know better.

I "should know better"? Care to explain in clear - and hopefully polite - terms?

>> *Only* for HTTP. It is a problem for rsync, hence the --server patch
>> you saw from me. And it is still a problem for HTTP as per below...
>
> The upgrade server is a good example of how to make 'cachable' rsync
> work.

And it is a valuable but very limited hack. It cannot deal with
non-top-level resources, and cannot be made to stream, which means
timeouts for the clients. In the very limited use case you have, it
works, but it very far from a being a general solution.

> Also, olpc-update should be able to use patches served over
> http in the 9.1 time frame.

Cool!

>>> But preseeding a offline DNS cache in the same way we preseed a web
>>> cache seems an entirely reasonable solution, that will allow many
>>> things to "just work".
>>
>> It will break a lot of stuff. For starters
>>
>>  - In a connected scenario, faking DNS allows us to mask something
>> like rsync, but it breaks all other services from that host. And the
>> rsync masking is all-or-nothing too, not a per-path thing.
>
> If we are connected, we should not be faking DNS.  Why would you want to do so?

If we had no  "--server" patch in olpc-update for example, I would
have to fake the DNS to make the upgrades local in school that is
connected via a slow link.

>>  - In a disconnected scenario, faking DNS affects the whole 'host'
>> entry. We just don't know what services we might be masking that may
>> not react well to being pointed at the XS.
>
> No one says the XS has to answer for a service it doesn't know about.
> Clearly, it shouldn't.

If we masked the dns name for server X, because we want to mask
service Y, as we have expensive resource Z, clients will also hit the
XS with requests for other resources and other protocols.

We may mask wiki.laptop.org to serve
http://wiki.laptop.org/go/Activities for sugar-update-control, which
means that we will get any requests for that host - other HTTP urls,
rsync connections, etc.

Most of this will be benign, but it is not hard to imagine examples
that confuse users and programs, and perhaps also cause pointless load
on the XS.

> We are *not* just returning the XS's address in response for a request
> for an inaccessible host.  See the discussion in [[Network
> principles]].

Hrmmm. I read Network principles again. I cannot find what you are
referring to. Do you mean the using the trick as per: "If a school
server is unavailable, we can provide a resolver which will form an
IPv6 link-local address from the lower 64 bits of the SHA-256 of the
domain name."

Is that what you mean? How does that help?

>> We are already doing this with Telepathy.
>
> Yeah, and how well is that working?

AFAICS, we are switching modes alright, the problems are further up the stack.

>>  -  masking specific host:proto:resource paths across protocols --
>> while connected -- without affecting other resources and protocols on
>> that host?
>>
>>  - how do we do the above in a disconnected scenario, without the
>> issues of clients assuming that the XS provides *all* the services of
>> the masked host?
>
> See above, and [[Network principles]].

I cannot see what strategy in that page you are referring to.

Network principles is a nice statement of desired ideal network
topology. Which we may implement one day - but I am delivering a
network topology and the _main source of XO services_ on a very  tight
timeframe and with no room for pie-in-the-sky stuff. Simple, proven,
effective, easy to implement.  That is the only game I can afford to
play.

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