Nice the padding option for all the connectionless packets looks indeed interesting.
Will defeat the amplification abuse and will allow inspecting/filtering at network level without having to worry about the magic packets tracking, either pass or not pass :) On Tue, 17 Nov 2020 at 18:59, Fletcher Dunn - fletcherd at valvesoftware.com (via csgo_servers list) <csgo_servers@list.valvesoftware.com> wrote: > John! Good to hear from all old folks from years ago! > > > > TL/DR: New proposal: the server requires *all* 3 connectionless packets > from clients to be at least 1200 bytes. > > > > I’ve gotten similar feedback from a few people now. The only reason to > consider allowing a smaller packet with a challenge is to give the client a > way to reduce the bandwidth sent when pinging a ton of servers. But doing > this would impair the ability to filter out these packets further out, and > it is also more complicated to implement. (I wasn’t planning on changing > the server browser in steamclient.dll to do it, I was just going to do the > simple thing of padding the packet.) Given that it is 2020 The Year of Our > Lord Gaben, probably the extra bandwidth needed to ping a bunch of servers > is just not significant. > > > > Regarding 1200: although this technically maybe not OK according to RFCs > from the mid 90’s, being larger than the absurdly small minimum IPv4 MTU, I > believe it is OK in practice in 2020 TYOOLG, especially since the minimum > MTU for IPv6 is 1280. In the SDR protocol used by CSGO and Dota, clients > always initiate their communication with a 1200 byte packet, and that has > not caused any problems. > > > > To Kyle Sanderson’s point: I realize that this is not the most pressing > issue facing the Internet today. However, I am currently working on > integrating SDR functionality with the server browser, and so while I am > touching this code, it seemed like the right time to address this > longstanding issue. However, Valve is very sensitive to breaking old > games. It’s my understanding that this plan allows old games to continue > to operate, even if the code cannot be updated. If I’m mistaken, let me > know. > > > > *From:* John <lists.va...@nuclearfallout.net> > *Sent:* Tuesday, November 17, 2020 9:38 AM > *To:* csgo_servers@list.valvesoftware.com > *Cc:* Fletcher Dunn <fletch...@valvesoftware.com> > *Subject:* Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol > > > > Fletcher, > > This sounds like a reasonable idea. > > Of the two, requiring a large request (#1) might be best. Both #1 and #2 > help with reflection attacks, but #1 also helps to mitigate directly > spoofed query attacks on game servers. There is less overhead involved on > the server side with rejecting an improperly sized packet than in > generating a randomized challenge response and having to locally store that > state; and, should the spoofer generate *properly*-sized packets, they > would be limited to a lower overall packet rate (which also drastically > reduces overhead on the server side). Further, an external firewall could > easily drop improperly-formatted packets based on size, cutting out many > attacks. > > (By the same token, connection and all other unsolicited packets should > probably also be required to be large.) > > The only real downside would be that tools would need to be updated. I > don't see a blocker there. > > The specific size of the packets isn't too important as long as it beats > lowest-common-denominator MTUs. 800-1200 should be fine. > > One other consideration here is whether this can be coupled with changes > designed to mitigate the negatives of proxied responses (some hosts have > taken to advertising their prefixes from multiple PoPs and proxying query > responses in order to fake lower latencies, which degrades the player > experience). I can't immediately think of a good mechanism for that in the > query protocol itself; the primary way to deal with it would seem to be at > the global level, by penalizing servers whose latencies are measured to be > low from multiple locations in an impossible way. > > -John > > On 11/16/2020 5:21 PM, Fletcher Dunn - fletcherd at valvesoftware.com > (via csgo_servers list) wrote: > > Hello! > > > > Over the next couple of months we will be releasing some changes to how > servers and clients using steamclent.so/dll handle the venerable Source > engine A2S_INFO message used by the server browser. This includes the > Steam client server browser, all Source engine games, and all Steam games > using the ISteamMatchmaking API. The purpose of these changes is a long > overdue fix for a reflection attack vulnerability. > > > > This email is to let you know what those plans are and to solicit your > feedback. Fixing the vulnerability requires changing the protocol and will > necessarily break existing third party utilities that speak the protocol. > > > > Currently, the A2S_INFO packet looks like this: > > 4 bytes: 0xFFFFFFFF > > 1 byte: 0x54 (A2S_INFO packet type identifier) > > 20 bytes: "Source Engine Query\0" > > > > The proposal is for clients to modify the A2S_INFO packet they send in > one of two ways: > > > > Option 1: Pad the message with zeros, so that the request is larger than > the reply. The passes size is TBD, but it will probably be at least 800 > bytes, and perhaps as high as 1200. Feedback is requested concerning this > size. > > > > Option 2: Append a 4-byte anti-spoofing challenge obtained using the > existing A2S_PLAYER or A2S_RULES messages. > > > > Note that both options produce a packet that is acceptable to the current > code in steamclient.so/dll. However, any custom handlers might have > stricter behavior, and will need to be updated to be aware than “extra” > data might appear after the end of the magic string in packets from > legitimate clients. > > > > Once all clients are using one of these two options, a server wishing to > avoid being vulnerable to reflection attacks could drop any A2S_INFO > packets below a minimum size without a challenge. > > > > The changes would be deployed as follows: > > > > 1. First, we will release a new Steam client that sends A2S_INFO > messages padding to a minimum size. (Option #1 above.) Since it takes > time for Steam client updates to roll out to all Steam users, and for third > parties to change their code to make queries in the new format, we will not > change the server to require the new format by default. However, the > server code will be updated to look for an environment variable that can be > used to opt into the new, stricter behavior. This is so that third parties > can test their clients to make sure they are compliant with the new server > code. > > 2. As more clients upgrade to the new code and third party tools > are updated to send queries in the new format, server operators may elect > to opt into the new behavior at their discretion using the environment > variable. > > 3. After some time has passed (and we have posted several warnings > on this mailing list), we will ship a new steamclient.so/.dll that has > the strict behavior enabled by default. A different environment variable > can be used to use the older, more permissive behaviour. > > > > If you have any concerns or feedback about this change, please reply to > this steam post: > > https://steamcommunity.com/discussions/forum/14/2989789048633291344/ > > > > After feedback has been collected and details finalized, I’ll post again > with more technical details about the changes that are going to be made. > > _______________________________________________ > 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/
