<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Much of what Erich wrote is along the lines of what I was thinking
too. A few notes:<br>
<br>
On 2/1/2011 12:51 AM, Erich Heine wrote:<br>
<blockquote
cite="mid:AANLkTik1+k+KDfkzQ=c4q0jWDD2zu_m8S+FO2PJV_WeE@mail.gmail.com"
type="cite">
<div>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</div>
</blockquote>
See my list of critical services, which seem to mirror yours.
Feedback on my thoughts on approaching those services would be good.<br>
<br>
<blockquote
cite="mid:AANLkTik1+k+KDfkzQ=c4q0jWDD2zu_m8S+FO2PJV_WeE@mail.gmail.com"
type="cite">
<div>So on top of these use cases we have some weird constraints
here:</div>
<div><br>
</div>
<div>* 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.</div>
<div>* Honest to goodness hop-count issues, and other weirdnesses
from running lots of traffic through small boxes.</div>
<div>* 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.</div>
<div>* 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.</div>
</blockquote>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:AANLkTik1+k+KDfkzQ=c4q0jWDD2zu_m8S+FO2PJV_WeE@mail.gmail.com"
type="cite">
<div>* 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...</div>
</blockquote>
<br>
Yes, but reasonable defaults will make things work better:<br>
<ul>
<li>On the gateway, identify uplink bandwidth with periodic
observations and/or speed tests</li>
<li>Prioritize critical-service traffic, DNS, and known chat
protocols, over bulk traffic</li>
<li>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</li>
</ul>
Peter<br>
<br>
</body>
</html>