Re: [tor-talk] Massive Bandwidth Onion Services

[Alec Muffett <alec.muffett@xxxxxxxxx>]

On 23 Dec 2016 2:02 am, "Ivan Markin" <twim@xxxxxxxxxx> wrote:

You'll have to do this after prop224 because of onion key
cross-certifications, so fancy plain OnionBalance "renaming" won't work
(HSDir system is unidirectional).


I did wonder; that said, all the nodes will know about each other, so they
can chat to each other using the existing "worker" onion addresses

I agree with George, this is not good to upload so many descriptors and
building so many useless circuits.


The cheap solution is that that will go away when I can set
NumIntroductionPoints to 1; because the new architecture will _require_ me
to use onion addresses to chat between worker-systems, the number of
descriptors and circuits will be effectively irreducible, thereby solving
George's/your concern on that front, too.

If you want to retain nice "hole punching"
feature of tor why not just use backchannel onion service (one per
cluster) for this? (Donncha actually mentioned this in the docs)..


Oh, I shll use the backchannel onion addresses.

What I regret is that the new architecture significantly complicates the
"background" communications for such a deployment, turning it from:

  "scrape the available worker descriptors and publish a master descriptor,
carry on regardless"

to:

  "an n-squared mesh of daemons which have to communicate with and
authenticate to each other using an application-specific protocol, as well
as maintain some kind of consensus of which workers are alive, which are
temporarily or permanently dead. Also: shared consensus protocols suck."

In short: not being able to use the HSDirs as a "source of truth" makes the
whole architecture a lot more complex and synchronous.

That's why.  But, y'know, if it's inevitable, it's inevitable.

    -a
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk