Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[David Parker]

Ah yes, I see it now.  Thank you Marco for that breakdown.

On Wed, Nov 18, 2020 at 3:00 AM Marco Padovan  wrote:

> What is being tackled here is the amplification factor
>
>
> https://github.com/Phenomite/AMP-Research/tree/master/Port%2027015%20(%2B%20more%20ports)%20-%20SRCDS%20(Arma3%2C%20Gmod%2C%20CSGO%2C%20etc)
>
> that means an attacker with a 100mbps connection at hand that allows
> spoofing could use srcds servers to achieve a 500mbps reflected attack
> towards a target
>
> big packets means the same attacker with a 100mbps connection would end up
> being able to only attack the target with potentially even less mbps then
> what he already had access to
>
> On Wed, 18 Nov 2020 at 04:23, David Parker  wrote:
>
>> Moving the server side of the query handling to the GMS would solve all
>> of the issues for GSPs and others hosting the games.  That makes perfect
>> sense to me.
>>
>> However, regarding the increased packet size (option #1), I'm a little
>> confused.  If the idea here is that the servers expect really big packets
>> and reject anything too small, couldn't the asshats who launch these
>> attacks just update their existing code to pad the requests with zeros, and
>> we're back to the same problem?  There's probably a piece to this that I'm
>> missing, and I apologize for my ignorance.
>>
>> Thanks!
>> Dave
>>
>> On Tue, Nov 17, 2020 at 4:53 PM Fletcher Dunn - fletcherd at
>> valvesoftware.com (via csgo_servers list) <
>> csgo_servers@list.valvesoftware.com> wrote:
>>
>>> >It depends now on what you're doing with SDR ;-).
>>>
>>> Yes, there are mechanisms to measure the latency to servers in known
>>> data centers, as well as to arbitrary hosts on the Internet using SDR P2P
>>> functionality.  I was referring to the ordinary servers.
>>>
>>> -Original Message-
>>> From: Kyle Sanderson 
>>> Sent: Tuesday, November 17, 2020 1:15 PM
>>> To: Fletcher Dunn 
>>> Cc: csgo_servers@list.valvesoftware.com
>>> Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol
>>>
>>> > I think some ping will always be necessary to measure the latency and
>>> > confirm UDP connectivity
>>>
>>> It depends now on what you're doing with SDR ;-).
>>>
>>> If you're planning on opening this up for optimized PoPs you already
>>> have the latency from the client, and the latency from the PoP to the
>>> server so you can return the sum there. One of the no-steam guys did this
>>> in like 2003 with his browser but he didn't control the PoPs. The latency
>>> was still off because he did addition of the requesting client
>>> + his master latency to the server then divided by two - with SDR you
>>> control the network (and the paths).
>>>
>>> > that the server is running
>>>
>>> Tweaking steamclient to be more happy with sharing alive updates (30s
>>> heartbeats) with the GMS would probably do the trick for stale
>>> information. It's not like it needs to be super up to date (although it
>>> could impact the "wait for a server slot" feature).
>>>
>>> Just a thought, anyway.
>>>
>>> Kyle.
>>>
>>> On Tue, Nov 17, 2020 at 12:23 PM Fletcher Dunn <
>>> fletch...@valvesoftware.com> wrote:
>>> >
>>> > 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 
>>> > Sent: Tuesday, November 17, 2020 11:38 AM
>>> > To: csgo_servers@list.valvesoftware.com
>>> > Cc: Fletcher Dunn 
>>> > 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 

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Marco Padovan]

What is being tackled here is the amplification factor

https://github.com/Phenomite/AMP-Research/tree/master/Port%2027015%20(%2B%20more%20ports)%20-%20SRCDS%20(Arma3%2C%20Gmod%2C%20CSGO%2C%20etc)

that means an attacker with a 100mbps connection at hand that allows
spoofing could use srcds servers to achieve a 500mbps reflected attack
towards a target

big packets means the same attacker with a 100mbps connection would end up
being able to only attack the target with potentially even less mbps then
what he already had access to

On Wed, 18 Nov 2020 at 04:23, David Parker  wrote:

> Moving the server side of the query handling to the GMS would solve all of
> the issues for GSPs and others hosting the games.  That makes perfect sense
> to me.
>
> However, regarding the increased packet size (option #1), I'm a little
> confused.  If the idea here is that the servers expect really big packets
> and reject anything too small, couldn't the asshats who launch these
> attacks just update their existing code to pad the requests with zeros, and
> we're back to the same problem?  There's probably a piece to this that I'm
> missing, and I apologize for my ignorance.
>
> Thanks!
> Dave
>
> On Tue, Nov 17, 2020 at 4:53 PM Fletcher Dunn - fletcherd at
> valvesoftware.com (via csgo_servers list) <
> csgo_servers@list.valvesoftware.com> wrote:
>
>> >It depends now on what you're doing with SDR ;-).
>>
>> Yes, there are mechanisms to measure the latency to servers in known data
>> centers, as well as to arbitrary hosts on the Internet using SDR P2P
>> functionality.  I was referring to the ordinary servers.
>>
>> -Original Message-
>> From: Kyle Sanderson 
>> Sent: Tuesday, November 17, 2020 1:15 PM
>> To: Fletcher Dunn 
>> Cc: csgo_servers@list.valvesoftware.com
>> Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol
>>
>> > I think some ping will always be necessary to measure the latency and
>> > confirm UDP connectivity
>>
>> It depends now on what you're doing with SDR ;-).
>>
>> If you're planning on opening this up for optimized PoPs you already have
>> the latency from the client, and the latency from the PoP to the server so
>> you can return the sum there. One of the no-steam guys did this in like
>> 2003 with his browser but he didn't control the PoPs. The latency was still
>> off because he did addition of the requesting client
>> + his master latency to the server then divided by two - with SDR you
>> control the network (and the paths).
>>
>> > that the server is running
>>
>> Tweaking steamclient to be more happy with sharing alive updates (30s
>> heartbeats) with the GMS would probably do the trick for stale
>> information. It's not like it needs to be super up to date (although it
>> could impact the "wait for a server slot" feature).
>>
>> Just a thought, anyway.
>>
>> Kyle.
>>
>> On Tue, Nov 17, 2020 at 12:23 PM Fletcher Dunn <
>> fletch...@valvesoftware.com> wrote:
>> >
>> > 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 
>> > Sent: Tuesday, November 17, 2020 11:38 AM
>> > To: csgo_servers@list.valvesoftware.com
>> > Cc: Fletcher Dunn 
>> > 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 

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[David Parker]

Moving the server side of the query handling to the GMS would solve all of
the issues for GSPs and others hosting the games.  That makes perfect sense
to me.

However, regarding the increased packet size (option #1), I'm a little
confused.  If the idea here is that the servers expect really big packets
and reject anything too small, couldn't the asshats who launch these
attacks just update their existing code to pad the requests with zeros, and
we're back to the same problem?  There's probably a piece to this that I'm
missing, and I apologize for my ignorance.

Thanks!
Dave

On Tue, Nov 17, 2020 at 4:53 PM Fletcher Dunn - fletcherd at
valvesoftware.com (via csgo_servers list) <
csgo_servers@list.valvesoftware.com> wrote:

> >It depends now on what you're doing with SDR ;-).
>
> Yes, there are mechanisms to measure the latency to servers in known data
> centers, as well as to arbitrary hosts on the Internet using SDR P2P
> functionality.  I was referring to the ordinary servers.
>
> -Original Message-
> From: Kyle Sanderson 
> Sent: Tuesday, November 17, 2020 1:15 PM
> To: Fletcher Dunn 
> Cc: csgo_servers@list.valvesoftware.com
> Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol
>
> > I think some ping will always be necessary to measure the latency and
> > confirm UDP connectivity
>
> It depends now on what you're doing with SDR ;-).
>
> If you're planning on opening this up for optimized PoPs you already have
> the latency from the client, and the latency from the PoP to the server so
> you can return the sum there. One of the no-steam guys did this in like
> 2003 with his browser but he didn't control the PoPs. The latency was still
> off because he did addition of the requesting client
> + his master latency to the server then divided by two - with SDR you
> control the network (and the paths).
>
> > that the server is running
>
> Tweaking steamclient to be more happy with sharing alive updates (30s
> heartbeats) with the GMS would probably do the trick for stale
> information. It's not like it needs to be super up to date (although it
> could impact the "wait for a server slot" feature).
>
> Just a thought, anyway.
>
> Kyle.
>
> On Tue, Nov 17, 2020 at 12:23 PM Fletcher Dunn <
> fletch...@valvesoftware.com> wrote:
> >
> > 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 
> > Sent: Tuesday, November 17, 2020 11:38 AM
> > To: csgo_servers@list.valvesoftware.com
> > Cc: Fletcher Dunn 
> > 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: t

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

>It depends now on what you're doing with SDR ;-).

Yes, there are mechanisms to measure the latency to servers in known data 
centers, as well as to arbitrary hosts on the Internet using SDR P2P 
functionality.  I was referring to the ordinary servers.

-Original Message-
From: Kyle Sanderson  
Sent: Tuesday, November 17, 2020 1:15 PM
To: Fletcher Dunn 
Cc: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

> I think some ping will always be necessary to measure the latency and 
> confirm UDP connectivity

It depends now on what you're doing with SDR ;-).

If you're planning on opening this up for optimized PoPs you already have the 
latency from the client, and the latency from the PoP to the server so you can 
return the sum there. One of the no-steam guys did this in like 2003 with his 
browser but he didn't control the PoPs. The latency was still off because he 
did addition of the requesting client
+ his master latency to the server then divided by two - with SDR you
control the network (and the paths).

> that the server is running

Tweaking steamclient to be more happy with sharing alive updates (30s
heartbeats) with the GMS would probably do the trick for stale information. 
It's not like it needs to be super up to date (although it could impact the 
"wait for a server slot" feature).

Just a thought, anyway.

Kyle.

On Tue, Nov 17, 2020 at 12:23 PM Fletcher Dunn  
wrote:
>
> 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 
> Sent: Tuesday, November 17, 2020 11:38 AM
> To: csgo_servers@list.valvesoftware.com
> Cc: Fletcher Dunn 
> 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) 
>  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 
> &g

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Kyle Sanderson]

> I think some ping will always be necessary to measure the latency and confirm 
> UDP connectivity

It depends now on what you're doing with SDR ;-).

If you're planning on opening this up for optimized PoPs you already
have the latency from the client, and the latency from the PoP to the
server so you can return the sum there. One of the no-steam guys did
this in like 2003 with his browser but he didn't control the PoPs. The
latency was still off because he did addition of the requesting client
+ his master latency to the server then divided by two - with SDR you
control the network (and the paths).

> that the server is running

Tweaking steamclient to be more happy with sharing alive updates (30s
heartbeats) with the GMS would probably do the trick for stale
information. It's not like it needs to be super up to date (although
it could impact the "wait for a server slot" feature).

Just a thought, anyway.

Kyle.

On Tue, Nov 17, 2020 at 12:23 PM Fletcher Dunn
 wrote:
>
> 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 
> Sent: Tuesday, November 17, 2020 11:38 AM
> To: csgo_servers@list.valvesoftware.com
> Cc: Fletcher Dunn 
> 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) 
>  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 

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

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  
Sent: Tuesday, November 17, 2020 11:38 AM
To: csgo_servers@list.valvesoftware.com
Cc: Fletcher Dunn 
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)  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 
> Sent: Tuesday, November 17, 2020 9:38 AM
> To: csgo_servers@list.valvesoftware.com
> Cc: Fletcher Dunn 
> 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 prob

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Kyle Sanderson]

>  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)
 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 
> Sent: Tuesday, November 17, 2020 9:38 AM
> To: csgo_servers@list.valvesoftware.com
> Cc: Fletcher Dunn 
> 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 immed

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[John]

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 
*Sent:* Tuesday, November 17, 2020 9:38 AM
*To:* csgo_servers@list.valvesoftware.com
*Cc:* Fletcher Dunn 
*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

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

One more clarification: this proposal is only to change A2S_INFO, A2S_PLAYER, 
and A2S_INFO.  There are other connectionless packets in Source engine 
protocols.  We could update our own games to require that those be padded as 
well (and check the same environment variables).  But it's totally separate 
code.  (Not to mention other games!)  So, any filtering will need to be smarter 
than just checking if the first 32-bits are .

While I'm touching this code, I'm also hardening the challenge generation.

From: csgo_servers@list.valvesoftware.com 
Sent: Tuesday, November 17, 2020 10:29 AM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

As John said, padding with zeros will be easier to mitigate (and less resource 
intensive) for providers, and it solves the reflection.

Any word on the last bit of John's response regarding "abuse" of BGP/Anycasting 
to reply to source engine queries from the closest geographical location to the 
requester?

It's one thing for hosts to use edge locations to mitigate attacks, allowing 
inbound filtering to be spread across multiple edge locations. But people are 
taking it a step further and intentionally sending a cached query response from 
those edge locations to benefit from players thinking their server has the 
lowest latency in the server browser.



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 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/

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

>Any word on the last bit of John's response regarding "abuse" of 
>BGP/Anycasting to reply
>to source engine queries from the closest geographical location to the 
>requester?

I don't have a good answer for this right now, unfortunately.

From: csgo_servers@list.valvesoftware.com 
Sent: Tuesday, November 17, 2020 10:29 AM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

As John said, padding with zeros will be easier to mitigate (and less resource 
intensive) for providers, and it solves the reflection.

Any word on the last bit of John's response regarding "abuse" of BGP/Anycasting 
to reply to source engine queries from the closest geographical location to the 
requester?

It's one thing for hosts to use edge locations to mitigate attacks, allowing 
inbound filtering to be spread across multiple edge locations. But people are 
taking it a step further and intentionally sending a cached query response from 
those edge locations to benefit from players thinking their server has the 
lowest latency in the server browser.



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 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/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

As John said, padding with zeros will be easier to mitigate (and less 
resource intensive) for providers, and it solves the reflection.


Any word on the last bit of John's response regarding "abuse" of 
BGP/Anycasting to reply to source engine queries from the closest 
geographical location to the requester?


It's one thing for hosts to use edge locations to mitigate attacks, 
allowing inbound filtering to be spread across multiple edge locations. 
But people are taking it a step further and intentionally sending a 
cached query response from those edge locations to benefit from players 
thinking their server has the lowest latency in the server browser.




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 unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Marco Padovan]

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)  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 
> *Sent:* Tuesday, November 17, 2020 9:38 AM
> *To:* csgo_servers@list.valvesoftware.com
> *Cc:* Fletcher Dunn 
> *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.  Fix

RE: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

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 
Sent: Tuesday, November 17, 2020 9:38 AM
To: csgo_servers@list.valvesoftware.com
Cc: Fletcher Dunn 
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: 0x
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, 

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[John]

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: 0x

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.

RE: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

Also, in case it isn’t clear, if the server is not updated the game still 
works.  Clients sending padded packets can work with old servers.

Are there any example of old *clients* that cannot be updated and need to talk 
to new servers?

From: csgo_servers@list.valvesoftware.com 
Sent: Tuesday, November 17, 2020 9:05 AM
To: csgo_servers@list.valvesoftware.com
Subject: RE: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO 
protocol

>proposing breaking tens of orphaned games

Can you give some examples of games that would be broken?

From: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com> 
mailto:csgo_servers@list.valvesoftware.com>>
 On Behalf Of Kyle Sanderson
Sent: Monday, November 16, 2020 11:44 PM
To: 
csgo_servers@list.valvesoftware.com<mailto:csgo_servers@list.valvesoftware.com>
Subject: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO 
protocol

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.

___
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/

RE: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

>proposing breaking tens of orphaned games

Can you give some examples of games that would be broken?

From: csgo_servers@list.valvesoftware.com  
On Behalf Of Kyle Sanderson
Sent: Monday, November 16, 2020 11:44 PM
To: csgo_servers@list.valvesoftware.com
Subject: [External Mail] Re: [Csgo_servers] RFC: Changes to the A2S_INFO 
protocol

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.
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Tyler Janse]

That's quite fair Kyle.

I'm not as versed on the intricacies of how changes to CSGO specifically
will propagate across other games.  However, I see what you mean.  Since
the shared object/library will be modified (shared across other SRCDS, not
just CSGO servers), only those who have active maintainers would transition
to the next "level" and those without dedicated maintainers will be left
off to the side.  Wouldn't this be a good discussion to have with the HLDS
community as a whole then instead of just the CSGO_Servers listserv?

If I'm reading this correctly, it'd be disappointing to lose those games.
Would there be a way for us to get around this, such as having "legacy"
server browser or such?  Or would this be a hard cut?  Is there a potential
for community-supported solutions?  Has anyone ever thought about this
before?  This opens up more questions regarding future/potential support
for other legacy software.

However, as far as progress goes, I see this as a step forward.  Ideally
we'd like a solution that supports all options but if we're at a
crossroads, I hate to say it for the nostalgic guy in me, but I'm still
leaning towards option 2.

- Tyler Janse



On Tue, Nov 17, 2020 at 11:16 AM Kyle Sanderson  wrote:

> All good Tyler. Yes, while this is on csgo_servers, the first paragraph
> clearly states this impacts all consumers.
>
> ```
> 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 is not just a change against CSGO, this is a change across the entire
> platform that has massive implications. Additionally, CSGO has not
> responded to these messages (completely, anyway) by default for many years
> (over 6 years if memory serves) which makes this all the more difficult to
> comprehend as this is not a change that impacts CSGO in the slightest.
>
> I really don't like this proposal because it's going to break old, stable,
> orphaned games that no one has the source code to anymore as the studios /
> artists are long gone. This is why I was claiming arson - because these
> games will finally die. I think the vast majority of us are against game
> death which is why I was/am quite irked by some of the comments saying this
> is fine for GSPs.
>
> Kyle.
>
> On Tue, 17 Nov 2020, 07:48 Tyler Janse,  wrote:
>
>> Kyle,
>>
>> I understand your argument however I think you're focusing on the wrong
>> baseline.  I'm familiar with SNMP and NTP and the volume of reflection
>> attacks.
>>
>> SNMP and NTP are significantly more widely adopted than SRCDS which is
>> why you'll get those volumes of traffic.  I'm not disagreeing with you on
>> that.  However, the point still stands that this is only focusing on
>> A2S_INFO protocol and the potential changes to the structure of said
>> protocol to minimize such issues.  This isn't a discussion about changes to
>> the SNMP and NTP protocol to mitigate these issues (most might argue
>> "configure SNMPD right!" or "put it behind a firewall"...).  Also I don't
>> see the "breaking tens of orphaned games" when this is the CSGO_Servers
>> listserv.  If you're talking about servers that have been orphaned then
>> those servers probably haven't been updated anyways, therefore preventing
>> people (with updated game clients) from connecting to them.  With or
>> without this change, server hosters have to update the game and underlying
>> mods anyways to continue to get players into their games.
>>
>> I think we can sum this up in a fairly simple way.
>>
>> *PROS*
>> - Reduce potential for reflection attacks from SRCDS
>>
>> *CONS*
>> - Additional effort needed to modify solutions built on top of this
>> protocol
>>
>> I'm not saying that developer time and attention is nothing, especially
>> since so much has been built off the backs of third party developers and
>> modders.  However, from what I see, it seems like this time investment will
>> continue to refine the underlying servers that props this game up.  I see
>> the argument of SNMP and NTP irrelevant as we're talking here about
>> something else.
>>
>> Also notice that they've published a schedule of staged deployments for
>> this solution.  It's not like they're going to flip the switch tomorrow and
>> all hell breaks loose.  If I'm misinformed, then please let me know.
>>
>> There's no reason to be condescending.  I'm not trying to be an arsonist
>> or "ruin everyone's fun".  Let's have a healthy discussion instead of
>> biting off everyone's head.
>>
>> - Tyler
>>
>>
>>
>> On Tue, Nov 17, 2020 at 9:50 AM David Parker  wrote:
>>
>>> I will also jump in here and say that I like option #2 better.  It's
>>> simpler and more 

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Kyle Sanderson]

All good Tyler. Yes, while this is on csgo_servers, the first paragraph
clearly states this impacts all consumers.

```
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 is not just a change against CSGO, this is a change across the entire
platform that has massive implications. Additionally, CSGO has not
responded to these messages (completely, anyway) by default for many years
(over 6 years if memory serves) which makes this all the more difficult to
comprehend as this is not a change that impacts CSGO in the slightest.

I really don't like this proposal because it's going to break old, stable,
orphaned games that no one has the source code to anymore as the studios /
artists are long gone. This is why I was claiming arson - because these
games will finally die. I think the vast majority of us are against game
death which is why I was/am quite irked by some of the comments saying this
is fine for GSPs.

Kyle.

On Tue, 17 Nov 2020, 07:48 Tyler Janse,  wrote:

> Kyle,
>
> I understand your argument however I think you're focusing on the wrong
> baseline.  I'm familiar with SNMP and NTP and the volume of reflection
> attacks.
>
> SNMP and NTP are significantly more widely adopted than SRCDS which is why
> you'll get those volumes of traffic.  I'm not disagreeing with you on
> that.  However, the point still stands that this is only focusing on
> A2S_INFO protocol and the potential changes to the structure of said
> protocol to minimize such issues.  This isn't a discussion about changes to
> the SNMP and NTP protocol to mitigate these issues (most might argue
> "configure SNMPD right!" or "put it behind a firewall"...).  Also I don't
> see the "breaking tens of orphaned games" when this is the CSGO_Servers
> listserv.  If you're talking about servers that have been orphaned then
> those servers probably haven't been updated anyways, therefore preventing
> people (with updated game clients) from connecting to them.  With or
> without this change, server hosters have to update the game and underlying
> mods anyways to continue to get players into their games.
>
> I think we can sum this up in a fairly simple way.
>
> *PROS*
> - Reduce potential for reflection attacks from SRCDS
>
> *CONS*
> - Additional effort needed to modify solutions built on top of this
> protocol
>
> I'm not saying that developer time and attention is nothing, especially
> since so much has been built off the backs of third party developers and
> modders.  However, from what I see, it seems like this time investment will
> continue to refine the underlying servers that props this game up.  I see
> the argument of SNMP and NTP irrelevant as we're talking here about
> something else.
>
> Also notice that they've published a schedule of staged deployments for
> this solution.  It's not like they're going to flip the switch tomorrow and
> all hell breaks loose.  If I'm misinformed, then please let me know.
>
> There's no reason to be condescending.  I'm not trying to be an arsonist
> or "ruin everyone's fun".  Let's have a healthy discussion instead of
> biting off everyone's head.
>
> - Tyler
>
>
>
> On Tue, Nov 17, 2020 at 9:50 AM David Parker  wrote:
>
>> I will also jump in here and say that I like option #2 better.  It's
>> simpler and more consistent with the other protocols used by SRCDS, and
>> keeps the packets nice and small while also (hopefully) mitigating these
>> attacks.
>>
>> And Fletcher, I appreciate you reaching out and soliciting feedback
>> before making this change.  Scrambling to implement a change in our
>> A2S_INFO clients after the fact would not have been much fun.
>>
>> Thanks!
>>
>> On Tue, Nov 17, 2020 at 3:33 AM YUAN RUI - number201724 at me.com (via
>> csgo_servers list)  wrote:
>>
>>> In another case, someone sends a fake connect packet to fill the server.
>>>
>>> FF FF FF FF connect.
>>>
>>> The server always prompts "server is full."
>>>
>>> They use proxy ips, and thousands of ips are sending fake data.
>>>
>>>
>>> On 11/17/2020 3:44 PM, Kyle Sanderson wrote:
>>>
>>> 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 

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Tyler Janse]

Kyle,

I understand your argument however I think you're focusing on the wrong
baseline.  I'm familiar with SNMP and NTP and the volume of reflection
attacks.

SNMP and NTP are significantly more widely adopted than SRCDS which is why
you'll get those volumes of traffic.  I'm not disagreeing with you on
that.  However, the point still stands that this is only focusing on
A2S_INFO protocol and the potential changes to the structure of said
protocol to minimize such issues.  This isn't a discussion about changes to
the SNMP and NTP protocol to mitigate these issues (most might argue
"configure SNMPD right!" or "put it behind a firewall"...).  Also I don't
see the "breaking tens of orphaned games" when this is the CSGO_Servers
listserv.  If you're talking about servers that have been orphaned then
those servers probably haven't been updated anyways, therefore preventing
people (with updated game clients) from connecting to them.  With or
without this change, server hosters have to update the game and underlying
mods anyways to continue to get players into their games.

I think we can sum this up in a fairly simple way.

*PROS*
- Reduce potential for reflection attacks from SRCDS

*CONS*
- Additional effort needed to modify solutions built on top of this
protocol

I'm not saying that developer time and attention is nothing, especially
since so much has been built off the backs of third party developers and
modders.  However, from what I see, it seems like this time investment will
continue to refine the underlying servers that props this game up.  I see
the argument of SNMP and NTP irrelevant as we're talking here about
something else.

Also notice that they've published a schedule of staged deployments for
this solution.  It's not like they're going to flip the switch tomorrow and
all hell breaks loose.  If I'm misinformed, then please let me know.

There's no reason to be condescending.  I'm not trying to be an arsonist or
"ruin everyone's fun".  Let's have a healthy discussion instead of biting
off everyone's head.

- Tyler



On Tue, Nov 17, 2020 at 9:50 AM David Parker  wrote:

> I will also jump in here and say that I like option #2 better.  It's
> simpler and more consistent with the other protocols used by SRCDS, and
> keeps the packets nice and small while also (hopefully) mitigating these
> attacks.
>
> And Fletcher, I appreciate you reaching out and soliciting feedback before
> making this change.  Scrambling to implement a change in our A2S_INFO
> clients after the fact would not have been much fun.
>
> Thanks!
>
> On Tue, Nov 17, 2020 at 3:33 AM YUAN RUI - number201724 at me.com (via
> csgo_servers list)  wrote:
>
>> In another case, someone sends a fake connect packet to fill the server.
>>
>> FF FF FF FF connect.
>>
>> The server always prompts "server is full."
>>
>> They use proxy ips, and thousands of ips are sending fake data.
>>
>>
>> On 11/17/2020 3:44 PM, Kyle Sanderson wrote:
>>
>> 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, 
>> 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 

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[David Parker]

I will also jump in here and say that I like option #2 better.  It's
simpler and more consistent with the other protocols used by SRCDS, and
keeps the packets nice and small while also (hopefully) mitigating these
attacks.

And Fletcher, I appreciate you reaching out and soliciting feedback before
making this change.  Scrambling to implement a change in our A2S_INFO
clients after the fact would not have been much fun.

Thanks!

On Tue, Nov 17, 2020 at 3:33 AM YUAN RUI - number201724 at me.com (via
csgo_servers list)  wrote:

> In another case, someone sends a fake connect packet to fill the server.
>
> FF FF FF FF connect.
>
> The server always prompts "server is full."
>
> They use proxy ips, and thousands of ips are sending fake data.
>
>
> On 11/17/2020 3:44 PM, Kyle Sanderson wrote:
>
> 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,  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 
>> wrote:
>>
>>> lol. Who are you.
>>>
>>> Best,
>>> Kyle.
>>>
>>> On Mon, 16 Nov 2020, 19:45 Calvin Judy - calvin at swiftnode.net (via
>>> csgo_servers list),  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)  
  wrote:

 ___
 To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
 https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

In another case, someone sends a fake connect packet to fill the server.

FF FF FF FF connect.

The server always prompts "server is full."

They use proxy ips, and thousands of ips are sending fake data.


On 11/17/2020 3:44 PM, Kyle Sanderson wrote:

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, > 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
mailto: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),
mailto: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 atswiftnode.net  

(via csgo_servers list)  
  wrote:


___
To unsubscribe, edit your list preferences, or view the
list archives,
please visit:
https://list.valvesoftware.com/


___
To 

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Kyle Sanderson]

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,  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 
> wrote:
>
>> lol. Who are you.
>>
>> Best,
>> Kyle.
>>
>> On Mon, 16 Nov 2020, 19:45 Calvin Judy - calvin at swiftnode.net (via
>> csgo_servers list),  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)  
>>>  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/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Tyler Janse]

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  wrote:

> lol. Who are you.
>
> Best,
> Kyle.
>
> On Mon, 16 Nov 2020, 19:45 Calvin Judy - calvin at swiftnode.net (via
> csgo_servers list),  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)  
>>  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/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Kyle Sanderson]

lol. Who are you.

Best,
Kyle.

On Mon, 16 Nov 2020, 19:45 Calvin Judy - calvin at swiftnode.net (via
csgo_servers list),  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)  
>  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/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

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)  wrote:

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Kyle Sanderson]

> thousands of srcds servers
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)  wrote:
>
> Kyle,
>
> SRCDS doesn't need to be a "majority stakeholder" to receive patches to known 
> security vulnerabilities. There's tens of thousands of srcds servers, nearly 
> all of which can be sent a spoofed query and will respond to a victim address 
> with server information. "Only 8x" is still enough to cause plenty of people 
> issues, when this can be resolved by a patch like Fletcher is suggesting. We 
> still see dozens of these attacks per month. Patching this won't have the 
> same impact as patching the memcached reflection, but it will still result in 
> a decrease in attacks, and allow a simplified mitigation solution.
>
> To break down how 8x can still overwhelm plenty of providers:
>
> Five servers/zombies on providers non-compliant with BCP38/RFC2827, each with 
> 1000mbit uplinks, send spoofed source engine queries to 5,000 srcds servers. 
> At 8x average amplification, the victim address will theoretically receive 
> 40Gbps worth of responses from those 5,000 srcds instances.
>
> Also, if I'm not mistaken, they did try to patch this previously a couple 
> years ago on CSGO, with the addition of the sv_max_queries_sec. But 
> unfortunately there's tens of thousands of srcds servers malicious actors can 
> cycle through, so those commands aren't very effective at their default 
> values.
>
>
> I think where I'm going with this is why on gods green earth are we
> doing this when SRCDS is just not a majority stakeholder on the
> internet anymore. I'm confuzzled: and now I'm confused.
>
> Kyle.
>
>
> ___
> 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/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

Kyle,

SRCDS doesn't need to be a "majority stakeholder" to receive patches to 
known security vulnerabilities. There's tens of thousands of srcds 
servers, nearly all of which can be sent a spoofed query and will 
respond to a victim address with server information. "Only 8x" is still 
enough to cause plenty of people issues, when this can be resolved by a 
patch like Fletcher is suggesting. We still see dozens of these attacks 
per month. Patching this won't have the same impact as patching the 
memcached reflection, but it will still result in a decrease in attacks, 
and allow a simplified mitigation solution.


To break down how 8x can still overwhelm plenty of providers:

Five servers/zombies on providers non-compliant with BCP38/RFC2827, each 
with 1000mbit uplinks, send spoofed source engine queries to 5,000 srcds 
servers. At 8x average amplification, the victim address will 
theoretically receive 40Gbps worth of responses from those 5,000 srcds 
instances.


Also, if I'm not mistaken, they did try to patch this previously a 
couple years ago on CSGO, with the addition of the sv_max_queries_sec. 
But unfortunately there's tens of thousands of srcds servers malicious 
actors can cycle through, so those commands aren't very effective at 
their default values.




I think where I'm going with this is why on gods green earth are we
doing this when SRCDS is just not a majority stakeholder on the
internet anymore. I'm confuzzled: and now I'm confused.

Kyle.


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

Fletcher,

Either option would work in theory, but #2 seems like the proper way to 
resolve this. Alfred spoke with me about this back in late 2015, but 
wasn't really concerned with patching it then, since then we've worked 
out many effective methods of filtering these attacks. (header 
checksums, rate limits, udp hashlimits) each method comes with their own 
tax on resources of our mitigation hardware. As a provider, having a 
unified, simple solution to filter these would be nice. Assuming this 
breaks older queries, there should also be a pretty significant decrease 
in the amount of attacks, as well as increasing the bandwidth required 
to launch them.

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Kyle Sanderson]

Hope you're well Fletcher.

I stopped following the list and similar for a number of reasons -
like breaking stable behaviour, it being debated in internal scrums
(and no one reached back before Valve issued threats!) for no reason.
I gave up after defeating the latest regression fully using basic
asmjs + remote code exec which is 100% not the avenue that I wanted to
utilize + ultimately aging out. SRCDS is not the same reflection
avenue that SNMP and some russian STB HTTP protocol had a decade ago -
and even now post other games implementing the wire protocol.
Arbitrarily it looks like it's 8x right now and you're proposing
breaking stable wire for an additional Byte which does not help fix
this. The game thread will still get destroyed on responses per usual,
and reflection attacks using SRCDS are just not relevant anymore.

I think where I'm going with this is why on gods green earth are we
doing this when SRCDS is just not a majority stakeholder on the
internet anymore. I'm confuzzled: and now I'm confused.

Kyle.

On Mon, Nov 16, 2020 at 5:22 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: 0x
>
> 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/

[Csgo_servers] RFC: Changes to the A2S_INFO protocol

[via csgo_servers list]

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: 0x
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/