UDP/datagram/cell based networks [was: Why_can't_email_be_secure]

[coderman]

On Thu, Aug 29, 2013 at 1:39 AM, grarpamp <grarpamp at gmail.com> wrote:
> ...
> Are we necessarily even speaking strictly of UDP 'datagrams'
> or applications? For example, I presume there might be something
> to be said for software switched packet/cell network stacks.


i should clarify:

the mode of operation for this presumed design and implementation is
to have SOCKS, HTTP, HTTPS, transparent UDP, transparent TCP,
transparent DNS (this is indeed different than just UDP :), and some
subset of transparent ICMP proxy support on the client / node.  you
could configure proxy settings, direct traffic to the trans ports, or
perform queries directly against the DNS port of the running real time
datagram mixer instance.

at the exits for public traffic or at the private ORCHID based
"hidden/overlay" endpoints, you transit these same protocols, per
advertised support in exit policy or overlay service capability
respectively.

on the wire, you would be sending UDP datagrams that encapsulate the
NAT busting IPsec telescope containing path data, multi-path SCTP in
userspace for reliable TCP stream transport over the datagram overlay.

for all intents and purposes these packets would look like AH/ESP or
CryptoBox wrapped opaque cipher texts in some standard UDP
encapsulation.



as for ATM, SONET, satellite data terminals, metro wireless, and all
other unusual or exotic transports: these are likely not useful for
the core network unless directly public UDP IPv4 reachable.

censorship bypass, non-node capable devices like phones, or very poor
network connectivity situations, would require other transports and
protocols for this initial tunnel into the overall real-time datagram
mix-like network.  in this context, the varied physical layers and
logical paths in a given metro region operating beneath IP routing can
play a role in passing traffic from suppressed/blocked users out to
the broader mesh or internet at large.



devices and users communicating via obfuscated links into the dgm
network do not have traffic analysis protections like full
participants.  despite this lack of stronger anonymity, the actors
observing at the edge can only note that you are tunneling into the
public network, and utilizing some stochastic gradient of bandwidth in
aggregate for some period of time.

this is still not much information, especially compared to the current
state of affairs!

there are many complications and constraints around how this would
work - i make it sound so easy ;)
  however, you could provide such services, including wireless metro
area mesh or p-to-mp distribution networks, constrained by propinquity
and referral by reputation, in combination with broadband internet
uplink of a more traditional sort where available.

and in fact, using multiple paths / transports concurrently provides
advantage for data continuity and throughput despite volatile and
changing upstream link availability on an individual basis to
particular gateway or router or access point devices.



metro area mesh benefits nicely from some backhaul ad-hoc or fixed
plant high capacity point-to-point links over distance with short IP
routes; there is a good paper from early 2000's about using atheros
802.11a devices with a custom tertiary firmware and host driver to
bond eight devices into a single point-to-point link with an aggregate
throughput over three or four hundred megabit a second in transport
rate... or so i recall.  IPoATM on a OC12 or bigger to an internet
provider would absolutely be useful as an upstream sink within such a
mesh.

i would love to see high degree mesh optimizer p-to-mp nodes applying
the latest high bit rate software defines radios for  backhaul and
security.  isolate each radio like a Pervices Noctar[0] or USRP B210
[1] into its own guest and isolate devices with VT-d enforced memory
access boundaries.  you may even put more than one device in a single
SDR Backhaul Guest VM if doing large-QAM or other complex MIMO
front-ends and signal processing.



i could go on, but alas, i've got code to write...  *grin*



0. "Noctar: 8Gbps, low latency, PCIe x4 bus, 250MHz bandwidth, full
duplex, RF frontend 100kHz – 4GHz, Two, 12 bit, 125 MSPS ADCs, Dual
channel, 16 bit, 250 MSPS DAC, 20MHz, 0.28ppm, reference TCXO, Altera
Cyclone IV EP4CGX22C FPGA"
  http://www.pervices.com/support/

1. "USRP B210 Kit: USB 3.0 (bus max 3.2Gb/s) for xfer ~60 MSym/sec, 56
MHz bandwidth 1x1 / 32 MHz 2x2 MIMO bandwidth, 70 MHz to 6 GHz
frequency range, flexible rate 12bit ADC/DAC, 2 TX and 2 RX full or
half duplex channels (4 total), Xilinx Spartan 6 XC6SLX150 FPGA"
  https://www.ettus.com/product/details/UB210-KIT