On 6/2/16, Allen <allenpmd@gmail.com> wrote:
Another alternative would be to re-architect the services of interest to use a message or packet store-and-forward protocol with a random delay to thwart traffic analysis.
Perhaps different terms for same derivative thing?
From other searchable and recent threads... Fill traffic needs store and forward with random delay, for low latency requirements it could be called reclocking with jitter, rearchitecting for higher latency adds additional bounds on time to the interval and jitter clocks. Packet / message oriented / UDP seems useful to remove constraints of TCP-in-TCP allowing for management of fill traffic, multipath traffic spreading, pluggables, and so on.
Ineffective is say rearchitecting web "services" to deliver a tarball of a website for offline reading, if said delivery is over a traditional non fill network, it will be TA'd. Fill / chaff seem needed, otherwise in an all wheat network, input traffic on one side seems to match output traffic on the other side at some point, regardless of storage / delay. Fixed packet sizes seem to help. Fill ratios up to 100% utilization can mask the wheat. Minimum fill is amount needed for plausible deniability that single input can't be mapped to a single output. ie: 10MiB in, must have at least two outputs that received 10MiB. Is there any group / list that is actively researching or developing such networks? Or that wants to?