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

[Tim Wilson-Brown - teor]

> 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

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>