The GMS does indeed have all of this information. Let me investigate moving more data to be in the GMS reply, instead of being returned in A2S_INFO.
I think some ping will always be necessary to measure the latency and confirm UDP connectivity and that the server is running. But there are probably some simple changes that can be made to reduce the size of these replies significantly and move them to the GMS. -----Original Message----- From: Kyle Sanderson <kyle.l...@gmail.com> Sent: Tuesday, November 17, 2020 11: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 > 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. Ahha! If we're already in there making other changes - I'd like to propose something else then. 1. Lets promote the GMS (if this still exists) to have all server information (players, rules, etc). 2. Have steamclient default to leaving old queries enabled, but the games themselves with a convar to disable old queries by default. 3. This way technically the client doesn't have to ping the server (I mean - it should still A2A_PING at some point), and tiny GSPs won't have to deal with conntrack as much. I think this is what was done with the old master > GMS flip(?) - same idea here. There can be a huge win because the GMS can immediately return all these results to the client (or pages - whatever), without destroying the conntrack table on bad home appliances. Simple stream, challenge, response with the full rendered list. "Steam Desktop Client" can still do the full query in the favourites list, but do a GMS query first for results and if it's missing try hitting it directly. WDYT? Kyle. On Tue, Nov 17, 2020 at 10:00 AM 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/
