[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24404 [Core Tor/Tor]: Propose a relay protover that allows IPv6 extends
#24404: Propose a relay protover that allows IPv6 extends
---------------------------------------------+-----------------------------
Reporter: teor | Owner: (none)
Type: enhancement | Status: new
Priority: Medium | Milestone: Tor:
| 0.3.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: needs-proposal, ipv6, tor-relay | Actual Points:
Parent ID: #24403 | Points: 1
Reviewer: | Sponsor: SponsorV-
| can
---------------------------------------------+-----------------------------
Comment (by teor):
Replying to [comment:4 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 the TLS connection
2. Elicit a NETINFO cell by sending a relay with the right protover a
NETINFO cell, where this relay is the client side of the TLS connection
3. Open a connection to a relay to elicit a NETINFO cell
I think this is conceptually much simpler, uses the same mechanisms we
would use anyway, and minimises the number of changes required.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24404#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs