Delivery-Date: Thu, 12 Mar 2015 09:23:39 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD,URIBL_BLOCKED
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id D0E611E039D
	for <archiver@seul.org>; Thu, 12 Mar 2015 09:23:37 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 35D52344EB;
	Thu, 12 Mar 2015 13:23:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 8D41F344E5
 for <tor-talk@lists.torproject.org>; Thu, 12 Mar 2015 13:23:30 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id jDJWbeWcI0Cz for <tor-talk@lists.torproject.org>;
 Thu, 12 Mar 2015 13:23:30 +0000 (UTC)
Received: from windmill.donncha.is (unknown [IPv6:2001:41d0:8:da8a::1])
 by eugeni.torproject.org (Postfix) with ESMTP id 4140B34451
 for <tor-talk@lists.torproject.org>; Thu, 12 Mar 2015 13:23:30 +0000 (UTC)
Received: from [192.168.42.62] (unknown [80.111.240.26])
 by windmill.donncha.is (Postfix) with ESMTPSA id 30FF516FD
 for <tor-talk@lists.torproject.org>; Thu, 12 Mar 2015 15:03:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=donncha.is; s=dkim;
 t=1426168982; bh=OeOHoUuKaNuzLukxJdRM9oOgSf+8cS4ABcn/HP0dWVQ=;
 h=Date:From:To:Subject:References:In-Reply-To:From;
 b=YHIM4PLE/WdNMoFP84fk8wzdje+cshUFSrYLlKLIkv+LfbCyCRCRegMmzQ8djQP55
 xrs09I3l3RspL7nQYAXAuebFHIwVo2aEUIuDHrgWpo9kxGBI9umGHdj3WL/o7bxOUU
 5zgkH3seGggqnuxABE0eeSlATMeuFVEcbR3gnmLA=
Message-ID: <5501932E.80703@donncha.is>
Date: Thu, 12 Mar 2015 13:22:54 +0000
From: Donncha O'Cearbhaill <donncha@donncha.is>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <A6DD5B99-8E6D-4B21-AC82-14E92C8C6332@maclemon.at>
 <87d24f8mb1.fsf@riseup.net>
In-Reply-To: <87d24f8mb1.fsf@riseup.net>
OpenPGP: url=http://donncha.is/donncha.asc
Subject: Re: [tor-talk] Load Balancing/High Availability Hidden Services
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4430844805395545556=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4430844805395545556==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="B2TjwwtAQbNOROdIRgKxN6KeWqXL1jQ7A"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--B2TjwwtAQbNOROdIRgKxN6KeWqXL1jQ7A
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 11/03/15 17:40, George Kadianakis wrote:
> MacLemon <tor@maclemon.at> writes:
>=20
>> Hoi!
>>
>> I'm looking into ideas for creating =E2=80=9Cload balanced=E2=80=9D or=
 =E2=80=9Chigh availability=E2=80=9D hidden services. Mostly pertaining t=
o web servers serving large-ish static files. (Let's say 5-100MB each.)
>>
>> Load balanced as in not all requests end up at the same box to speed u=
p downloads.
>> High availability as in the service is still available if one box goes=
 down or is taken offline for maintenance.
>>
>> So, not exactly your usual distributed-cluster setup.
>>
>>
>> From what I understand it would not make sense to run the same HS Key =
on multiple boxes since the descriptors would overwrite each other every =
few minutes.
>>
>> I don't think one can do something like Round-Robin DNS with HS.
>>
>> So the only way I can imagine this to work is a central redirection no=
de that know about all the nodes and more or less intelligently/randomly =
302 redirects each file request to a known-to-it server.
>>
>> This still leaves a single-point-of-failure in form of the redirection=
 server but would at least distribute the traffic load across multiple se=
rvers and cope for nodes coming and going.
>>
>> Has anyone done something like this?
>>
>=20
> An application-layer load balancer like HAProxy might be able to help y=
ou.
>=20
> Unfortunately, there is not something equivalent to DNS Round Robin
> for hidden services yet. There are some ideas on how to do this on the
> Introduction Point-layer, but a proposal still needs to be written. For=

> further reading:
> https://lists.torproject.org/pipermail/tor-dev/2014-April/006788.html
> https://lists.torproject.org/pipermail/tor-dev/2014-May/006812.html
>=20

I've been thinking a little about this problem. It seems like one simple
solution would be to find a way of combining the
descriptors/introduction points from multiple Tor HS instances into one
hidden service descriptor from which the client can pick intro points at
random.

To implement such a solution like that, there needs to be a means for
the hidden service instances to communicate with other. They can then
either selected a common set of intro points or combine the individual
sets of intro points selected by each instance.

In one straight forward implementation a hidden service operator could
set up a Tor relay and a hidden service on each of their load-balancing
nodes. These load balancing hidden services SHOULD have different hidden
service keys and could use stealth authentication for privacy (so that
their introduction points are encrypted).

A management server would contain the actual hidden service key but
would not need to run any hidden services. The role of the management
server would be to regularly fetch descriptors for the load-balancing
hidden services, combine the introduction points into a single
descriptor for the hidden service which is then published as normal.

After the signature on the hidden service descriptor is verified there
is the hidden service protocol doesn't user the permanent key/onion
address. As such there is no need for each of the relays to have a copy
of the hidden service key.

I think this provides a couple of advantages:

	- The hidden service key only needs to be in one place. The machine
holding the key would generate very little traffic and would not be
locatable by the publically known hidden service attacks.

	- The hidden service key could be stored encrypted on the management
server.

	- If any of the load balancing relays are compromised an operator
simply needs to stop including its introduction points in the
descriptor. This should minimise the need to 'revoke' hidden service keys=
=2E

The number of introduction points in a HS descriptor is currently
limited to 10 in Tor. This sets a limit on the number of load-balancing
nodes that could be deployed at present.

This approach doesn't require any changes to the Tor code base at all. I
hope to implement a management server in the next few weeks to test how
this works in practice.

It would be great to get any feedback about this proposal!

Regards,
Donncha




--B2TjwwtAQbNOROdIRgKxN6KeWqXL1jQ7A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGcBAEBCgAGBQJVAZNFAAoJENYNZOc0WPKF9jAL/iJ/+VPLzmzm+ahhytPFV2eE
E+yverRtot9v4GIEfh/hm7omwLFN3hUSmHDKRuPluDNsF3++WLgEsL2TpXskyzJN
Af/gBQRt78ejVPDUu/Z8Iqq/wXLYel6EiEE8Zjjq6lEv/d1isH02x378N+jYz2+e
iHiismwU8Uv9w6bZAc9tfGqn/5bT6+iGLAwxs/EqoXMb3heK9g9Uu/tpxmQdxC5x
aid7/jz00BW8glPf/gopNYltr5hS6M7kjJ3Pd5yFW0VKK2WtnkKz2SG8f2PObdqW
fAbwAUOq73s5APH8k2j3jK4s7PDc9qObDhFDKOBDpAdulxjDUStqdjYAPG/EhvF6
fZzZVzMcPZHe9LcTdwwWRr0Fd2LqfHXfB0nt/3rI8MK5zDlNYCblmNYW02CwhgcH
dp2QyY5Jf6nSCCHmvPf180OyUVXqLds6TWB3ldFFyFXyUebwwWjNfSKiLKLNFRRq
8S1Vgf0ZGzBulbTs10LFZyVserL4GjdhIRsTReFVDA==
=gpzu
-----END PGP SIGNATURE-----

--B2TjwwtAQbNOROdIRgKxN6KeWqXL1jQ7A--

--===============4430844805395545556==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============4430844805395545556==--

