Opened 2 years ago

Closed 4 weeks ago

Last modified 4 weeks ago

#23507 closed defect (fixed)

Handle unreachable addresses on v3 single onion services by using a 3 hop path

Reported by: teor Owned by: teor
Priority: Medium Milestone: Tor: 0.4.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: v3-onion-service-feature-parity, prop224, tor-hs, single-onion, ipv6, network-team-roadmap-august
Cc: teor Actual Points: 0.2
Parent ID: #23818 Points: 1
Reviewer: Sponsor: Sponsor27-must

Description

Here is how we make IPv6 (and other unreachable addresses) 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.

Here are the steps:

  1. The service chooses and connects to the intro point (possibly using a 3-hop path if it is a single onion service and can't reach it directly)
  2. The service always puts IPv4 and IPv6 in its descriptor link specifiers (if they are available in directory documents)
  3. If the link specifier has a reachable address, and the service is not a single onion service, a Tor2web client (currently v2 only) can use it to make a direct connection to the intro point
  4. Otherwise, the client connects over a 3-hop path via one of its reachable entry nodes

The process for client rendezvous is similar, but if the client knows that the service is a single onion service, it *must* connect to the rend point using a 3-hop path. (Again, this only matters for Tor2web, which is v2 only).

Child Tickets

Change History (18)

comment:1 Changed 2 years ago by dgoulet

Status: newneeds_information

I do think we have all this logic in place already *except* for the concept of both IPv4 or IPv6 but that is a know limitation for now and postponed to 033 (#23502).

Can you confirm it?

  • pick_intro_point() when a service picks intro points.
  • hs_get_extend_info_from_lspecs() is the function called by the client to get the extend_info_t from the descriptor. It has many checks (and some a missing for IPv6 #23502). It WILL NEVER be a direct connection for client in v3 (no Tor2web).
  • hs_get_extend_info_from_lspecs() (same as the above) is used by the service to connect to the rendezvous point. This time it can consider for direct connection.

Again, you'll notice that the IPv6 problem in #23502 aren't addressed but apart from that, is the algorithm you describe followed?

comment:2 Changed 2 years ago by dgoulet

Owner: set to dgoulet
Status: needs_informationaccepted

comment:3 Changed 2 years ago by teor

Keywords: doc added

IPv6 v3 single onion services appear to work on master. We should say that they're using a work around in the 0.3.2 release notes.

But this ticket is about getting the algorithm in the prop224 spec. Then we can document the behaviour we want, and implement the rest of it in 0.3.3.

comment:4 Changed 2 years ago by teor

Oh, no it doesn't work on master. I think we should fix that.

comment:5 in reply to:  1 Changed 2 years ago by teor

Replying to dgoulet:

I do think we have all this logic in place already *except* for the concept of both IPv4 or IPv6 but that is a know limitation for now and postponed to 033 (#23502).

Can you confirm it?
...
Again, you'll notice that the IPv6 problem in #23502 aren't addressed but apart from that, is the algorithm you describe followed?

No, it's broken in several places in 0.3.2.1-alpha (single onion service descriptor link specifiers, and fallback 3-hop connections for intro and rend). That's why the test doesn't work.

For fixes for 0.3.2 and a plan for 0.3.3, see https://trac.torproject.org/projects/tor/ticket/23493#comment:9

comment:6 Changed 2 years ago by dgoulet

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

Full dual stack single onion service should be in 033+ so I propose we make a proper spec of the algo once we have it working correctly so I'm postponing this to 033.

comment:7 Changed 20 months ago by dgoulet

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

Move 033 ticket I own to 034

comment:8 Changed 18 months ago by nickm

Keywords: 034-triage-20180328 added

comment:9 Changed 18 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:10 Changed 18 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:11 Changed 6 months ago by teor

Keywords: v3-onion-service-feature-parity added; doc tor-spec removed
Summary: Add single onion unreachable address algorithm to prop224Add single onion unreachable address algorithm to prop224 and implement it

comment:12 Changed 3 months ago by gaba

Owner: dgoulet deleted
Status: acceptedassigned

dgoulet will assign himself to the ones he is working on right now.

comment:13 Changed 2 months ago by teor

Points: 0.51
Summary: Add single onion unreachable address algorithm to prop224 and implement itHandle unreachable addresses on v3 single onion services by using a 3 hop path

comment:14 Changed 2 months ago by teor

Sponsor: Sponsor27-must

This is a must have sponsor 27 v3 onion service parity ticket.

comment:15 Changed 2 months ago by gaba

Cc: teor added
Keywords: network-team-roadmap-august added; 034-triage-20180328 034-removed-20180328 removed

comment:16 Changed 4 weeks ago by teor

Owner: set to teor

comment:17 Changed 4 weeks ago by teor

Milestone: Tor: unspecifiedTor: 0.4.2.x-final
Parent ID: #23493#23818
Resolution: fixed
Status: assignedclosed

I added the code for this fix to #23818.

comment:18 Changed 4 weeks ago by teor

Actual Points: 0.2
Note: See TracTickets for help on using tickets.