Re: [tor-bugs] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:                                       |         Points:  1
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:5 dgoulet]:
 > Replying to [comment:4 teor]:
 > > Replying to [comment:2 dgoulet]:
 > > > Oh dear... hmmm proposal 224 makes IPv4 *mandatory* in order to
 extend to the relay and seems in this case you have IPv6 only?...
 > >
 > > The single onion service in this test can only make IPv6 connections.
 > > This works for v2, but not v3.
 > >
 > > > Is this something we want to allow right now or should I say simply
 possible to have NO IPv4 for a relay?
 > >
 > > We can make IPv6 work with single-hop client and service connections
 to intro and rend points. It works for v2 single onion services. We talked
 about it for v3, but it never made it into the prop224 spec.
 >
 > Yeah, it will make it with #23502. Spec and code change for that matter.
 Basically, any link specifiers for the IP (in descriptor) and RP (in INTRO
 cell) were requiring an IPv4 else you couldn't use the relay.

 But this is fine at the moment.

 All relays have an IPv4 address, so clients and services can put them in
 the link specifiers in the descriptor and introduce cell.

 > >
 > > Edit: I opened #23507 with a list of steps we can add to the spec. We
 should implement them in this ticket!
 > >
 > > I don't see how #23502 is a dependency. Initiating clients/services
 should always include IPv4 and IPv6, even if they wouldn't use them (step
 0). And responding clients/services should use a direct connection if
 available, or a 3-hop connection if not (steps 1 & 2).
 >
 > In this scenario, no IPv4 were available with this chutney test

 I don't understand what you mean here.

 The service connects over IPv6, but it has a consensus with an IPv4
 address, why isn't it using it in the link specifier for the intro point
 in the descriptor?

 > so the code was just saying "nope" and you wouldn't pass step 0 which is
 what #23502 is addressing.
 >
 > Then considering the above fixed, you are right that if the chosen IP
 can't be reached via a direct connection, we fallback to 3-hop, see
 `pick_intro_point()`. However, for the RP, I'm not sure there is a
 fallback, even for v2... See `pick_rendezvous_node()`, that fallback
 concept is only if `ENABLE_TOR2WEB_MODE`.

 That's ok, it's only needed in Tor2web mode: all other clients connect
 using a 3-hop path through a guard or bridge they can reach.

 > The second thing here that I want to raise is that including both IPv4
 and IPv6 is *not* possible right now within tor and the reason is that
 from a `node_t`, we create an `extend_info_t` object used for opening a
 circuit and that object can only take one type of address, v4 or v6
 (`tor_addr_t addr`). Furthermore, the `extend_cell_format()` simply
 doesn't care at all about IPv6. (#22810 is probably relevant and should be
 expanded to IPv6 also).

 Sending an EXTEND with IPv4 is ok at the moment, but it will need to
 change for relays to extend to IPv6 (for example, IPv6 ORPort self-
 checks). I think there is a ticket for this already.

 > So, IPv6 can only be used in a direct connection really and is entirely
 ignored for 3-hop.

 Yes, at the moment.

 > If you can confirm the above, we should open tickets about all that.

 Some already have tickets.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23493#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs