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.