On Mon, Oct 21, 2019 at 06:27:42AM -0400, grarpamp wrote:
On 10/17/19, coderman <coderman@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? )