On Mon, Apr 01, 2019 at 10:45:59PM -0400, grarpamp wrote:

...

I am personally convinced that a flat traffic shape will only dare attackers to cut links between parts of the network, effectively making an even larger traffic shape to corrilate with.

Today if play the cut links game, eventually a toggled link will expose the traffic you seek, because there's no fill between nodes that automatically takes its place. Your global monitor sees a respective signal slump among the nodes making up the subject path, each node distinguishable by time deltas. Such signal the adversary was probably clocking into it themselves for easier recognition anyway... fetch 1MB, fetch 1MB, fetch 1MB, fetch 1MB... oh noes.

Tor's hidden services are total sitting ducks because of this. Same for likely all current overlay networks in production regardless of whatever service they provide... from traffic, messaging, storage, cryptocurrency, and so on.

There are surely better links from the bib space, yet here are some concepts on generated buckets, retiming, how they can contain full time "empty" fill that yields to wheat demand on the line, traffic contracts, etc therein...

https://en.wikipedia.org/wiki/Generic_cell_rate_algorithm

If all the nodes are independantly maintaining independant traffic contracts between their physical and/or logical peers, cut links won't do hardly as much impact if anything at all...

A \ B + -----> M -----> { U V W X Y Z } C + D /

If actual transport GPA "route detection" resistance is desired, create many low bandwidth entries to the network and aggregate the bandwidth → this implies 'fancy' routing at some mid point node that can split an e.g. incoming stream's packets across multiple low bandwidth routes; use always only say 50% of your routes and that "connection" is not shaped downwards except that 50% of your mini routes are cut. If GPA is super scary, use only 10% of your routes or less. If GPA is almost irrelevant, use 100% of your routes and suffer GPA route detection if even one of your mini routes is cut. Vice versa for upload. Clearnet endpoints are the most vulnerable of course, so we need distributed "content based" servers (i.e. Git-style content addressing and distributed data stores, so your critically important TDS website becomes completely decentralized - as long as even one person wants to read the site, the site exists on their node.

If nodes ABCD on the left are trafficing through M cloud fanning out to the right mesh towards UVWXYZ, then adversary cutout of D is not visible beyond M if M makes up for D's packet slack on its left contract by continuing to emit the same amount as fill to fulfill its right contract.

M could variously blackball A for non contractual suspect misbehaviour... weird rates, timing anomalies, uptimes, etc.

M could signal BC that they can now renegotiate upwards with M since M now has more rate free on its left.

If M is cut out, the left renegotiates with some L or N nodes via new northern or southern arc routes.

The "shape" or "bitrate" of the contracts could be negotiated as need be, "flat" might not be necessary, so long as the contract is upheld and policed by all participants to it.

Contracts could be one to one, one to many, many to many, physical next IP hop to hop, logical overlay address to address, multiplex, simplex, tunneled, shared, etc. And pertain to bitrates, timing, uptime, any sort of constraints, metadata, etc.

Exactly!

This also makes Sybil's life more difficult... it must now own the full path or it will lose sight due to contracts with non Sybil nodes in the path who are also meshed and contracted out to other non Sybils around ot. Sybil must also uphold all its own contracts or get dropped by other nodes.

Nice.

...

I am not convinced low latency systems can be immune to traffic shape corrilation and hence that being said

Copper, Fiber, Radio, etc.. so long as it's quality line rate hardware that can keep up with its advertised rate, their time to transfer data is dependant only on distance, not on how full the line is. Such network hardware is agnostic... fill, wheat... it all gets there in the same time.

Indeed. If the "cut the link" game genuinely heats up, then the "alternate physical private" link rollout game will also get going - dark fibre, radio, neighbour to neighbour copper etc.

When people say "X latency network overlay", they're really referring to the cost of software processing their overlay design on their crappy stack of PC / Phone CPU hardware. And in their transport protocols running on the same... TCP, UDP, etc... all the way down the stack until it hits the real network hardware, which will either happily accept and ship the packet, or drop it.

When people cry about "bandwidth", all they need to do in a fill model is allocate whatever bitrate to it they like and forget it. They're not going to get more bitrate from their ISP than they paid for, and they'll probably contract to the overlay under that so they can do other things with their line. And they're not going to get more wheat bytes across the overlay than a 100% wheat ratio (fill yields to wheat demand) within their contract to the overlay, even if they do disconnect from their byte transfer based ISP / Phone afterwards.

Research would need done into routing models needed to transit traffic across the overlay. ie: TCP can readily jam more yet slower circuits through a full pipe, UDP mix gets dropped routed or reserved for. Raw IP becomes interesting.

Raw ethernet should be preferred at the lowest layer, falling back to IP, UDP and e.g. Tor's "VPN" mode/ tunnelled HTTP/S etc as needed, depending on what the ISP allows in/out.

As a network HW project for defense in depth...

If hardware makers would add line rate encryption and fill silicon to every physical port on every switch, router, and NIC... mandatory on by default per physical link... that would kill off a lot of vampires.

An open IETF RFC spec for that would cost under $1 per port to integrate into existing silicon port fab worldwide, plus electricity to drive the port which would be estimated as part of the RFC process. Modular agility would not cost much more at scale.

Assuming line rate hardware, there's no latency impact here either.

To use existing silicon "IP" (Intellectual Property) blocks, sequence a TRNG/HRNG, into a rand pool, HASH each chaff packet (for chaff/ fill) and AES (or whatever) the result (for both chaff/ fill and wheat packets), and always check your hash at the receive end (to check your line AES/etc crypto is at least superficially working.

...

I think state actors are out of scope of the current threat model of llarp.

If any network application involves free speech, politics, money aka cryptocurrency, business, journalism, industry, messaging, personal affairs, data storage and transfer, basically anything at all... you can be absolutely certain that many State and Other Actors have a serious continuum of interest in it.

Thus failing to "relevantly improve" on the I2P/Tor status quo is largely an exercise in pointlessness.

Is it the responsibility of each application to develop their own solutions to the threat?

No... probably not when many such apps ride on, aggregate muddily over, and depend on networks. All apps can contribute to the development of a diversity sound number of strongly resistant networks that they can then utilize and endorse as they would their own.

Be they overlays on top of the internet, enhancements to the internet, or new guerrilla physical plant...

That process of people contributing to original and ongoing development of new strong networks that are not susceptible to such Basic Bitch Adversaries as Global Vampires, is something more should consider.

Same for likely figuring out how to get the deployment Social aspects right so you can circle the network wagons against Sybil.

At least begin your network, where at all possible, with trusted peers, GPG ring of trust style.

...

This may or may not change.

Pity the fool who changes even one satoshi based on the worthless drivel herein :)

And thank the fools who try...

On Mon, Apr 01, 2019 at 10:45:59PM -0400, grarpamp wrote:

...

I am personally convinced that a flat traffic shape will only dare attackers to cut links between parts of the network, effectively making an even larger traffic shape to corrilate with.

Today if play the cut links game, eventually a toggled link will expose the traffic you seek, because there's no fill between nodes that automatically takes its place. Your global monitor sees a respective signal slump among the nodes making up the subject path, each node distinguishable by time deltas. Such signal the adversary was probably clocking into it themselves for easier recognition anyway... fetch 1MB, fetch 1MB, fetch 1MB, fetch 1MB... oh noes.

Tor's hidden services are total sitting ducks because of this. Same for likely all current overlay networks in production regardless of whatever service they provide... from traffic, messaging, storage, cryptocurrency, and so on.

There are surely better links from the bib space, yet here are some concepts on generated buckets, retiming, how they can contain full time "empty" fill that yields to wheat demand on the line, traffic contracts, etc therein...

https://en.wikipedia.org/wiki/Generic_cell_rate_algorithm

If all the nodes are independantly maintaining independant traffic contracts between their physical and/or logical peers, cut links won't do hardly as much impact if anything at all...

A \ B + -----> M -----> { U V W X Y Z } C + D /

If nodes ABCD on the left are trafficing through M cloud fanning out to the right mesh towards UVWXYZ, then adversary cutout of D is not visible beyond M if M makes up for D's packet slack on its left contract by continuing to emit the same amount as fill to fulfill its right contract.

M could variously blackball A for non contractual suspect misbehaviour... weird rates, timing anomalies, uptimes, etc.

M could signal BC that they can now renegotiate upwards with M since M now has more rate free on its left.

If M is cut out, the left renegotiates with some L or N nodes via new northern or southern arc routes.

The "shape" or "bitrate" of the contracts could be negotiated as need be, "flat" might not be necessary, so long as the contract is upheld and policed by all participants to it.

Contracts could be one to one, one to many, many to many, physical next IP hop to hop, logical overlay address to address, multiplex, simplex, tunneled, shared, etc. And pertain to bitrates, timing, uptime, any sort of constraints, metadata, etc.

This also makes Sybil's life more difficult... it must now own the full path or it will lose sight due to contracts with non Sybil nodes in the path who are also meshed and contracted out to other non Sybils around ot. Sybil must also uphold all its own contracts or get dropped by other nodes.

...

I am not convinced low latency systems can be immune to traffic shape corrilation and hence that being said

Copper, Fiber, Radio, etc.. so long as it's quality line rate hardware that can keep up with its advertised rate, their time to transfer data is dependant only on distance, not on how full the line is. Such network hardware is agnostic... fill, wheat... it all gets there in the same time.

When people say "X latency network overlay", they're really referring to the cost of software processing their overlay design on their crappy stack of PC / Phone CPU hardware. And in their transport protocols running on the same... TCP, UDP, etc... all the way down the stack until it hits the real network hardware, which will either happily accept and ship the packet, or drop it.

When people cry about "bandwidth", all they need to do in a fill model is allocate whatever bitrate to it they like and forget it. They're not going to get more bitrate from their ISP than they paid for, and they'll probably contract to the overlay under that so they can do other things with their line. And they're not going to get more wheat bytes across the overlay than a 100% wheat ratio (fill yields to wheat demand) within their contract to the overlay, even if they do disconnect from their byte transfer based ISP / Phone afterwards.

Research would need done into routing models needed to transit traffic across the overlay. ie: TCP can readily jam more yet slower circuits through a full pipe, UDP mix gets dropped routed or reserved for. Raw IP becomes interesting.

As a network HW project for defense in depth...

If hardware makers would add line rate encryption and fill silicon to every physical port on every switch, router, and NIC... mandatory on by default per physical link... that would kill off a lot of vampires.

An open IETF RFC spec for that would cost under $1 per port to integrate into existing silicon port fab worldwide, plus electricity to drive the port which would be estimated as part of the RFC process. Modular agility would not cost much more at scale.

Assuming line rate hardware, there's no latency impact here either.

...

I think state actors are out of scope of the current threat model of llarp.

If any network application involves free speech, politics, money aka cryptocurrency, business, journalism, industry, messaging, personal affairs, data storage and transfer, basically anything at all... you can be absolutely certain that many State and Other Actors have a serious continuum of interest in it.

Is it the responsibility of each application to develop their own solutions to the threat?

If the state is out to get you I'd just assume that everything arround you is rooted and a wire tap and act accordingly.

No... probably not when many such apps ride on, aggregate muddily over, and depend on networks. All apps can contribute to the development of a diversity sound number of strongly resistant networks that they can then utilize and endorse as they would their own.

Be they overlays on top of the internet, enhancements to the internet, or new guerrilla physical plant...

That process of people contributing to original and ongoing development of new strong networks that are not susceptible to such Basic Bitch Adversaries as Global Vampires, is something more should consider.

Indeed, we'll get there eventually. I am just a guy that made a thing because I thought it was cool.

Same for likely figuring out how to get the deployment Social aspects right so you can circle the network wagons against Sybil.

...

This may or may not change.

Pity the fool who changes even one satoshi based on the worthless drivel herein :)

Let the record show that I am not the one making the sybil resistance claims it's the coin team that is. I doubt them as well but I am open to being surprised. I orignally had another model in mind for mitigating bad actors on the network that I still plan on implementing (eventually) Effectively it's a f2f mesh connectivity layer to help hide traffic shape. I am not arrogant enough to claim to be able to repell state actors from sqaure one.