[tor-dev] Alternate Single Onion Service Designs

[Alec Muffett]

> On Nov 6, 2015, at 4:56 PM, teor <teor2345 at gmail.com> wrote:
> Do we need both single onion services (Proposal 252) and rendezvous single onion services?

I would say they are both desirable, and that we could/should have both.

RSOS is great for adoption, the rendezvous step enables NAT-punching and yet lowers latency.

The NAT-punching is particularly desirable where - like in our configuration - the tor daemon resides in a DMZ enclave without inbound connectivity.

See diagram at: https://twitter.com/dcuthbert/status/573197027242315776/photo/1

Source: https://storify.com/AlecMuffett/tor-tips

RSOS thereby also offers a easy, nearly-no-rearchitecture-required route to enterprise deployment.

Also RSOS enables OnionBalance, and other performance hacks such as those proposed by Tom van der Woerdt (https://lists.torproject.org/pipermail/tor-dev/2015-October/009618.html) all without requiring broad changes to deployed Tor daemons

SOS by comparison sounds best where pure performance matters, but I am not sure how the other scaling solutions will fit into it; but pure performance matters a lot, so overall I think I’d like to see both.

My plans for Onion scaling are approximately as follows:

1) Remove unnecessary privacy hops / deploy RSOS (in progress)

2) OnionBalance: Merge introduction points (IPs) from multiple daemons into one descriptor (possible issue: there is a hardcoded limit of 3x IPs?)

3) Steven Murdoch / Ceysun Sucu research: Implement distinct OnionBalance descriptors at each (6?) point on the HSDir ring

These three solutions in aggregate should lower latency and scale tor daemon bandwidth by a range of 18..60x

Then:

4) (Wishlist) implementation of TVDW's handoff of RP callback

...which will resolve any remaining CPU-bandwidth issues.

These plans are subject to change, but seem reasonable so far.

    - alec


> I see at least the following scenarios for using these alternate single onion service designs:
> 
> 0. an onion service operator who wants to minimise latency and maximise bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous protocol)
> 
> 1. an onion service operator runs a SOS for new clients, and an RSOS for old clients (a RSOS is compatible with current clients, a SOS Is not)
> 
> 2. an onion service operator who can’t expose an ORPort runs a RSOS for all clients (there are enclave and NAT configurations where external ports are an issue)
> 
> 3. an onion service operator who wants to use Proposal 255 for load-balancing runs a RSOS, and splits their introduction and rendezvous instances by passing the introduction over the control port (proposal 255 relies on the rendezvous protocol to handoff the rendezvous point connection to another Tor instance)
> 
> 4. an onion service wants low latency and better bandwidth, and doesn't want to wait until the SOS feature is developed and deployed (SOS is a larger feature, and it needs client changes). They'll switch to SOS when it's well supported by installed versions of Tor Browser.
> 
> Given these use cases, I think we could implement both flavours of single onion service. But this splits the onion service anonymity set at least 3 ways (and maybe also by some other onion service features). I'm not sure how much of an impact this will have - it does depend on our threat model for each flavour of onion service.
> 
> If we wanted to generate more onion service cover traffic, we could move various automated Tor Browser actions (such as update checks and update downloads) to appropriate flavours of onion service. This would shift load away from exits, and also have address authentication benefits. (Tor Browser wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.)
> 
> The other mitigations I'm aware of are cover traffic and lookalike protocol interactions, but these require significant research and design work.
> 
> We're working on implementing rendezvous single onion services in #17178. I think they're pretty close: we need to do some more testing, and handle some edge cases. RSOS servers work with existing clients, including current Tor Browser releases.
> 
> Single onion services (Proposal 252) is a larger feature, so it's a bit further away. SOS are incompatible  with current clients, so supporting code will need to be deployed in Tor clients (such as Tor Browser) as well as on the onion service itself. After the feature is ready, there will be some lead time before SOS are usable with the majority of deployed Tor clients.
> 
> What do you think?
> Are onion services big enough to safely have multiple flavours?
> Could they get that big if we support enough functionality?
> Or are we better to implement secure, one-size-fits-all defaults, and ask users and operators to sacrifice some performance?
> 
> Tim
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP 968F094B
> 
> teor at blah dot im
> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.torproject.org_cgi-2Dbin_mailman_listinfo_tor-2Ddev&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=T4UdyZF0g0I68UQdhjA_7A&m=39qCF0WwsOlclgI4JLpSsdoQf3OFoAoioXMj3Yl9cSo&s=62XIjIsvN1QdwcbCz2d3zq1T9iYCDY5GVPmORfbvhKU&e=

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151106/515cee82/attachment.sig>