Nextgen G* Traffic Analysis Resistant Overlay Networks (re Tor stinks)

[Zenaan Harkness]

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.