tor replacement - was Re: Box for simple Tor node.

[Zenaan Harkness]

On Wed, Oct 23, 2019 at 05:15:57AM -0400, grarpamp wrote:
> >>     ok, so that's actually one of, or the most fundamental requirement.
> >> The connection between user and 'network' HAS to have a fixed rate.
> 
> Assuming "fixed rate" means "always filled to said rate" not
> "fillable up to said rate"... then that makes every users node
> look nicely busy.

Ack.

"Chaff fill" has become overloaded.

Let's try Link Metrics Normalization or LMN (or something better if
someone speaks up soon):

 1. packets per time unit normalization

 2. packets transmission latency/jitter normalization

 3. packet size normalization (this one's easy)


> And if the rate is the same for all users, then
> every user looks the same.

Ideal operating mode.

Practical (as in acceptable to users) operation probably requires as
coderman suggested earlier, to allow steady stepping upwards/
downwards over time (by config only of course), to provide for the
impatient bittorrent and youtuber crowd. There is no bw cap that will
be accepted by all, probably not even by a majority.


> However all nodes in the net need to be always filled to
> some rates.

Ack. I imagine a network ping (to friend/ connected nodes) on say a
10 minute interval, which from memory was only about 2.1MiB per
month, would be an acceptable base load for everyone, and that many
will accept higher base load than this.


> Otherwise adversary vampire can just watch
> the nodes end user is connected to, or perturb the users
> packet stream, or wait until user unluckily routes across
> quiet middle nodes, etc.

Ack. Gov stalkers gonna stalk.

One limit case to consider is all direct (first hop) p2p/f2f links
are always and only ever, 1KiB/s (say). You want more bw, you add
more separate links, and the disappearing act is handled by stepping
up, and maintaining that rate for some period of time (presumably
longer than actually needed), before eventually stepping down
(removing links).

And the point, in relation to "unluckily route across quiet
(stalking) middle node" - some application of multi-path:

  - 10 trusted friends to whom I hop in to the net

  - 1 dark net server supporting multi path, from which I download
    the latest Adobe Photoshop cr24c/7

  - 10 separate routes to 10 separate "darknet server access point
    nodes"

  - if 1 link gets killed in the middle, my corresponding friend node
    keeps chaff filling to my node regardless, and I can attempt to
    create with him, a new route;
    - also, the other 9 links continue to hum along



> > last but not least, you could apply the padding traffic to key
> > pre-distribution or opportunistic protocol maintenance. e.g. distributing
> > routing and node identity information. (the "directory")
> 
> If pad fill can be used to carry something, better than to
> waste it.