teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 08:52, Scott Bennett bennett@sdf.org wrote:
teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 03:07, Scott Bennett bennett@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 protocolin 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?
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. 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.)
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.
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.
which is like using an "ExitNodesIPv6" (if there were such a thing) line in torrc with a long and growing list of nodes.
There are flags on SOCKSPort for IP versions, including PreferIPv6, which is the default.
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? How many when the default was changed?
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?
For interposing dual-protocoled nodes along the way, how many do therehave 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.
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.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************