Opened 9 months ago

Last modified 5 months ago

#33241 assigned task

Prop 312: 3.2.5. Use Directory Header IPv6 Addresses

Reported by: teor Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop312, ipv6, 044-deferred
Cc: Actual Points:
Parent ID: #33049 Points: 4
Reviewer: Sponsor: Sponsor55-can

Description

This is a parent ticket.

If relays are unable to discover their IPv6 address in any other way, they should get their IPv6 address from the X-Your-Address-Is HTTP header in tor directory documents. To support this change, we propose that relays start fetching directory documents over IPv4 and IPv6.

We propose that bridges continue to only fetch directory documents over IPv4, because they try to imitate clients. Therefore, they can't use X-Your-Address-Is HTTP headers to find their IPv6 addresses.

See proposal 312, section 3.2.5:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n429

Child Tickets

TicketStatusOwnerSummaryComponent
#33242assignedProp 312: 3.2.5. Make Relays do IPv4 and IPv6 Directory FetchesCore Tor/Tor
#33243assignedProp 312: 3.2.5. Handle IPv6 Directory Fetch FailuresCore Tor/Tor
#33244assignedProp 312: 3.2.5. Use IPv6 Addresses from Directory ServersCore Tor/Tor
#33249assignedProp 312: 4. Update Directory Spec for IPv6 X-Your-Address-IsCore Tor/Tor

Change History (6)

comment:1 Changed 9 months ago by teor

Points: 4

comment:2 Changed 6 months ago by teor

Here is my opinion on this feature:

This feature is complicated. It requires relays to regularly do
directory fetches over IPv6. These directory connections should be
over an ORPort, so that the addresses are authenticated.

As an alternative, we can use IPv6 addresses from NETINFO cells. But
relays still need to make regular IPv6 ORPort connections:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n796

In both cases, the addresses should only come from outbound
connections. And we may only want to trust addresses from directory
authorities.

We can't make this change on bridges, because they have to imitate
clients. And clients don't try IPv4 and IPv6 connections yet. (See
proposal 306.)

This feature is also high-risk. If we make a mistake, we give network
adversaries the ability to set our IPv6 address. (But note that we
already accept this risk for IPv4.)

Overall, I think we should make this feature optional.
(And make all its children optional.)

Last edited 6 months ago by teor (previous) (diff)

comment:3 Changed 6 months ago by teor

Owner: teor deleted

Un-assign myself from future Sponsor 55 tasks.

comment:4 Changed 6 months ago by teor

Sponsor: Sponsor55-mustSponsor55-can

I've made all the IPv6 directory fetch tasks optional, because they could take a lot of work, and they are high-risk.

When we finish the required tasks, we can prioritise the optional tasks.

comment:5 Changed 5 months ago by nickm

Keywords: 044-deferred added
Milestone: Tor: 0.4.4.x-finalTor: unspecified

Bulk-remove tickets from 0.4.4. Add the 044-deferred label to them.

comment:6 Changed 5 months ago by nickm

Milestone: Tor: unspecified

Bulk-move prop311 and prop312 to 0.4.5

Note: See TracTickets for help on using tickets.