Tyler, SNMP attacks are easily 1500x+ the reflection capability (yes, fifteen hundred times) from a single packet. NTP is a couple hundred but there were systemic fixes over half a decade ago. What is being proposed here is 100% a non-issue (SRCDS is again, 8x at best) for the entire internet, and is instead proposing breaking tens of orphaned games. I really don't know what yourself or Calvin are thinking but this is absolutely a non issue and is threatening the entire ecosystem over absolutely nothing. There's plenty of non-source games that use the same wire protocol (hell, even a call of duty game) - why are we changing it...
Why the hell are you guys thinking this is okay lol. I'm actually really confused now if you're not attempting to be arsonists. Kyle. On Mon, 16 Nov 2020, 22:56 Tyler Janse, <tylerrobinja...@gmail.com> wrote: > Hi all, > > I'd like to echo Calvin's opinion. I think Option 2 is in the right > direction. I don't have anything new technical-wise to contribute beyond > what's already been stated. > > I don't think anyone is worried about carriers or datacenters going down > over source engine reflection attacks, and I made no comment that would > imply that. > > My goal is to keep customer's services online throughout the attacks, > regardless of method or size. DNS/NTP/SNMP reflections are far less > resource intensive to mitigate compared to attacks that require hashlimits > or DPI, even if they are magnitudes larger on average. > > I'd like to accent this thought. We're talking about an issue that can > hit individual instances, not a whole datacenter. This is even more true > in a game played in short periods (45 minutes per game) compared to other > longer-played/persistent games. > > The fact that these options are proposed and community feedback is > solicited suggest that even internally they recognize this is an issue that > needs to be addressed. > > Cheers. > > Tyler > > > On Tue, Nov 17, 2020 at 12:27 AM Kyle Sanderson <kyle.l...@gmail.com> > wrote: > >> lol. Who are you. >> >> Best, >> Kyle. >> >> On Mon, 16 Nov 2020, 19:45 Calvin Judy - calvin at swiftnode.net (via >> csgo_servers list), <csgo_servers@list.valvesoftware.com> wrote: >> >>> So your argument is because there are reflection attacks with higher >>> amplification, Valve should, do nothing? >>> >>> I don't think anyone is worried about carriers or datacenters going down >>> over source engine reflection attacks, and I made no comment that would >>> imply that. >>> >>> My goal is to keep customer's services online throughout the attacks, >>> regardless of method or size. DNS/NTP/SNMP reflections are far less >>> resource intensive to mitigate compared to attacks that require hashlimits >>> or DPI, even if they are magnitudes larger on average. >>> >>> I'm not sure why anyone would condemn Valve for patching a well known >>> reflection vector. >>> >>> >>> What are you talking about 😂 >>> There's millions of other boxes. The genesis for all of this was SNMP >>> +- NTP, which came after and was 50x worse per academia. NTP, SNMP, >>> and CoD were the basic reflection staples of 2010. >>> >>> There's MTU hacks that break other queries which further destroy the >>> ecosystem regarding statistics. Breaking outside of the hacked STB >>> ecosystem (and oh my lord is there a lot) this is not really a hot >>> market anymore. There's boxes that can actually saturate the entire >>> link now that don't have to spoof. My single port server receiving on >>> 27015 killing an entire datacentre (which hit many other folks - to >>> the point of pings on IRC) from getting a simple reflection attack is >>> long gone. >>> >>> Basically, it's great that you've found the entire Valve + self-hosted >>> ecosystem at its peak. But this is a decade old issue that no longer >>> impacts real carriers, >>> Kyle. >>> >>> On Mon, Nov 16, 2020 at 6:43 PM Calvin Judy - calvin at swiftnode.net >>> (via csgo_servers list) <csgo_servers@list.valvesoftware.com> >>> <csgo_servers@list.valvesoftware.com> wrote: >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/ >>> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/ >> > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/ > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/
