Opened 18 months ago

Last modified 7 weeks ago

#24404 new enhancement

Propose a relay protover that allows IPv6 extends

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, ipv6, tor-relay, 034-triage-20180328, 034-removed-20180328
Cc: cypherpunks Actual Points:
Parent ID: #24403 Points: 1
Reviewer: Sponsor: SponsorV-can

Description

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.)

Child Tickets

Change History (13)

comment:1 Changed 18 months ago by teor

Parent ID: #24403

comment:2 Changed 18 months ago by teor

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?

comment:3 Changed 18 months ago by teor

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

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

comment:4 Changed 18 months ago by 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?

comment:5 in reply to:  4 ; Changed 18 months ago by teor

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.

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

comment:6 in reply to:  5 Changed 18 months ago by teor

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:

  1. 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
  2. Open a connection to a relay to elicit a NETINFO cell over the desired IP version

Instead, we should:

  1. expire 10% of our oldest connections, and optionally 10% of our least-used connections (don't do this on authorities)
  2. Retry step 1
  3. 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.

comment:7 Changed 18 months ago by teor

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).

comment:8 Changed 18 months ago by teor

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

comment:9 Changed 16 months ago by teor

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

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

comment:10 Changed 14 months ago by nickm

Keywords: 034-triage-20180328 added

comment:11 Changed 14 months ago by nickm

Keywords: 034-removed-20180328 added

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

comment:12 Changed 14 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:13 Changed 7 weeks ago by cypherpunks

Cc: cypherpunks added
Note: See TracTickets for help on using tickets.