Pipe-Net

[Zenaan Harkness]

On Mon, Oct 21, 2019 at 06:27:42AM -0400, grarpamp wrote:
> On 10/17/19, coderman <coderman at protonmail.com> wrote:
> >> There are many, many analogies you can draw about a network of this
> >> type to an ATM (asynchronous transfer mode) network.
> >
> >
> > i'm old enough to remember writing XTI/STREAMS code for ATM networks. (blast
> > from the past!)
> >
> > ATM CBR SVCs would be a perfect fit for padding schemes, if they existed for
> > consumer use :)
> 
> 
> Telco generated clocked TDM bucket brigades...
> Suggested for years overlays can still emulate them to good use...
> full time chaff padding fill all node-to-node links at negotiated maintained
> rates, displace chaff with wheat as it comes in, reclock and enforce
> the line contracts, keying, etc at the switchports (overlay nodes).
> *VC padding requires lots of management overhead and signaling

  "*VC" ?


> between layers in overlay net to avoid user traffic saturating paths,
> finding bw routes, etc, forget that. Chaff fill at node-to-node
> link layer is easier...

Yes, sounds easier.


> just as physical link crypto over fulltime fill
> works in background between switchports (there are proposals
> for ethernet to do this, embedded PHY instead of aftermarket
> anti-SPY gadget). Nodes already know what other nodes the
> upper layer wants to talk to, so they nego fill with them before
> swapping out lower fill for upper wheat on demand. Tor-like circuit
> extends in upper layer still works. User traffic in upper layers rides
> happy till users fill their own circuits they provisioned into the net,
> no different than tor or any other overlay today.

"provisioning into the net" is interesting

End user can create mini-routes, e.g. ABC, where, if B is "trusted"
(friend) peer node, C can receive (when it decrypts an incoming
packet) a plain text wheat packet. This packet is therefore minimized
in size, and node C can combine small wheat packets into larger
packets (up to MTU size), to send to next hops.

If much traffic using smaller than max packets, it might be better to
have chaff fill links be say 0.5KiB UDP packets rather than ~1.5KiB
packets - or perhaps every link's node pair negotiates between
themselves - packet size changing (over time) could be a similar
"optimization" problem to link bandwidth changing - step up/down as
needed over time (with e.g. random extended time periods at previous
levels before changing to sufficiently neuter GPA traffic
statistical analysis, +/or as opportunistic per stats like TCP
keepalive).

If end user does not trust first hop node AB, he must encrypt route
at least one hop through (ABC), perhaps to foreign jurisdiction for
latency-insensitive apps at least.

(
 "Pure switch based network" implies each peer node being able to
 make all switching decisions - which of course won't fly it the face
 of untrusted peer nodes, which is where at least short onion routes
 must be used.

 The question re this is what ratios of mini onion routes, vs longer
 onion routes, makes sense, for which use cases?
)