Hi,

We just had a meeting to discuss the following tor proposals[0] in the #tor-dev 
IRC channel[1].

Proposal 252: Single Onion Services
Proposal 260: Rendezvous Single Onion Services
Proposal 255: Controller features to allow for load-balancing hidden services
Proposal 246: Merging Hidden Service Directories and Introduction Points

A quick summary of each proposal:

Some onion (hidden) service websites don't need to hide their location.
They can have faster connection setup and bandwidth, and put less load on the 
tor network, by having 3 relays between the client and onion service.

Proposal 252 has the onion service open an ORPort, and then clients extend from 
their third relay to the ORPort.
Proposal 260 has the onion service connect directly to the introduction and 
rendezvous points.

The other proposals improve onion service speed in different ways:

Proposal 255 improves hidden or onion service load balancing by handing off the 
rendezvous to another tor instance.

Proposal 246 improves hidden or onion service setup time by using the HSDirs as 
introduction points, and teaching clients to re-use the HSDir connection for 
the introduction.

And a quick summary of our thoughts:

Proposal 252 and Proposal 260 achieve similar outcomes. 260 is simpler to code, 
preserves NAT-punching (which some website providers need), and has already 
been coded[2]. It's also compatible with 255, which 252 is not. But 252 has a 
faster connection set-up time, because it skips the rendezvous protocol 
entirely. We'd like to see more research into the performance differences 
between 252 and 260.

We want to focus on Proposal 224 (next-generation hidden services), and we were 
concerned that too much other work on onion service proposals would slow that 
down. So we'd like to finish 260 in the short term, and then reconsider 252 
based on resourcing and research outcomes.

We thought that 255 was a good idea, but noted that it increases connection 
set-up time.

We noted that 246 already had concerns raised about it on the mailing list. 
That said, we could use 246 to improve the performance of 260.

Tim

[0]: https://gitweb.torproject.org/torspec.git/tree/proposals 
<https://gitweb.torproject.org/torspec.git/tree/proposals>
[1]: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-02-08-22.00.log.html 
<http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-02-08-22.00.log.html>
[2]: https://trac.torproject.org/projects/tor/ticket/17178 
<https://trac.torproject.org/projects/tor/ticket/17178>


Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
tor-dev mailing list
[email protected]
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Reply via email to