Opened 3 months ago

Last modified 3 weeks ago

#24181 accepted defect

Put IPv6 and unrecognised link specifiers in onion service EXTEND cells

Reported by: teor Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.3.4.x-final
Component: Core Tor/Tor Version: Tor: 0.3.2.1-alpha
Severity: Normal Keywords: prop224, tor-hs, single-onion, ipv6, tor-spec
Cc: Actual Points:
Parent ID: #23493 Points: 3
Reviewer: Sponsor:

Description

Prop224 says:

The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.

https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1689

We should either remove this from the spec, or we should:

  • add a similar sentence for client descriptor lspecs
  • put unrecognised lspecs in descriptors in client intro EXTEND requests
  • put unrecognised lspecs in INTRODUCE cells in service rend EXTEND requests

Child Tickets

Change History (5)

comment:1 Changed 3 months ago by teor

We should also put IPv6 addresses in EXTEND cell link specifiers, even if current relays won't use them.

comment:2 Changed 3 months ago by teor

Do we need to do this for CREATE cells as well?
I don't think so, because we're the ones connecting.

comment:3 Changed 3 months ago by teor

Summary: Put unrecognised link specifiers in onion service EXTEND cellsPut IPv6 and unrecognised link specifiers in onion service EXTEND cells

This needs to be done in the same release as #24451, to avoid introducing a v3 onion service distinguisher.

comment:4 Changed 2 months ago by dgoulet

Owner: set to dgoulet
Status: newaccepted

comment:5 Changed 3 weeks ago by dgoulet

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

Move 033 ticket I own to 034

Note: See TracTickets for help on using tickets.