Man. I really am old now, aren't I? Darn it.
I'm glad you're still around and I appreciate that you're asking for
feedback!
I agree on the 1200 being in-bounds. Was thinking along the same lines
with IPv6 and precedent with other games and normal game traffic.
As you indicated, there's a potential issue here for low-bandwidth
connections when using a game browser. Even now, many consumer
connections have anemic upload speeds, such as 0.5 Mbps, despite more
reasonable download speeds. I'd have to run some tests to see what the
current peak outbound bandwidth usage is when loading a large set of
servers, then calculate how much it might increase under the new system.
You don't want to have to limit the number of servers requested at once
by too much, or force users to manually twiddle settings.
On 11/17/2020 9:59 AM, Fletcher Dunn 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/
<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/ <https://list.valvesoftware.com/>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/
