On Sun, Oct 27, 2019 at 11:48:58AM +1100, Zenaan Harkness wrote:

On Sat, Oct 26, 2019 at 05:32:59PM -0400, grarpamp wrote:

...

ie: Bittorrent nodes (clients) ignore nodes that send corrupted datas... overlays should drop peer nodes that exhibit non conformant traffic characteristics... such as unclocked, bursty waves, etc that was not agreed to, that would present risk to observability.

"Bursty" anything, without negotiation of graduated/ stepped up/down link management, must not be permitted in the first instance.

Except of course, where bursty is high bandwidth, low priority traffic which can be buffered and used effectively as a form of chaff fill when higher prio traffic is satisfied. By making such streams a first class citizen (design wise - e.g. low risk torrents), we may find that chaff/wheat ratio ultimately gets really low (i.e., very efficient overall network b/w utilization).

For most all folks today, their first physical hop or link, is to their ISP.

A GAA performing active timing attack, in the way of suspending your internet link for say 500 ms, is not possible to defend against when you have no other links for onboarding.

Acess censorship is separate from what the first overlay net node you connect to decides to do with the adverary modulated garbage they received from your node. That first node, or any other node, should drop you until you behave, assigning the bandwidth and timing contract they negotiated with you to a better participant in the meantime.

active link suspension across target sets of end users, bisecting as needed to map end user nodes to destination/ server streams of interest.

So what, a secure overlay should drop its apparently contract breaking nodes (as so affected by adversary whether by cutout or other modulation) up to and including the remaining overlay progressively cutting out thus effectively downing itself as protection in reaction to increasing adversary scopes of aggression. A net can't call itself secure if it is stupid enough to stay up under known successful attack methods, operational yes, secure no.

the less your enemy can hide, the better.

An estimate is required to determine if G* adversary can actually sustain modulation for traffic analysis against millions of nodes at once for what duration of time... if adversary cannot hold a self-defensive network down and out as such, the overlay wins, and adversary is relegated to a mere annoyance randomly sinking nodes as a sore loser for lols.

QoS, lo / hi priority

People first have to solve old problems with those... - Users declaring all their traffic as hi, because. - The overlay must see inside all traffic to inspect and classify, no go. - The overlay must becomes the State offering only proprietary apps that it can controls, boring limited. - Users pay for play to the overlay, complex. Users are paying ISP for what rate they choose to pass over their NIC. Most all overlays have always been able to handle user traffic because there are more than enough wheat-idle nodes to carry for example low quality video over 7 hops, or mid quality youtube over 3. Unlike Tor, if as in Phantom every user is a relay, there should be plenty of excess wheat-idle capacity because users are mostly idle.

Phone calls require QoS.

Both the Internet and Tor have no QoS, yet users have been able to hold voice and IRC conversations between Tor onions since day one, with some even being able to stuff low quality video calls over it as well. In a fill network, so long as fill yields to for wheat demand, the only real constraint seems how the overlay's transport such as TCP / UDP and or some proprietary bucket transport handle congestion when two or more users traffic shares the same physical path between nodes.

I don't understand the consideration

Overall point was, are people building some overlay to handle only one app (messages, storage, IRC, whatever), or a general purpose transport overlay like the internet that can carry whatever. Presuming both can be done equally securely and performant, there is no point to do the former. Lots of research and nets out there "We're building an overlay for this specific app". That being, much more research needs done in area of application agnostic, general purpose transport, traffic analysis resistant, networks. If you can figure out how to do the latter, the former is entirely moot. Study the latter first.

In an overlay net, we think of a link as peer to peer.

But physically that link is usually as follows:

NodeA -> ISP1 router -> GT-1 router ... ... -> ISP2 router -> NodeB

Wo when we talk base fill/ linerate/ fulltime chaff link, we should perhaps be clear about which physical links/routes we are referring to - we must consider the physical links as much as the virtual/ overlay links, in order to properly assess security implications.

In a fill-as-defense model, overlay links dont care about the physical between, only that whatever the two overlay nodes agreed about bandwidth and timing expectations they have for each other is upheld between them. If it isn't, they or their internet path between is under attack either by nature or adversary, the contract A B negotiated between themselves will fault, and they should sleep / drop / renegotiate, before passing data for the overlay again.

On Sun, Oct 27, 2019 at 06:22:53AM -0400, grarpamp wrote:

...

Let's say we buffer 500ms since that forces attackers to suspend links for over 500ms to identify target nodes, and making their network node bisections more noticeable to end users: 3.5s

...

And 500ms may not be enough! Perhaps we should buffer up for a second or more?

10 milliseconds, 10 seconds, 10 minutes, 10 hours or 10 days... speculating on which any adversary will use... removes use cases for the network as a result.

Set speculations to 0 ms, and just depeer from node when it appears to no be upholding traffic parameters it said it would be sending you. If you agree to x, possibly supported by iperf test between you, and your peer start sending you a chopped up sine wave outside allowable deviation, they or their path to you are obviously fucked, just drop them. If it's allowable then buffer and reclock it when sending it back out your NIC so that whatever natural identifiable remains is not replicated beyond you.

Ack. Yes each link, BA, AC, must be maintained according to its own agreements, and is bound by the consequences of not meeting those agreements. So let's analyse this: Nodes A, B and C. There is a link BA, and a link AC. B is sending packets to A, and A is routing them (per pre arranged agreement) to C. - A may have had some unused capacity in a currently maintained link AC, which A allocates to serve the request by B (of A) to route packets to C (at least for a time), - or, A may have had to make a request of C, to increase the capacity of the link AC (which request, node C may ack or nack at its discretion), - or, A may have had to establish a new link as a result of B's request, link AC. In any case, we assume: - C has granted A's request for a link, - and that C is not told why A is requesting the new link (or an increase in b/w on this link), - and in all cases, A must maintain its contract with C. So, B begins to use link BA, and indirectly link AC. So now, B suddenly comes under attack, and is unable to maintain its previously requested packet sending rate (or latency/ jitter), to node A: - This should not affect A's link with C (AC) - if, in any particular packet sending time period T, A has not received sufficient packets from B, to send on to C, A simply chaff-fills the link AC, so that a passive onlooker cannot see any difference in the AC link behaviour. - node C is satisfied with this, since A is keeping up its end of the bargain, albeit there is apparent under-utilization of the link AC - Per config, A could ramp down, or kick, the BA incoming link, and consequently ramp down its AC outgoing link. - From A's point of view, B's metrics just took a negative hit, and A records this fact; in the case B is a meat space friend, the operator of node A may either noisily (on the phone or in email) or quietly (in person) enquire of his friend operating node B "wtf?" And the issue is, for A to maintain AC properly, A has options in relation to a "pause + catchup burst" from B (on link BA): 1. duplicate the "trough+spike", i.e. "catch up" with B - if this is SOP (std op procedure), the "trough+spike" will propagate throughout the entire link, so we're not doing this! 2. of course A chaff fills the trough, in its link to C, but what about the "catchup spike" from B? A could cache that spike ongoingly, until the stream is over; this may be desirable from B's perspective, but a lot of spiking could cause both unpredictable, out of control and therefore problematic "spike caching" - although this could be readily handled by requiring B to pause a second time, just to allow A to drain its "spike cache for B". 3. At some point, if the behaviour is bad enough, A simply kicks B (your network behaviour is sufficiently bad, bye bye). 4. do something else? Nodes, in this case B, are expected to display "decent" behaviour in relation to such spikes, even if say B is unable to operate without such spikes (perhaps there are network local conditions making spikes on B's outgoing link, unavoidable ??), and in this case "decent" behaviour could mean "if you've had troughs and spikes, you must add troughs, since I (node A) will only cache at most N packets for you, after that I will simply drop packets and/or kick your link. By maintaining node behaviour metrics, and by propagating such metrics (need to think about this from a privacy vs network sanity perspective), we may be able to identify "latency creators" (therefore problematic nodes and/ or hardware) if not immediately, at least after attacks happen, thereby increasing the cost to stalkers - also, we will have a digital war on our hands, a massive global us vs the GAA stalkers situation, where certain physical links, end points, routers, buildings etc, will be identified as stalkers/ attackers, and outed (network, and IRL - make 'em pay the price for stalking and attacking us). So from the perspective of the syntax / scenario above, "reclocking" (by A) of "dodgy input" (from B) simply means "chaff filling the output, so that my output link to C appears perfectly normal", and ensuring B does an additional pause to allow A to drain its temp "B spike cache" - at least, this is my current understanding. If there is an additional concept to "reclocking" that may also be useful, we should consider that too...

On Sun, Oct 27, 2019 at 05:41:49AM -0400, grarpamp wrote:

...

For most all folks today, their first physical hop or link, is to their ISP.

A GAA performing active timing attack, in the way of suspending your internet link for say 500 ms, is not possible to defend against when you have no other links for onboarding.

Acess censorship is separate from what the first overlay net node you connect to decides to do with the adverary modulated garbage they received from your node. That first node, or any other node, should drop you until you behave, assigning the bandwidth and timing contract they negotiated with you to a better participant in the meantime.

The problem is the node that was attacked with a latency injection attack - he just got attacked, his friends have now dropped him, and the Feds just identified whatever it was he was up/downloading - this is a problem we're trying to solve, and it seems impossible to solve with a single govnet onramp link (at least, with traditional fat and bursty up- and down-loads.

...

active link suspension across target sets of end users, bisecting as needed to map end user nodes to destination/ server streams of interest.

So what, a secure overlay should drop its apparently contract breaking nodes (as so affected by adversary whether by cutout or other modulation) up to and including the remaining overlay progressively cutting out thus effectively downing itself as protection in reaction to increasing adversary scopes of aggression. A net can't call itself secure if it is stupid enough to stay up under known successful attack methods, operational yes, secure no.

Is it possible to have GUI such that end user can specify "important" streams which must go down/stop when under any identified successful attack, vs "unimportant" regular clear net surfing? What we want, if possible, is an appealing end user experience, but one which does not deceive them as to what is happening.

...

the less your enemy can hide, the better.

An estimate is required to determine if G* adversary can actually sustain modulation for traffic analysis against millions of nodes at once for what duration of time...

It's not the millions we need to protect usually, just the few.

if adversary cannot hold a self-defensive network down and out as such, the overlay wins, and adversary is relegated to a mere annoyance randomly sinking nodes as a sore loser for lols.

Fat bursty traffic, if it is of high importance or criticality in relation to G*As, needs to be modified to be a different type of traffic - analogous to free to air terrestrial broadcast, vs spread spectrum "disappears in the white noise" comms which merely raises the noise floor.

...

QoS, lo / hi priority

People first have to solve old problems with those...

- Users declaring all their traffic as hi, because.

Solution: Peers of course won't accept that. The model is, make request of a peer, for X bps @ Y QoS; peer responds with ack or nack; repeat until route is created, or not possible at this time. - End user/ individual node, is the final authority for all requests made of him. - So find an anon peer who acks your request, or wait, or make (more) friends in meat space.

- The overlay must see inside all traffic to inspect and classify, no go.

Indeed, no go.

- The overlay must becomes the State offering only proprietary apps that it can controls, boring limited.

No go. A node is its own final authority. Everything else will be by agreement/ contract - inducement by incentivization, and also squeezing some things into base "minimum suggested operating mode" to establish tacit consent to such minimum suggested operating modes (e.g. default 10cps headroom chaff filled "first hop" node links).

- Users pay for play to the overlay, complex.

The first motivation for most these days is pay to play - like that South Korean "zero sim" or whatever they're called which you recently posted. Before going there, let's maximise each of: - natural incentivization - tacit consent, and - voluntary node to node "contracts" - even with 'unknown' nodes we can pop up requests to end user e.g.: Node you are connected to ('SHA713...') requests "Please stay online for 10 minutes, wants 20Kbps: [YES] [NO] Many UI elements and config etc can be created around this concept of course, to maximize end user sense of control, comfort, social credit significance feelz, preference first hop nodes that are my actual friends (if under 15 minutes, always accept but let me know, unless I have clicked "I'm going to sleep" button), maximum requests accepted per 10 minutes, request batching, unattended behaviour, etc etc.

Users are paying ISP for what rate they choose to pass over their NIC. Most all overlays have always been able to handle user traffic because there are more than enough wheat-idle nodes to carry for example low quality video over 7 hops, or mid quality youtube over 3.

And we're dealing with a fat bursty "single TCP stream" links too - much room for improvement - e.g. yt-dl can resume a previous partial dl, this means that the yt server will download from any point in the file/stream, which means we can do multi-path, to increase dl speed. If the net is compelling, and has safe fallback modes for non-important clear net comms (UI behaviour must be absolutely unambiguous to end user), and perhaps a killer app comes along, we have a moon shot chance at replacing the internet as we know it. Which is, of course, the goal.

Unlike Tor, if as in Phantom every user is a relay, there should be plenty of excess wheat-idle capacity because users are mostly idle.

Ack.

...

Phone calls require QoS.

Both the Internet and Tor have no QoS, yet users have been able to hold voice and IRC conversations between Tor onions since day one, with some even being able to stuff low quality video calls over it as well.

In a fill network, so long as fill yields to for wheat demand, the only real constraint seems how the overlay's transport such as TCP / UDP and or some proprietary bucket transport handle congestion when two or more users traffic shares the same physical path between nodes.

For QoS, and in general, this conversation seems to be merging on a concensus of "be conservative, keep a little headroom, rather than absolutely max out the links". And, each node is its own final authority to ack or nack - a node which acks a QoS, yet does not deliver, has its "ability to deliver phone call class QoS" metric reduced.

...

I don't understand the consideration

Overall point was, are people building some overlay to handle only one app (messages, storage, IRC, whatever), or a general purpose transport overlay like the internet that can carry whatever. Presuming both can be done equally securely and performant, there is no point to do the former.

Thanks - yes, ack.

Lots of research and nets out there "We're building an overlay for this specific app".

That being, much more research needs done in area of application agnostic, general purpose transport, traffic analysis resistant, networks.

Research, or empirical. I don't need to see research, to have a gut feel that a) "each node is its own primary authority" and that b) "each link is nogotiated, and acked/nacked between nodes (not by any central authority)", means we may well be able to make the generic packet switched overlay work in an application agnostic way, notwithstanding that certain app transports may be effectively built into the lowest overlay layer (e.g. low b/w, very high latency, high value short text messages and related ping circle userspace).

If you can figure out how to do the latter, the former is entirely moot. Study the latter first.

Ack.

...

In an overlay net, we think of a link as peer to peer.

But physically that link is usually as follows:

NodeA -> ISP1 router -> GT-1 router ... ... -> ISP2 router -> NodeB

Wo when we talk base fill/ linerate/ fulltime chaff link, we should perhaps be clear about which physical links/routes we are referring to - we must consider the physical links as much as the virtual/ overlay links, in order to properly assess security implications.

In a fill-as-defense model, overlay links dont care about the physical between, only that whatever the two overlay nodes agreed about bandwidth and timing expectations they have for each other is upheld between them.

This is the first step to such defense, yes.

If it isn't, they or their internet path between is under attack either by nature or adversary, the contract A B negotiated between themselves will fault, and they should sleep / drop / renegotiate, before passing data for the overlay again.

Ack.

On Sun, Oct 27, 2019 at 08:50:03PM -0400, grarpamp wrote:

...

The problem is the node that was attacked with a latency injection attack - he just got attacked, his friends have now dropped him, and the Feds just identified whatever it was he was up/downloading

No, ident requires timing attack to propagate thereby exposing the end-to-end speakers. Node X, or its path to some other nodes was attacked, X's relavant peer nodes connected to X detected that disturbance in X's transmissions, and refused to forward on anything X sends (meanwhile the entire overlay is filling and reclock normalizing everything anyway).

And in this case, let's say X was uploading the next helo gunship collateral murder video, was half way through, is attacked, does not get to finish uploading. GPA was monitoring the upload, thus why GPA attacked X (and others in their target set), and due to the [temp|full] link dropout (latency trough), GPA IDs node X as the uploader. But, same problem even if link not dropped, and just a latency trough - target X, is now IDed by GPA. In both cases a) X's uplink dropped, or b) not dropped, there destination of X's upload, sees the [temp|permanent] dropout.

You could cut X's stream off from the left of Y (that Y normally forwards out its right), Y's CPU either creates fill to replace X's bw contract and sends that out its right, or ultimately renegotiates a lower sum of rates with some of its right peers that accounts for loss of X on its left, Y is now free to accept new contract proposals on its left summing up to the rate that X formerly consumed.

Yes. That is how we must operate - remaining (non attacked) nodes, must continue per chaff fill and renegotiation protocols.

Yes, X got depeered, sucks for X, at least until X reconnects and starts upholding policed timing traffic fill contracts expected, but the attack did not succeed in disclosing anyone who was talking to who end-to-end.

Yes - if X was uploading to a target passively monitored by GPA, GPA should not be able to detect any traffic troughs or dropouts, since the upload target's peers maintain chaff fill in the face of the wheat dropout. Only X is IDed, not also X's upload target. This is certainly an improvement on the status quo. So our problem set is now thankfully reduced to "what can X do to improve his own situation", and the answer appears to be "dark links" of some form.

It's entirely plausible and reasonable that in decades post-911 post-Snowden, G* may now have laughably trivial end-to-end who-to-who traffic analysis attacks that none of today's overlays are strongly resistant against. Most of today's overlay networks design-think predates one or both of those revelations and confirmations, and applies little of the new crypto and network research that has evolved since either of them.

If you (or anyone following along) is aware of specific cutting edge research that you believe applies to this problem domain, please of course post a link, and ideally a description. Now is the time to consider the cutting edge, what we can incorporate.

You need

s/you/we/

to come up with projects and overlays whose whitepapers clearly indicate solid resistance measures to G* TA (instead of disclaiming / dodging / burying / ignoring the topic as is the norm today), and whose analysis whitepapers by external reviewers cannot find fault with their approach (certainly at least not to any materially use case significant odds of success, unlike with todays overlays).

Logic is logical for a reason. Those who write whitepapers have the time and motivation to do so. We are writing here a whitepaper without polishing it for publishing. Anyone motivated to polish that which we discuss, into a whitepaper, is encouraged to do so. Short of that, we're coming to conclusions as best we can. Anyone who identifies errors in our logic or unspoken assumptions or etc, is encourage to name such, at the moment you cognize such.

There are probably a variety of design and tech can be applied towards that. Both for general purpose overlays, and app specific overlays.

Have fun creating and deploying them :)

I personally intend to focus primarily, though not exclusively, on a packet switched network layer. To this end we have a few more concepts to lay out and tear apart yet. Also, we should continue to put forth and discuss certain concepts which app layers can build on, in particular distributed cache incentivization. A big-I Internet replacement, must target both the comms, plus the content storage, not just one or the other - on occasion the dynamic between two core concepts gives rise to a breakthough. E.g., if we can sufficiently incentivize decentral opportunistic cacheing, we are very close to replacing cloudflare, akamai and youtube. And if with some DHT, P2P, possibly git style content distribution mech on top of opportunistic intrinsically incentivized cacheing, we may effectively and readily eliminate the need for all webservers - where every end user node can at any time publish anything, as long as he has an audience interested in his publishing, and that audience naturally caches that content, at the minimum for the time required to view that content and/ or decide whether to store it longer term in local library. How close we can get to replacing the Internet as we know it is yet to be determined, and there is apparently no inherent reason we cannot achieve this goal. The reason the centralizers exist is due to the nature of profit maximizing "content producers" holding the tide back against what is now possible. We begin from the present moment. We are not bound by the present manifestations of past intentions. We carve out our collective future with our intentions, will and actions today. Create our world,

Awesome! Thank you for this clarity. I had not grokked the below. On Mon, Oct 28, 2019 at 01:33:29AM -0400, grarpamp wrote:

...

GPA was monitoring the upload, thus why GPA attacked X (and others in their target set), and due to the [temp|full] link dropout (latency trough), GPA IDs node X as the uploader. But, same problem even if link not dropped, and just a latency trough - target X, is now IDed by GPA. In both cases a) X's uplink dropped, or b) not dropped, there destination of X's upload, sees the [temp|permanent] dropout.

No. First principles... under a proper enforced and regulated background of fill traffic network, there is no such observables for GPA to monitor, so nothing to attack (which a GPA doesn't do), no ID to be made.

Now if a GAA is an agent running the central server receiving the upload, and they're fast enough to recognize the content on their filesystem as such before it completes, they can try to DoS back their own overlay hops toward the uploader in realtime.

At first that would seem hard to defend against.

Then you realize that again, a proper fill contract aware network will auto detect and depeer any link that gets DoS, thus the upload stops well before it can ever be tracked back. And GAA has to literally sweep through the entire overlay spiking at tens of thousands to millions of nodes (because every node is a relay, linear search odds) trying to find the point source that causes the server upload to stall. And if the user has selected a higher hopcount for their side, odds are that much higher that GAA will spike one of those first again depeering the path and ending the upload before discovery.

The upload might continue a bit slower in a multipath or scatter mixnet, or if either the depeered node renegotiates back in, or the source repaths another circuit around. Whichever way the GAA has discovered nothing and is back to step one at that point... the depeering problem.

Nodes might publish a number of depeering tolerance parameters, or network metrics seen of peers, such that clients could use them when constructing paths on continuum from more reliable to more secure as desired. The particulars of what observables drive depeering thresholds should be, and whether an overlay can perform whatever self management tasks well... all need tested out.

Regardless, sensitive users should not upload to any plausibly owned / suspect / scene central servers, and instead should insert into any distributed encrypted file storage overlays, IPFS, generic surface websites or hosts, upload encrypted blobs and release the keys elsewhere, use wifi, vpn, etc.

Any candidate network for any nextgen award in the subject line should raise the bar significantly such that only the highest sensitive and smallest number of users would have reason to argue.

That is simply not the case with today's networks.

...

incentivize

Incentive is that secure network platforms provide generic transport for cool apps and services that people want to use. Most users are not going to hack their nodes to disable giveback, and or the network will detect that, or have natural consumption limits. Again ventures into generic transport network built for mass utility vs network built for some specific app or class of app... the former has probably not yet received its fair share of development consideration over the last decades.

As before, have fun creating and deploying new stuff.

On Mon, Oct 28, 2019 at 05:19:08PM -0300, Punk - Stasi 2.0 wrote:

On Mon, 28 Oct 2019 01:33:29 -0400 grarpamp wrote:

...

Then you realize that again, a proper fill contract aware network will auto detect and depeer any link that gets DoS,

The 'literature' I've seen so far (up to 2007) mentions Pipe-Net 1.1 a few times and they say that when a Pipe-Net link is attacked, the whole network shuts down in self-defense. Which isn't too practical or robust...

Indeed. Grarpamp's presentment makes much sense on this - nodes don't drop all links (and domino this out) just because one went bad. For 1995, pipe-net was the cutting edge, and vs the newer Tor: besides more onion/ less packet switch, Tor just seems to have introduced TCP as base layer to f@#$ things up - although arguably, since TCP makes life easier for the prototyper (no having to handle the things TCP handles, like re-sending, re-sequencing etc) - if Tor weren't so funded, we could argue it's just a prototype, but since it is so well funded, the more plausible explanation is that its problems are intended.

I haven't looked into how the the thing actually works yet...

http://www.weidai.com/pipenet.txt

...but I'm puzzled by the fact that the people commenting on pipe-net (like adam back) don't suggest the apparently obvious improvement of cutting links selectively instead of shutting down the whole thing.

On Tue, Oct 29, 2019 at 11:27:43AM +1100, Zenaan Harkness wrote:

Re randomized fan outs, here is a bit of a conundrum/ potential opportunity - in the balance between various options available to us:

- Does it make sense for N0 to leave certain routing decisions to another node in its route?

- Is the "fan out + randomize" concept identifiably useful for certain use cases?

- For say N2 to do a randomized fan out in on incoming packets from N0 (say via N1), N2 will have to buffer the incoming packets over time period units of T, so that it has > 1 packet to on- send in a randomized fashion;

The above is incorrect: N2 could "round robbin" incoming packets, or rather randomized round robin, the packets incoming from route N0 (via node N1) to node N2. Of course, this would introduce visibility if not chaff filled, if we are working with one packet at a time. Maintaining link rate means sending one packet per time period, and sending chaff if we don't have wheat. Therefore, for fan out to be network efficient, fan out links need to be proportionally smaller b/w than the incoming link, which is another "obvious visibility" issue in relation to G*A.

this naturally introduces latency - which of course is acceptable, even desirable, depending on use case - we're now

and of course, undesirable in other use cases

conceptually heading into random latency/ high latency mix net design territory.