IETF Logo Mail Archive

Re: [radext] Session closure in DTLS (was: Review of draft-ietf-radext-radiusdtls)

Alan DeKok <aland@deployingradius.com> Thu, 18 April 2024 13:05 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75BAC14F689 for <radext@ietfa.amsl.com>; Thu, 18 Apr 2024 06:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whfUZzIjfE1J for <radext@ietfa.amsl.com>; Thu, 18 Apr 2024 06:05:40 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BDCC14F6A7 for <radext@ietf.org>; Thu, 18 Apr 2024 06:05:38 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 5D50320A; Thu, 18 Apr 2024 13:05:36 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <f73233a3-2c0c-48f6-b80b-d3e7e1ccd753@dfn.de>
Date: Thu, 18 Apr 2024 09:05:34 -0400
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B704FF43-2219-4C56-BA85-A089C40A6AC4@deployingradius.com>
References: <CA9BEA9C-39EF-4764-A0FE-D122413B37F7@deployingradius.com> <47fb04d9-a224-457f-b169-d94e29fe007e@dfn.de> <f73233a3-2c0c-48f6-b80b-d3e7e1ccd753@dfn.de>
To: Jan-Frederik Rieckers <rieckers@dfn.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/ft9ThkVRZi7TXl4yivcJyK08mto>
Subject: Re: [radext] Session closure in DTLS (was: Review of draft-ietf-radext-radiusdtls)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2024 13:05:47 -0000

On Apr 18, 2024, at 8:47 AM, Jan-Frederik Rieckers <rieckers@dfn.de> wrote:
> It may be useful to have session information after a graceful closure, which would also fall under "closed for any reason".
> Before we change that, I would like to hear opinions from other people (hopefully some people a bit more familiar with DTLS)

  People are familiar with DTLS?  :(

  My limited understanding is that once the TLS layer says "done", then the TLS layer is no longer usable.

  At which point, there is no aunt in an application keeping the TLS session around.

  There is the corner case of lost packets.  i.e. one end sends 4 packets, some of which are lost.  The other end sends a TLS Closure Alert.

  Will the lost packets be retransmitted, or just lost?  It's not clear.  I think the safest assumption is that they'll be lost.

  It would be good to clarify whether or not the application needs to do any retransmissions itself.  If instead it rely on the DTLS layer to do retransmissions, then that simplifies this spec.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email