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

[coderman]

On Thu, Aug 29, 2013 at 10:25 AM, grarpamp <grarpamp at gmail.com> wrote:
> ... because of our silly desire to not fill our pipes with chaff,
> we've made it easier in some cases for GPA's [...] to watch and
> connect the inputs/outputs across a relatively silent backbone...

active attacks are often even more effective at rapid traffic
confirmation and analysis[0]; GPA is pretty tame perhaps!


in any case the challenge you mention: thwarting or preventing traffic
analysis without a full mix of constant traffic. if the datagram based
system above existed, combine with:

- stochastic fair queuing and re-ordering of egress traffic. by
"clamping" the outbound rate of randomized, re-ordered datagrams to a
broad "size/chunk" of capacity, you deter traffic confirmation,
anonymity set reduction, and other traffic analysis attacks of various
types.

- client-side classification of application traffic into prioritized
classes[1] for ingress / dgm proxy level active shaping by classful
HTB queues before transiting the first hop and losing all visibility
into the content and priority of message payloads.

- integrate a lowest effort / unreliable background reliable multicast
like bulk transport channel for resource and key pre-caching, network
participant and performance information distribution, secure remote
archives, random performance measurement/tests across peer groups,
other low priority communications suited for this "filler" class of
traffic. (consuming more or less filler traffic helps smooth out the
effective throughput and efficiency when changing the broad
"stochastic traffic capacity range" appropriate for a given peer.)

- provide LEDBAT or AQM management of edge traffic to upstream(s) to
prevent unnecessary latency in upstream buffers. this ensures that
even at full utilization the responsiveness of the broadband link is
excellent.

- and the multi-path SCTP, IPsec, UDP NAT traversal and encapsulation,
and other user space network stacks communicating across this overlay
network as discussed above for requisite application and control
communication support.

these techniques combined allow you to use still not insignificant
"stochastic traffic capacity ranges" instead of a constant fixed
amount of traffic to protect against these attacks.  these stochastic
ranges can be adjusted up or down as network performance and capacity
dictate. this protocol provides congestion control and TCP
friendliness while greatly reducing the amount of bandwidth consumed
relative to a traditional mix.

---

at best (in theory), an attacker with local active and global passive
methods on hand could discern anonymity sets for broad categories /
scales of possible communication usage.  E.g. anon set A exhibits
traffic utilization on the order of 1Mbps to 5Mbps, while anon set B
exhibits traffic utilization on the order of 5Mbps to 50Mbps, and anon
set C exhibits traffic utilization on the order of 50Mbps to 1Gbps,
etc.

given this drawback, code a kick ass client with participation enabled
by default if sufficient connectivity and resources are available.
you've now made these broad traffic volume sets nearly useless in a
practical / actionable sense.


congratulations! you've now got a traffic analysis resistant low
latency anonymity protocol, implementation, and network that nearly
anyone can participate in and contribute to. for my next magic hand
wave, a directory / route selection method that scales to billions of
peers while leveraging geographic propinquity and social peer groups
to constrain Sybil attacks and impact of bad actors.

next grow network capacity in a way that continually applies implicit
feedback from the network overall and peers directly and your
deterrence to these attacks begins to improve further over time,
perhaps even one day hitting a tipping point of prevalence and
persistence for de-facto victory in most threat models...

we can dream!


---


perhaps someone should toss up a Bitcoin donation address to support
work on detailed technical specifications, experimental prototypes,
maintaining clouds for continuous builds, regression checks, load
tests, and traffic analysis for quality measurement and security
improvement[2],

could also use donations for bounties for identifying or exploiting
security or privacy vulnerabilities in the design and implementation
of this final generation anonymous network.  whoever sets this up
should probably use an onion to coordinate development and distribute
sources, other resources...

calling all "tup" s, ...  ;P


---


0. "From a Trickle to a Flood: Active Attacks on Several Mix Types"
  http://freehaven.net/doc/batching-taxonomy/taxonomy.pdf

1. i have mentioned the following classes before, with each in
priority order for the HTB prioritization / shaping before traffic
enters the network and becomes opaque:
 a. control and signalling traffic - always takes precedence.
 b. real-time and interactive communications, but not video.
 c. real-time video communication, if applicable.
 d. low priority bulk communication.  torrents, archives, opportunistic caching
 e. filler / last-tier best effort unreliable traffic as mentioned
above for filling in the remaining capacity at the current stochastic
rx/tx rate center point.


2.  instead of trying to research and author formal proofs of entropy
bounds for various idealized models, cut straight to the chase and
build the most aggressive, best in class developmental learning / deep
learning systems for classification and identification of nodes,
flows, protocols, identities in a test bed setup that provides full
traffic visibility and active client edge MitM capability (E.g.
simulate attack via rogue AP or cell tower for tagging? selective DoS?
others,).  malicious attacks performed by the remote end or injected
by remote's upstream are not in scope for this traffic analysis and
privacy assessment. however, passive capture of all exit
communications and ORCHID hidden endpoint communications is in scope
for analysis.

then, see how effective this best scenario and tools attack is against
a running implementation.  did it fail catastrophically in flames or
break wide open with trivial effort?  keep improving...

respectably hardened against the most aggressive machine learning and
malicious active attacks you could conceive of and build?  great! have
a beer and then find the people who see the oversights and blind spots
you don't.  keep improving... rinse, repeat, ...