Loki.network, Crypto Network HW Links, Anti Vampire and Sybil Nets, Actors Everywhere

[Zenaan Harkness]

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...