[Commotion-dev] Thoughts on secondary apps

[Peter Folk]

Much of what Erich wrote is along the lines of what I was thinking too. 
A few notes:

On 2/1/2011 12:51 AM, Erich Heine wrote:
> First of all, consider use cases, which seem to fall naturally into
> some sort of priority scheme. Here is how i see it, which is by no
> means a complete, or even accurate list, but we gotta start somewhere
See my list of critical services, which seem to mirror yours.  Feedback
on my thoughts on approaching those services would be good.

> So on top of these use cases we have some weird constraints here:
>
> * Limited Internet connectivity. It's like the olden days but worse --
> fast LAN super slow WAN. Further that WAN link is probably pretty
> sketchy and down and up a lot.
> * Honest to goodness hop-count issues, and other weirdnesses from
> running lots of traffic through small boxes.
> * Trust issues like woah -- social trust issues between/about various
> groups, mesh networks seem tailor made for MiTM situations, canonical
> naming and other issues go out the window.
> * Infrastructure setup issues -- even if we get a packet network up
> and running on meshed devices, there needs to be a bunch of local
> services set up to deal with the fact that 1. no one can reach
> standard infrastructure reasonable (see the limited connectivity
> issues) and 2. many of the local language services are probably run on
> servers that can no longer talk to the network, and probably can't
> reasonably be expected to jump on the mesh.
It seems to me likely that a person will usually know the person
providing their gateway (multiple small disconnected cells are more
likely than a full mesh) or at least someone who knows that person (no
need for a party, which is operationally dangerous; you can have a chain
of trust).

With that in mind, you need each user to exchange a key with their
gateway host, in the form of the fingerprint for a self-signed SSL cert,
and get the direct URL of that gateway so that it can (via whatever
routing mechanism) use a secure HTTP proxy and critical service
interfaces that run on the gateway.

The gateway owner needs to get fingerprints of trusted out-of-country
proxies, ccsrssp hosts, etc.  Since the gateway operator has 'net
access, that can be PKI-based.

> * deciding what gets out over the uplink: really this will come down
> to the uplink operator anyway, so there is no point trying to enforce
> it...

Yes, but reasonable defaults will make things work better:

    * On the gateway, identify uplink bandwidth with periodic
      observations and/or speed tests
    * Prioritize critical-service traffic, DNS, and known chat
      protocols, over bulk traffic
    * If the gateway only communicates with an out-of-country proxy
      (through an SSH tunnel, for example), that proxy can similarly
      prioritize gateway-bound traffic

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20110201/4dec086b/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 552 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20110201/4dec086b/attachment.sig>