Propose a relay protover that allows IPv6 extends

Write a proposal for a relay protover, in which relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)

changed milestone to %Tor: 0.4.4.x-final

added 034-removed-20180328 034-triage-20180328 actualpoints::3.5 component::core tor/tor ipv6 milestone::Tor: 0.4.4.x-final needs-proposal parent::24403 points::1 priority::medium resolution::fixed severity::normal status::closed tor-relay type::enhancement labels

Trac:
Parent: N/A to #24403 (moved)

We also need to decide what relays should do when:

• An EXTEND request is received with an IPv4 and an IPv6 address (relays should only use IPv6 in step 2), and
• The relay receiving the extend request supports the new protover:
  • Always use IPv4? (then we'll need another protover for client IPv6 extends)
  • Choose between IPv4 and IPv6 at random?
  • Attempt to switch between IPv4 and IPv6?
  • Do something even better?

We also need to decide which fallback to use if we don't confirm ourselves reachable within 20 minutes (this can happen because relays will use existing canonical connections rather than making a new one):

• use an IPv6 exit to connect to our ORPort (this doesn't authenticate that the remote port actually belongs to us)
• use a magic value for the identity (all zeroes?) when connecting to our ORPort, to force a new connection (DoS risk, doesn't authenticate, but does check addresses in the NETINFO cell)
• put flags in the extend cell that say "must IPv6"? (also a DoS risk)
• close an old/unused connection, and then extend a preemptive circuit to ourselves over IPv6
• some smarter mechanism?

Edit: note another DoS risk

Extend the notion of canonical to have a canonical v4 and a canonical v6 connection. Only in the event of a reachability check with a "must v4" or "must v6" flag create a new connection of the other connection type. Treat this second connection as canonical for the purpose of deciding whether to close it etc, but not for actual traffic. Does that alleviate the DoS risk you're worried about? If not, why not?

Replying to Sebastian:

Extend the notion of canonical to have a canonical v4 and a canonical v6 connection. Only in the event of a reachability check with a "must v4" or "must v6" flag create a new connection of the other connection type. Treat this second connection as canonical for the purpose of deciding whether to close it etc, but not for actual traffic. Does that alleviate the DoS risk you're worried about? If not, why not?

It mitigate it, but does not eliminate it, because it still doubles the number of open connections per relay (in a worst-case scenario where all relays have IPv6). However, a scheme like this would also substantially reduce the need for a fallback mechanism for reachability checking. To eliminate it, we could make a must-flagged EXTEND cell trigger a NETINFO cell along an existing connection.

Here's a much nicer alternative fallback that avoids adding must flags:

• relays with the latest protover respond to NETINFO cells on existing connections by sending a NETINFO cell, at most every N minutes per connection (N < 20 minutes, the current reachability warning threshold)

Then the fallback becomes:

• if there are no relays with the right protover or all relays with the right protover have an existing connection to this relay, try these steps in order
  1. Elicit a NETINFO cell by sending a relay with the right protover a NETINFO cell, where this relay is the server side of an existing TLS connection over the desired IP version
  2. Elicit a NETINFO cell by sending a relay with the right protover a NETINFO cell, where this relay is the client side of an existing TLS connection over the desired IP version
  3. Open a connection to a relay to elicit a NETINFO cell over the desired IP version

I think this is conceptually much simpler, uses the same mechanisms we would use anyway, and minimises the number of changes required.

Replying to teor:

relays with the latest protover respond to NETINFO cells on existing connections by sending a NETINFO cell, at most every N minutes per connection (N < 20 minutes, the current reachability warning threshold)

Then the fallback becomes:

• if there are no relays with the right protover or all relays with the right protover have an existing connection to this relay, try these steps in order
  1. Elicit a NETINFO cell by sending a relay with the right protover a NETINFO cell, where this relay is the server side of an existing TLS connection over the desired IP version

These won't work, they don't get a NETINFO for the ORPort address:

2. Elicit a NETINFO cell by sending a relay with the right protover a NETINFO cell, where this relay is the client side of an existing TLS connection over the desired IP version
3. Open a connection to a relay to elicit a NETINFO cell over the desired IP version

Instead, we should: 2. expire 10% of our oldest connections, and optionally 10% of our least-used connections (don't do this on authorities) 3. Retry step 1 4. If we keep on failing, we are not getting any inbound connections, so we're an anomaly: a busy relay that can only make outbound connections. (This situation fixes itself: if we give up and drop out of the consensus, we're no longer a busy relay, and our reachability checks should work.)

There will need to be limits so that we publish immediately if a minimum number of relays supporting the protover aren't in the consensus. And we should make sure we expire a minimum number of connections.

We probably want to use the stored information from the original NETINFO cell on each connection, rather than eliciting another one with the same content (and adding complicated code to make sure we don't send too many).

Should we ignore any NETINFOs sent before the most recent config change? Probably.

The 0.3.3 freeze deadline has passed, all these children of #24403 (moved) belong in 0.3.4

Trac:
Milestone: Tor: 0.3.3.x-final to Tor: 0.3.4.x-final

Trac:
Keywords: N/A deleted, 034-triage-20180328 added

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

Trac:
Keywords: N/A deleted, 034-removed-20180328 added

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

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: unspecified

Trac:
Cc: N/A to cypherpunks

Removing sponsor V as we do not have more time to include this tickets in the sponsor.

Removing sponsor from tickets that we do not have time to fit in the remain of this sponsorship.

Trac:
Sponsor: SponsorV-can to N/A

I created an initial draft of this proposal at:

• torspec: https://github.com/torproject/torspec/pull/103

I'll also send an email to the tor-dev list.

Trac:
Status: new to needs_review
Actualpoints: N/A to 3
Milestone: Tor: unspecified to Tor: 0.4.4.x-final

Comments by nickm on tor-dev@. Moving this to needs_info until that part is resolved or not so we can then proceed to upstream merge and make prop311 official.

Trac:
Status: needs_review to needs_information

FWIW it is okay IMO to merge a proposal as sent to tor-dev, and then to update it as we edit that proposal. Let's go with whatever Teor prefers there.

I've merged this proposal, and I think it's pretty much in its final state.

Trac:
Actualpoints: 3 to 3.5
Status: needs_information to closed
Resolution: N/A to fixed

closed

changed time estimate to 8h

added 28h of time spent

mentioned in issue #24405 (moved)

mentioned in issue #24406 (moved)

mentioned in issue #24767 (moved)

mentioned in issue #24841 (moved)

mentioned in issue #29570 (moved)

mentioned in issue #33043 (moved)

moved to tpo/core/tor#24404 (closed)

mentioned in issue tpo/core/tor#24405 (closed)

mentioned in issue tpo/core/tor#24406 (closed)