Nextgen Traffic Analysis Resistant Overlay Networks (re: tor replacement box)

[grarpamp]

>> https://lists.cpunks.org/pipermail/cypherpunks/2020-May/080509.html
>>  mid: CAD2Ti282noLJEugQ8dQ6BAnbfxdz8DDy1xUpNAXSXMxHNN

Being potentially applicable to a more abstract generic overlay
transport network handling modular applications, one perhaps
being 'replacing tor'...


bell writes:
> 'chaff' might have been a problem if
> the people who host the nodes had some limited-data Internet service, but I
> am aware that Centurylink now offers 1 gigabit service for $65 monthly, and
> I think that service has no monthly data limit.  (their slower services have
> a 1 terabyte montly limit).  That should be plenty to allow for generous
> chaff.


Things maybe different from the notion that paying high speeds,
enables sufficient chaff, enables sufficient security.


Data limits vs bitrate vs network fill chaff vs security.

A network normally filled fulltime during user-idle time with
right-of-way-Yielding chaff, then yielding way dynamically to
user-not-idle traffic demand of right-of-way-Having wheat,
an equation is...

(rowY chaff + rowH wheat = at all times ensuring the provisioned line
rate is full)

...that is self enabling, regardless of bitrate, caps, or money.


If user has a 'data limit' specified as a quantity (typically Bytes in a
period), they can generally save some quantity for later consumption by...

- turn on client, use for whatever, turn off client

...but client must still conform to equation above when running,
else no security improvement over todays existing overlay networks.


3TiB/mo = 100GiB/dy = 10Mbps

Any data quantity limit per time period breaks
down as above into an available constant bitrate.
If that bitrate is not enough for user to do whatever within,
say voiceconferencing at stupidly offensive codec bitrates,
then they must play the on/xfer/off game above to convert
more saved quantity into now bitrate, this is simple physics.
They only have bitrate up to the max they got from ISP, the
maximum even then is up to the hard physical link speed PHY.
Both of which are usually higher than any data quantity
limits the user bought and got provisioned because the ISP
wants to rape user's bill for Bytes (the ISP aggregates and
only deals in bitrate pipes upstream anyway, Byte caps
are just counters triggering management scripts over pipes).

Point is, constant bitrate <=translate=> data quantity.

And the constant background of chaff would yield its way packet
by packet on the fly upon demand of the quantity of user's wheat
flow, whether the demand be for 0% up through 100% of the line,
all [re]clocked back out the NIC.
Whatever the %, and for the varying duration and amount of its
demand, that wheat is in fact become part or all of the fill traffic
needed to prevent traffic analysis across the network.
Security of the net requires all network nodes to
always enforce the above equation when running.

So there is probably less notion of this 'allow for generous chaff',
only the notion of if the user has purchased enough
capacity to do what they want. If they didn't buy enough,
nothing will let them dodge their provisioned physics.
This physics is no different than with Tor, I2P, bittorrent,
IPFS, BTC, this model or anything other, or even plain old
raw websurfing straight out user's NIC to their ISP to YouTube.


1Gbps = 300TiB/mo = $65/mo
1TB/mo = 3Mbps = $?/mo

Only one of those two ISP plans will allow the
user to do 10Mbps of demand. The network is still
secure during their use of it regardless of which plan
they choose or how they choose to use it.

If talking about 'hosting' nodes, meaning configuring them up
as transit nodes, possibly in addition to user's own use of them
as endpoints, the same equation still applies.

People still too often think of chaff by the old fashioned models,
they still assume chaff can only be in addtion to or somehow taking
up space for or blocking out wheat... the equation above offers
a new dynamic yield-right-of-way model to think about.

All nodes, whether end user endpoints or any other type,
must generate equation conforming fill of their entire virtual
connection rates into the overlay [1], else...
- Pairs of endpoint traffic patterns can still be matched up.
- Overlay cloud will have quieter/unregulated paths that will
eventually get randomly chosen by endpoints to path through
yielding a traceback match.
... tor tries to game these with noise and aggregation,
but that may not be sufficient.

Nodes auto negotiating bandwith rates among peers,
enforcing those contracts and [re]clocking expectations,
else dropping them out as suspect, still applies as usual.

Migrating end users from any of today's overlays would set
one new thing... the end users subject to data caps would
configure their node to sit idle until it detects their call for
the network, or just turn it off. Both those and unrestricted
users gain access to some more analysis resistance in
usual transparent-tor-like sort of way.

The model might not depend or care about how traffic
moves around inside the network, or what the apps
it carries are. It maybe possible to apply to any existing
or new overlay network as an external function managing
its traffic over the NIC to/from its peer nodes on clearnet,
like in old ATM cell bucket brigade fashion.

foreach bucket in negotiated_clocked_rate if demand
then send demand else send chaff


This scheme probably rubbish anyway.


[1] The real pipe bought from ISP might have some virtual
rates carved from it by user for other clearnet applications.
In a router device, this would be the typical red/black ports
and rate limit packet filters, so that traffic doesn't impede
each other, or provides a dynamic use equation
for the real pipe.

bought rate = rate allocated to clearnet apps + rate allocated to
nextgen overlay app