[PLUG-TALK] Server sky - geographic routing (2)

[Keith Lofstrom]

> On Sat, Jan 30, 2010 at 9:16 AM, Keith Lofstrom <keithl at kl-ic.com> wrote:
> > About 10 months back, I presented Server Sky to advanced topics,
...
> > I wanted to talk a bit about the pros and cons of the direct data
> > links.  Like anything new, there are pluses and minuses.  I would
> > like to hear more ideas.

On Sat, Jan 30, 2010 at 10:21:18AM -0800, drew wymore wrote:
 
> Keith,
> I don't know whether this idea is plausible/scalable but why not use
> something like a global nat'ing type route infrastructure to provide
> another layer anonymity? For example: Public IP's on the radio links
> in space itself but the ground stations utilizing it would have
> private IP connectivity to the Server Sky infrastructure itself. That
> way, if packets are being snatched out of the air and somehow
> decrypted or sourced because you are re-using private IP space
> throughout the world, it would be harder to identify the source in
> that fashion. Obviously the link pulse problem is another issue
> altogether, I don't know enough about radio communication but
> something like random beacon pulses not associated with user
> communication necessarily in order to add some other obfuscation of
> source? Just tossing ideas out there. They are probably immediately
> worth tossing in the trash but something is better than nothing right?

Drew, thanks for the idea.  Not dumb!

I expect to be using IPV6, and eventually consume a /64 (!!!) for the
server sky arrays in the vicinity of the earth.  Very sparsely populated
address space, assigned to volumes of 3 dimensional physical space.  A
moving latitude/longitude/altitude volume of space will be assigned a
particular /32 subnet.  The server sky arrays will sometimes migrate
from volume to volume, changing physical address.  Given time of day
and simple ephemerides calculations, that tells the ground antenna where
to look for a given array IP address, without depending on routing tables.

The DNS system and the machines with the routing tables are excellent
places for governments to spy on what their citizens connect to.  I
would like to get rid of that.

However, with virtual technology running on the satellites themselves,
the virtual machine that ground stations talk to hops from physical
machine to physical machine,  so that the virtual stays within view
(maybe 30 hops a day).  On the ground, the agile phased array antenna
is communicating with the machine disappearing to the east, and
100msec later communicating with the machine rising in the west.  

BTW, multiple copies of virtuals provide data backup for each other,
using something like rsync to keep the copies matched in spite of
radiation damage.

So DNS and addressing will be dynamic, and talking to a particular 
array, which may contain portions of millions of different websites,
does not tell snoopers /which/ website you are talking to.  Is it
the flower arrangement website, or the "Kim Jong-il picks his nose
and eats it" website?

So where does NAT come in here?  I seem to be doing the opposite,
potentially assigning many IPV6 addresses to the same content.  The
machines will have fixed MAC addresses, position dependent IPV6
addresses (acting like another layer of MAC) and another addressing
layer that sits in between IPV6 and the DNS layer;  ephemeral but
data related, which I will call the "temporal NAT" layer.  That
bundle of addresses will also be IPV6, in a separate space, related
to "conversations" rather than tied to fixed endpoint pairs.  I don't
get to re-use those addresses in different places at the same time
like NAT, because there are no firewall boundaries in orbital space
to separate different regions using the same address space.  But I
can reuse temporal NAT spaces in /time/,  expiring blocks of addresses
and reassigning them to different purposes every 30 minutes or so
(sequentially, not all at once).  I can randomize the expiration times
a bit just to piss off the snoopers.  Individual conversations can
jump from one block to the next early, or run multiple streams bonded,
perhaps turning one packet into three, that are XORed together at the
receiver.  So, we are moving from NAT in space, defined by a NAT-ing
firewall, to NAT in time, with temporary address blocks appearing
and disappearing to serve large groups of aggregated conversations.  

To snoop on that would require far more computational and listening
resources than Server Sky itself, which will be impossible.  When you
need ten full time spies to watch every part time spy, the spying
game is impossible to play.

That was all pretty vague, but perhaps somebody else can flesh out
a detail or two.  Thanks, Drew!

Keith

-- 
Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs