On 2 Oct 2015, at 14:43, Tom van der Woerdt < info@xxxxxxx> wrote:
Hi Tim, Thanks for your great comments, very much appreciated! Comments inline. Op 30/09/15 om 19:40 schreef Tim Wilson-Brown - teor:
On 30 Sep 2015, at 17:27, Tom van der Woerdt <info@xxxxxxx
<mailto:info@xxxxxxx>> wrote:
...
Filename: xxx-intro-rendezvous-controlsocket.txt
Title: Load-balancing hidden services by splitting introduction from
rendezvous
Author: Tom van der Woerdt
Created: 2015-09-30
Status: draft
1. Overview and motivation
To address scaling concerns with the onion web, we want to be able to
spread the load of hidden services across multiple machines.
OnionBalance is a great stab at this, and it can currently give us 60x
the capacity by publishing 6 separate descriptors, each with 10
introduction points, but more is better. This proposal aims to address
hidden service scaling up to a point where we can handle millions of
concurrent connections.
The basic idea involves splitting the 'introduce' from the
'rendezvous', in the tor implementation, and adding new events and
commands to the control specification to allow intercepting
introductions and transmitting them to different nodes, which will then
take care of the actual rendezvous.
…
In general, I’m concerned that we need to think through the
implementation of this proposal more carefully, because it will help us
decide whether it’s compatible with:
* Current Hidden Services
* Next-Generation Hidden Services
And perhaps make changes to any of these proposals to make them work
together.
Thoughts welcome! I don't think I'm the right person to address those.
I’d also note that it’s definitely not compatible with Single Onion
Services as specified in Proposal #252, as there is no rendezvous in
that protocol.
Indeed.
Splitting the introduction and rendezvous is another use case for NAT-punching single-rendezvous-hop onion services.
However, splitting hidden services into multiple different implementations provides less cover for users who really need three-hop hidden services. We’ll need to decide what the tradeoff is here.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
|