[radext] Re: Comments on draft-janfred-radext-radius-congestion-control

[Alan DeKok <[e-mail]>]

On Nov 6, 2025, at 12:39 PM, Alan DeKok <alan.dekok=[e-mail]> wrote:
...

  Some points from the current discussion:

  It looks like the solution does not need Proxy-Capabilities in every Access-Request.

  The goal of the congestion control document is two-fold:

1. Reduce the total amount of traffic sent over a proxy network

2. More quickly clean up the 8-bit IDs across a proxy network.

  The blocking of users is for a few different situations:

1. I haven't had an account for 10 years, but my phone still tries to connect

  * we want to be able to say "this user is blocked at that location for a longish period of time"

2. A broken system is sending enormous amounts of traffic for one account

  * we want to delay rejects, which experience shows will also slow down the sender

3. An attacker is testing passwords, either by sending enormous amounts of traffic (as with #2), or by sending many simultaneous access requests for one account

  * we want to block this account for a shortish period of time, and/or delay rejects for a short time.


  The discussion in Montreal indicates that the "delay reject for one second" situation is very similar to the situation of "block this user for one second".  As such, we may not need two different mechanisms.

  Another result of the discussion is that we should recommend that all "edge" RADIUS servers ensure that there is at least a short delay between request and reject.  And, that proxies should ideally forward traffic as quickly as possible.

  The recommendations for a home server are then:

1. If the account doesn't exist, it should reply indicating that the account is blocked for a "long" period of time, e.g. 10 min.

2. If the credentials are wrong, it should reply indicating that the account is blocked for a "short" period of time, e.g. 1-5 seconds.

  The combination of the recommendations for the "edge" and "home" servers should address most of the requirements noted above.

  Alan DeKok.