[radext] Re: Final update to RADIUS/(D)TLS-bis

[Peter Deacon <[e-mail]>]

On Sat, 1 Aug 2026, Jan-Frederik Rieckers wrote:

> Hi everyone,

> based on Fabian's feedback during the IETF, I've created a pull request with 
> some (hopefully final) changes to the document, before it can be passed on to 
> the RFC Editor.

> * A connection is treated as "failed" if it has not received valid packets 
> within the reconnect window (e.g., closed immediately after the TLS 
> handshake)

"* If a RadSec server deems a client to be not acceptable, it MUST 
terminate the (D)TLS connection immediately. RADIUS/TLS servers MUST also 
close the TCP connection. RadSec servers SHOULD send the TLS alert access 
denied(49) (if supported by the (D)TLS implementation)"

Servers should not be required to immediately terminate connections they 
don't find acceptable.  I'm not opposed to suggestions however I can 
easily see servers for example deeming it better to keep a connection open 
or slow walk closure to prevent aggressive reconnect attempts.



"If the connection is closed without having received any valid packets 
from the peer, it is also treated as failed, and the reconnect timers MUST 
NOT be reset, if the connection lasted shorter than the current reconnect 
timer."

Neither should it be presumed closure without having received any packets 
from peers constitutes failure.  It could for example be a client is 
attempting to establish a connection to available peers concurrently and 
simply closes connections to the slower peer it does not need.  In this 
case there would be no cause to presume a failure has occured.

regards,
Peter