<div dir="ltr">Thank you Cecylia.  I think this is a good plan.  I like the idea of <a href="http://stun.stunprotocol.org">stun.stunprotocol.org</a> being "in the rotation" for these nodes.  Just not the "exclusive default" unless a user manually configures it that way.  Does that work for you?<div><br></div><div>That being said, I don't have hard evidence that Snowflake is causing load issues or excessive DNS queries.  There's no headers or attributes in these STUN requests that indicate the originating app. A few million STUN requests per day from a service isn't much bother. A few hundred million hits per day gets noticed.  </div><div><br></div><div>As for the DNS queries, it was only a sample of a few IP addresses in the Route 53 logs that led me to this group.  <a href="http://stun.stunprotocol.org">stun.stunprotocol.org</a> has continuously been hit with DDOS attacks over the years. It wouldn't surprise me if these same attackers are going after the DNS service as well.</div><div><br></div><div>I ran the Snowflake extension from the browser and the proxy code from the command line while simultaneously running Wireshark to monitor traffic. I didn't see anything unusual with regards to STUN. I'll double check DNS, but I thought I evaluated that too last night.</div><div><br></div><div>It's nice to meet everyone. I'll respond to David's messages next.</div><div><br></div><div>Thanks,</div><div>jrs</div></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 26, 2022 at 10:43 AM Cecylia Bocovich <<a href="mailto:cohosh@torproject.org" target="_blank">cohosh@torproject.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/26/22 00:55, John Selbie wrote:<br>
> Greetings,<br>
><br>
> I hope this is an appropriate mailing list to discuss a technical <br>
> issue with Tor's Snowflake project.  Please redirect me to the right <br>
> place if not.<br>
><br>
> I am the original author and maintainer of the open source project, <br>
> Stuntman.  Stuntman is an implementation of the STUN protocol, which <br>
> includes the STUN server. More details at <a href="http://www.stunprotocol.org" rel="noreferrer" target="_blank">www.stunprotocol.org</a> <br>
> <<a href="http://www.stunprotocol.org" rel="noreferrer" target="_blank">http://www.stunprotocol.org</a>>.  In short, a STUN server helps <br>
> bootstream direct "p2p" connections such as WebRTC sessions or similar <br>
> VOIP scenarios by allowing internet devices to self-discover their own <br>
> public IP address and obtain a (UDP) port for communicating with <br>
> another node.<br>
><br>
> I also run a public instance of a STUN server with the code at <br>
> <a href="http://stun.stunprotocol.org" rel="noreferrer" target="_blank">stun.stunprotocol.org</a> <<a href="http://stun.stunprotocol.org" rel="noreferrer" target="_blank">http://stun.stunprotocol.org</a>>.  It's been up <br>
> and running for about 10 years now. It's hosted on AWS.  In recent <br>
> years, the hosting bills for this server have started to get on the <br>
> high side, even with reserved instances.  The number of STUN queries <br>
> it processes per day is now on the order of hundreds of millions. The <br>
> <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> <<a href="http://stunprotocol.org" rel="noreferrer" target="_blank">http://stunprotocol.org</a>> domain receives nearly a <br>
> million DNS queries on Route 53 daily. What used to cost a trivial <br>
> number of dollars to run is now starting to reach $1000 in annual <br>
> service costs. This isn't paid for by a corporation or well funded <br>
> internet organization. I pay this out of my personal pocket.<br>
><br>
> It's been a mystery what has been driving the increasing traffic to <br>
> the server - especially redundant requests from the same IPs.  I was <br>
> inspecting the DNS logs the other day and started to investigate the <br>
> nodes sending out redundant DNS requests repetitively.  Trying to <br>
> understand why these nodes wouldn't leverage DNS caching.  And to my <br>
> surprise, one of the IPs was running a web server that presented a TOR <br>
> landing page.  That led me to discover this discussion online:<br>
><br>
> <a href="https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30579" rel="noreferrer" target="_blank">https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30579</a><br>
><br>
> And a quick inspection of the Snowflake code leads me to find that <br>
> <a href="http://stun.stunprotocol.org" rel="noreferrer" target="_blank">stun.stunprotocol.org</a> <<a href="http://stun.stunprotocol.org" rel="noreferrer" target="_blank">http://stun.stunprotocol.org</a>> is the default <br>
> STUN server for Snowflake proxy and listed throughout the <br>
> documentation as well.<br>
><br>
> While the Snowflake project has good intentions, it doesn't appear to <br>
> take my hosting costs into consideration. I'm hoping we can have a <br>
> good discussion on the following:<br>
><br>
> 1) How many snowflake clients and proxies are active and how many STUN <br>
> requests are each generating towards <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> <br>
> <<a href="http://stunprotocol.org" rel="noreferrer" target="_blank">http://stunprotocol.org</a>>? Do we think the entire worldwide usage of <br>
> Snowflake could be responsible for millions of STUN queries to <br>
> <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> <<a href="http://stunprotocol.org" rel="noreferrer" target="_blank">http://stunprotocol.org</a>> per day?<br>
><br>
> 2) Expected number of DNS queries (it's a 3-day TTL on these DNS <br>
> entries, so it blows my mind that there are so many redundant <br>
> requests). Does Pion or any other part of the Snowflake code tend to <br>
> go direct to the namespace server itself?<br>
><br>
> 3) Removing <a href="http://stun.stunprotocol.org" rel="noreferrer" target="_blank">stun.stunprotocol.org</a> <<a href="http://stun.stunprotocol.org" rel="noreferrer" target="_blank">http://stun.stunprotocol.org</a>> as <br>
> the default STUN server.<br>
><br>
> OR...<br>
><br>
> 4) Alternatively, I'm always open to accepting donations to help run <br>
> the service costs of <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> <<a href="http://stunprotocol.org" rel="noreferrer" target="_blank">http://stunprotocol.org</a>>. I'm <br>
> definitely not getting rich running this thing.<br>
><br>
> Thanks,<br>
> John Selbie<br>
<br>
<br>
Hi John,<br>
<br>
Thank you for reaching out. This is exactly the right place to discuss <br>
this. This was an oversight on my part not to reach out to you as the <br>
operator of our configured default STUN server and I'm very sorry for <br>
the unexpected increased costs. We can absolutely remove <br>
<a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> as the default.<br>
<br>
First, to answer some of your questions:<br>
<br>
1) I would definitely believe the amount of snowflake traffic to <br>
<a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> to be this high. We have over 100,000 proxies. <br>
According to recent metrics[0], there are around 8 million matches a day <br>
and therefore that many WebRTC ICE gathering requests coming from just <br>
the proxies. The clients use a randomized subset of configured STUN <br>
servers, so the number is slightly different but it's safe to say they <br>
are also generating a few million STUN queries to your server.<br>
<br>
2) I'm not sure about the DNS queries. It also surprises me that there <br>
are this many, I'll open an issue to investigate why.<br>
<br>
Now for immediate next steps. I've sent an email to people internally to <br>
start the process of looking into sending some funds your way for the <br>
costs. We might not get an answer until after everyone is back at work <br>
in January. In the meantime:<br>
<br>
- I'd like to remove <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> as the default STUN server for the <br>
proxies. The reason we added to our list in the first place was because <br>
it implements RFC 5780 which we are using on the client side to <br>
determine NAT matching and filtering types (thank you for this <br>
implementation BTW!). The proxies no longer use this however, so there's <br>
no reason we can't have them use any number of other public STUN servers.<br>
<br>
- We can remove <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> from the list of *default* client STUN <br>
servers and reserve it for a small subset of users instead. This would <br>
really cut down on the traffic, but keep it open as an option for <br>
clients in places that have blocked other industry STUN servers.<br>
<br>
How does this sound to you?<br>
<br>
Thanks again for all the work you've done on Stuntman and in running a <br>
public server. I'm glad you reached about this.<br>
<br>
- Cecylia<br>
<br>
[0] <a href="https://snowflake-broker.bamsoftware.com/metrics" rel="noreferrer" target="_blank">https://snowflake-broker.bamsoftware.com/metrics</a><br>
<br>
_______________________________________________<br>
anti-censorship-team mailing list<br>
<a href="mailto:anti-censorship-team@lists.torproject.org" target="_blank">anti-censorship-team@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team</a><br>
</blockquote></div>