<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"><div>Hi David,</div><div><br></div></div><div dir="ltr"><blockquote type="cite">On 26 Mar 2020, at 05:01, David Fifield <david@bamsoftware.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>On Wed, Mar 25, 2020 at 09:42:48AM +0100, Karsten Loesing wrote:</span><blockquote type="cite"><blockquote type="cite"><span>3. Roger found a case where traffic tagged with a 0.0.0.0/8 address was</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> being ignored by some part of tor's internal bandwidth accounting</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> (https://bugs.torproject.org/33693). Until recently, the Snowflake</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> bridge had a bug where, for certain clients, it reported a client</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> address of 0.0.0.0 to the tor bridge's ExtORPort (https://bugs.torproject.org/33157).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> The bug is only partially fixed--we now report no address at all for</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> the affected clients. The fix was not deployed until 2020-02-22, so</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> it doesn't explain the divergence of read/written on its own. Do you</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> know offhand whether an apparent client address of 0.0.0.0, or no</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> address at all, would cause problems with measuring usage?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I'm afraid I don't know. I wonder if teor knows more about this, as he</span><br></blockquote><blockquote type="cite"><span>spent some time on bandwidth statistics for IPv6 traffic statistics</span><br></blockquote><blockquote type="cite"><span>recently.</span><br></blockquote><span></span><br><span>Doing a quick test just now, in the absence of an Extended OR Port</span><br><span>USERADDR command, the tor bridge will default to the remote IP address</span><br><span>of the socket, which is 127.0.0.1:XXXX because it's coming from the</span><br><span>pluggable transport server on the same host. As far as I can tell,</span><br><span>127.0.0.1 is ignored for bandwidth accounting just as 0.0.0.0 is.</span><br><span></span><br><span>Obviously the correct solution in this case is to fix #33157 and have</span><br><span>the Snowflake proxies report the correct client IP address in 100% of</span><br><span>cases. But it makes me think that it would be nice to have a token or</span><br><span>designated address that means, I don't know what the client IP address</span><br><span>is, but please count its bytes anyway. In meek we can rely on the CDN</span><br><span>setting an X-Forwarded-For header, and in Snowflake we have the proxy</span><br><span>attempt to extract the remote IP address of the peer-to-peer connection</span><br><span>and attach it to the WebSocket request as a URL parameter. But I'm</span><br><span>thinking about a DNS-based transport and there's no way to cause a</span><br><span>recursive DNS resolver to forward the client's IP address to the</span><br><span>authoritative resolver. (There is RFC 7871, but some DNS servers do not</span><br><span>support it by design, and it's only a prefix anyway.) It would be nice</span><br><span>to have clients counted even if they cannot be geolocated.</span><br></div></blockquote><div><br></div>I looked at this code in tor a few weeks ago, as part of the relay<div>IPv6 statistics work.</div><div><br></div><div>Internal addresses aren't counted for statistics (or accounting).</div><div><br></div><div>It wasn't very well documented, so I improved the comments:</div><div><a href="https://github.com/torproject/tor/commit/98899f20ad22e97c03235cfe13ff1fe416a15509#diff-13f67a11cfe3a7a0ff3aa39f2b87a2dc">https://github.com/torproject/tor/commit/98899f20ad22e97c03235cfe13ff1fe416a15509#diff-13f67a11cfe3a7a0ff3aa39f2b87a2dc</a></div><div><br></div><div>Here's the list of Tor's current internal addresses:</div><div><a href="https://github.com/torproject/tor/blob/686494f0f71b9235399b8241aba3e0c2fcb03ea1/src/lib/net/address.c#L241">https://github.com/torproject/tor/blob/686494f0f71b9235399b8241aba3e0c2fcb03ea1/src/lib/net/address.c#L241</a></div><div><br></div><div>As a workaround, you can set:</div><div>CountPrivateBandwidth 1</div><div>in the bridge torrc.</div><div><br></div><div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">If you wanted a token, you could draw it from a documentation address</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">block:</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><a href="https://tools.ietf.org/html/rfc5737#section-3">https://tools.ietf.org/html/rfc5737#section-3</a></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">These addresses shouldn't appear on local networks or the internet.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">(But tor doesn't ignore them yet, because it doesn't have any concept</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">of "unacceptable for use anywhere".)</div></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">But let's check with a Nick and others before we do that. Otherwise,</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">you might find those addresses get ignored in future.</div><div><br></div><div>T<br><div><br></div></div></div></body></html>