Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193])
	by mx.ietf.org (Postfix) with ESMTP id 206E430
	for <radext@ietf.org>; Tue, 22 Sep 2026 09:54:38 +0000 (UTC)
Authentication-Results: mx.ietf.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx.ietf.org: domain of peterd@iea-software.com designates
 70.89.142.193 as permitted sender) smtp.mailfrom=peterd@iea-software.com
Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com
 (Rockliffe SMTPRA 7.0.6) with ESMTP id <B0006276647@aspen.iea-software.com>;
 Tue, 22 Sep 2026 02:54:31 -0700
Date: Tue, 22 Sep 2026 02:54:32 -0700 (Pacific Daylight Time)
From: Peter Deacon <peterd@iea-software.com>
To: Jan-Frederik Rieckers <rieckers@dfn.de>
In-Reply-To: <f5ac552e-01e8-4af1-b6a5-554c0bcc04d2@dfn.de>
Message-ID: <c943d687-ea4f-9fa3-6e76-554290513b69@iea-software.com>
References: <4be6b9ec-3432-441f-a1f2-689261d94571@dfn.de>
 <d858013a-e223-257a-5b4d-2835224a78ac@iea-software.com>
 <12fc615b-f563-4237-8928-e3fa6a784912@switch.ch>
 <50505951-a2b5-5712-6983-c967ad2da96e@iea-software.com>
 <0a7d41a9-baea-4d04-94fb-3414f4941001@switch.ch>
 <f5ac552e-01e8-4af1-b6a5-554c0bcc04d2@dfn.de>
MIME-Version: 1.0
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
Content-ID: <729588c5-3b06-12d4-486e-6673e18c9b6b@iea-software.com>
X-Spamd-Bar: /
Message-ID-Hash: JYCIE5X4D345QTXODNPRC5MJLXUWQ3UO
X-Message-ID-Hash: JYCIE5X4D345QTXODNPRC5MJLXUWQ3UO
X-MailFrom: peterd@iea-software.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop;
 banned-address; header-match-radext.ietf.org-0; emergency; member-moderation;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
CC: radext@ietf.org
X-Mailman-Version: 3.3.10
Precedence: list
Subject: [radext] Re: Final update to RADIUS/(D)TLS-bis
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/radext/v_aSCQ550dnFxvEGqe_hKSMSGiY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Owner: <mailto:radext-owner@ietf.org>
List-Post: <mailto:radext@ietf.org>
List-Subscribe: <mailto:radext-join@ietf.org>
List-Unsubscribe: <mailto:radext-leave@ietf.org>

On Sun, 6 Sep 2026, Jan-Frederik Rieckers wrote:

> Hello,
> I'm not sure if a "SHOULD" for the connection closure is sufficient.

> If a connection has a security issue it should always be closed 
> immediately. Keeping the connection artificially open is harmful, 
> because the client might start to send packets and those may even time 
> out if the server knows the connection is unacceptable and does not 
> process anything received on that connection.

If a client offends a server in some way a server should not be required 
to provide immediate feedback if doing so would be harmful to the server.

A robust client implementation could issue an application keepalive 
immediate upon session establishment or initially concurrently connect to 
multiple servers using the one that responds first.  I don't support 
requiring instant feedback to an offensive client.

Unfortunately given current draft even over a "reliable" transport a 
perfectly valid request over a perfectly valid connection is allowed to be 
summarily ignored with not even a best effort expectation of any kind of 
response.

Clients therefore have to be able to handle these bizarre situations where 
even reliable transports act for all intent and purposes as if they were 
unreliable.  Not just initially but throughout the life of the session.

regards,
Peter
