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

[Fabian Mauchle <[e-mail]>]

On 03.08.2026 00:40, Peter Deacon wrote:
> 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.

I think slow walking as a defensive measure for aggressive clients is 
fine (it's actually the aggressive clients that need fixing, see below), 
but in general not telling a (well behaved) client that the connection 
has failed I think is very bad, as the client has no way to tell that 
something is wrong and possibly do something about it. That one 
connection won't magically succeed but the client may revert to other 
connections instead.

Keeping a connection that was deemed not acceptable open for an extended 
time in my view is completely useless. Even as a defense as it won't 
prevent really aggressive clients simply opening new connections.

The text is ment to avoid confusion about what to do if none of the 
acceptance criteria is met, wich was the missing part. Closing the TLS 
side is the easiest way to tell both ends not to do anything stupid with 
the connection.


> "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.

The point here is to avoid clients spamming new connections **if** the 
server chooses to immediately close the connection (and does so only 
after the TLS handshake, as discussed in this thread).

The important part isn't whether the connection has failed (one could 
also say it hasn't succeeded), its that in these cases the client MUST 
still adhere to the exponential back-off.

-- 
Fabian