#33375: Stop advertising an IPv6 exit policy when DNS is broken for IPv6 -------------------------------------------------+------------------------- Reporter: teor | Owner: neel Type: defect | Status: | needs_revision Priority: Medium | Milestone: Tor: | 0.4.4.x-final Component: Core Tor/Tor | Version: Tor: | 0.2.9.14 Severity: Normal | Resolution: Keywords: security-review-dos-risk, extra- | Actual Points: review, no-backport, ipv6, tor-exit, tor-dns | Parent ID: #24833 | Points: Reviewer: teor | Sponsor: -------------------------------------------------+------------------------- Changes (by teor):
* cc: nickm (added) * keywords: ipv6, tor-client, tor-exit, tor-dns, extra-review, no-backport => security-review-dos-risk, extra-review, no-backport, ipv6, tor-exit, tor-dns Comment: (Sorry for multiple comments, I kept thinking about this ticket today.) Can you describe the design of this new feature? The code doesn't match the rough design in the ticket description. That's ok, but without a design, I can't tell the difference between a bug and a feature. In particular, I wonder why we need separate "was_disabled" and "is_disabled" variables. This IPv6 DNS code is currently unused, so it has never been tested. So I want to make sure we have the design right. Here are some issues I noticed when reading the code: * the code only counts DNS errors on timeout, but there are actually 11 different DNS errors. We should consider which errors we want to track, and which ones we want to ignore. See http://www.wangafu.net/~nickm/libevent-2.1/doxygen/html/dns_8h.html * the minimum number of queries before failure is 10. But that could happen by chance, on server startup. Let's make the minimum something more reasonable. We can make it at least 1000. But maybe we should set it to 1 when TestingTorNetwork is set. That way, broken IPv6 exits will fail quickly in chutney. We should find out which DNS errors can be triggered by tor clients, and ignore them. Otherwise, a client that floods an exit with bad DNS queries could disable IPv6 exiting on that relay. I think Nick might be able to help here. I think it's ok to fail thousands of client circuits, before an IPv6 exit disables IPv6. Because getting the new descriptor to clients can take an hour or two. There's also a tradeoff here: we want quiet exits to disable IPv6 eventually. But we want busy exits to survive a momentary glitch. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33375#comment:5> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs