[tor-relays] About relay size

Wed Oct 4 05:49:58 UTC 2017

> On 4 Oct 2017, at 01:38, grarpamp <grarpamp at gmail.com> wrote:
> 
> ... Exits would have
> to tag their support of "exit v4 and/or v6 to clearnet"
> in consensus so circuits get built to a place that
> can actually ship the client's cells out to clearnet.
> Relays WAN function already offer inbound connection
> capabilities by their listed OR IP format in consensus,
> but not yet any outbound IP version, which client must
> also know from consensus and compute to reach next input.

The ExitPolicy ad IPv6Exit options on Exits are put into the relay's
descriptor, which gets turned into the microdescriptor, which clients
use to select exits.

And most clients just send a DNS name and a set of IP version flags.

For the rare cases where literal addresses are used, or there are
IPv6-only websites over DNS, tor could be smarter.

We accept patches, but it's not a high priority, because it works for
almost all hostnames / addresses that clients actually use.

> Building WAN paths is different from what is carried within.
> So that, it seems possible, if in consensus, to make WAN path like...
> v6 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v6 ==> v6 clearnet
> v4 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v4 ==> v4 clearnet

This abstraction layer exists in tor and it works fine.

> On 4 Oct 2017, at 00:49, Scott Bennett <bennett at sdf.org> wrote:
> 
> teor <teor2345 at gmail.com> wrote:
> 
>> 
>>> On 3 Oct 2017, at 08:52, Scott Bennett <bennett at sdf.org> wrote:
>>> 
>>> teor <teor2345 at gmail.com> wrote:
>>> 
>>>> 
>>>> On 3 Oct 2017, at 03:07, Scott Bennett <bennett at sdf.org> wrote:
>>>> 
>>>>>>> In the meantime, I think it would be great to have IPv6-only relays, to
>>>>>>> avoid this kind of NAT-related issues.
>>>>>> 
>>>>>> We'd love to make this happen, but the anonymity implications
>>>>>> of mixed IPv4-only and IPv6-only (non-clique) networks need
>>>>>> further research. Search the list archives for details.
>>>>>> 
>>>>>   Couldn't that be taken care of in the tor client code?  For example, a
>>>>> client, having chosen a path through which an IPv6-only relay, could extend
>>>>> the path by one hop to tunnel through a node with both types of interface
>>>>> published?
>>>> 
>>>> Yes, clients choose paths, and could choose them using these kinds of
>>>> restrictions. But current tor relay versions won't extend to other relays
>>>> over IPv6. Because we don't understand the anonymity implications of
>>>> restricting the next relay in the path based on the previous relay. Which
>>>> is why we need further research.
>>> 
>>>    Here's a procedure:  if the next hop/destination does not use a protocol
>>> in common with the client/current hop, a dual-protocoled node must be
>>> interposed; else use the originally selected hop/destination directly.
>> 
>> But is this procedure safe?
> 
>     Why might it not be safe?

Because it may make clients distinguishable from each other. Client
indistinguishability is a key part of tor's anonymity design. I encourage you to
read the original Tor paper.

>> And is it an efficient use of resources to add extra hops?
> 
>     Well, the additional hops ought to increase the safety.  Wouldn't that
> have to be considered in an efficiency calculation?
> 
>> (That is, is there a more efficient 3-hop algorithm that's just as safe?)
>> We need research to answer these questions.
> 
>     It seems to me that a) using a small number (i.e., 3) of hops reduces
> safety and b) a constant number of hops also reduces safety.  Added hops to
> make an unpredictable path length ought to counter the alleged safety issues
> in choosing hops from a smaller pool.

No, because added hops make clients distinguishable via latency, and as far as
we can tell, they don't increase safety. There's a paper on this, too.

> Also, unless the pool of dual-protocol
> hops is much smaller than the number of relays available, say, ten years ago,
> I don't see a reason to worry.  (We were thrilled to have 900 - 1300 up at
> any one time.)

Tor provides better anonymity guarantees than it used to ten years ago.
So it's today's anonymity we need to measure against, not 2007's.

>>> The client-to-first-hop situation is analogous to using a set of entry guards
>>> today, so that much should be okay.  What do IPv6-only clients currently do?
>> 
>> Choose a relay with an IPv6 ORPort.
>> (Or configure a bridge with an IPv6 ORPort or pluggable transport.)
>> 
>> IPv6-only clients need to be manually configured using "ClientUseIPv4 0",
>> because this feature is still experimental. We think it will be safer when all
>> dual-stack clients use some IPv6 guards.
>> 
>     Dual-protocol clients connecting to dual-protocol entry nodes ought to
> choose randomly which protocol to use.  Similarly, a dual-protocol relay
> extending to another dual-protocol relay ought to choose randomly which
> protocol to use for the connection.  Both clients and relays would have the
> option of retrying the attempt via the other protocol in the event a failed
> attempt to connect.  This ought to have been implemented already, but can
> still be done soon.

I agree.

We accept proposals, and patches. I've been trying to find time to write these
ones.

If my emails are a bit short, or a bit repetitive, or point you to other
resources, it's because I'm trying to keep some time for volunteer development
work like this.

>>>    Allowing IPv6 destinations today limits exit-hop selections to dual-
>>> protocol-capable exit nodes
>> 
>> No, IPv4-only exits are still useful and used, because tor clients typically
>> send DNS names to exits. IPv6 DNS records typically have IPv4 as well,
>> so any exit will work. (There's a ticket for better handling of DNS that
>> only resolves to IPv6.)
>> 
>> And in the rare case of address literals, the client can choose a capable
>> exit. (I think there's a ticket for this, too.)
> 
>     Okay, but those circuits are incidental to the circuit that a user wants,
> which is limited to dual-protocol-capable nodes.

No, this isn't how tor works. Read the relevant proposals, or the source code.

>> ...
>>> How
>>> long would that list have to be for the warning on the man page under the
>>> ExitNodes statement definition to become unimportant?  How many were there
>>> when IPv6 destinations were first allowed?
>> 
>> The situation isn't analogous.
>> 
>> For safety, IPv6 exit destinations were turned off by default until we had enough
>> IPv6 exits. Now they are on by default.
> 
>     I repeat:  how many were there when IPv6 destinations were first allowed?

I don't know. Read the relevant proposals.

> How many when the default was changed?

I don't know, but I think it was 2016, so you can check the metrics graphs.
(Do we have a metrics graph for IPv6 exits? Or IPv6 ORPorts? Maybe we should!)

>> But we haven't done the same thing for relays, because we don't know how to
>> design the feature so it's safe.
> 
>     As soon as there are as many IPv6-capable relays as there were IPv4
> relays ten years ago, there will no longer be any reason not to enable their
> use.  How close are we to reaching that number now?  Or have we already
> passed it?

It's today's anonymity we need to measure against, not 2007's.

>>>    For interposing dual-protocoled nodes along the way, how many do there
>>> have to be for it to become "not too limiting"?
>> 
>> This is one of the questions we need researchers to answer.
>> 
>     Maybe.  That depends upon whether we already have at least as many as
> were considered safe for IPv4.

So it's today's anonymity we need to measure against, not 2007's.

>>>>> A related question is can a relay with only an IPv4 address
>>>>> published currently set an IPv6 OutboundBindAddress?
>>>> 
>>>> Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
>>>> 
>>>    That's okay, but what if the node is an entry-and-middle node only?
>> 
>> Relays don't extend to IPv6, so you can set the option, but it won't do
>> anything, because there are no outbound IPv6 connections.
>> 
>    But they could, and ought to, be doing that, at least in some
> circumstances, as noted above.

I agree.

But email threads can only achieve so much.

The next step is a proposal, and then a patch.

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171004/d12eabdf/attachment-0001.sig>