[tor-dev] Proposal: Load-balancing hidden services by splitting introduction from rendezvous

Tim Wilson-Brown - teor teor2345 at gmail.com
Fri Oct 2 12:56:35 UTC 2015

> On 2 Oct 2015, at 14:43, Tom van der Woerdt <info at tvdw.eu> 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 at tvdw.eu
>>> <mailto:info at tvdw.eu>> 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 Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151002/fe649a90/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151002/fe649a90/attachment-0001.sig>

More information about the tor-dev mailing list