Re: [radext] Server identity and RFC7585bis

Jan-Frederik Rieckers <rieckers@dfn.de> Thu, 11 April 2024 12:08 UTC

Return-Path: <rieckers@dfn.de>
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 4BC03C14F5EB for <radext@ietfa.amsl.com>; Thu, 11 Apr 2024 05:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dfn.de
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 fUr2wtxHwEtF for <radext@ietfa.amsl.com>; Thu, 11 Apr 2024 05:08:25 -0700 (PDT)
Received: from c1004.mx.srv.dfn.de (c1004.mx.srv.dfn.de [IPv6:2001:638:d:c303:acdc:1979:2:58]) (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 D888CC14F5E7 for <radext@ietf.org>; Thu, 11 Apr 2024 05:08:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dfn.de; h= content-type:content-type:in-reply-to:organization:from:from :content-language:references:subject:subject:user-agent :mime-version:date:date:message-id:received; s=s1; t=1712837299; x=1714651700; bh=d21w2x4IeLjD6ZafsLhEH4MkZnPI7joH4kmjPKH1vGg=; b= XJXRcDCACarCsvrdSpXki/q3zeLXRS9N7j0katP/nkarchOdw4/UZl4zYCEvBkBe 9r5WIQYoC0OC3Cuq3xKHX4x7x4bE9gSHT5+M8R7J0N1khTa23xRrlNVoAsdU6cxW RsJfc4SNEmbfBwclXKHZV5AXv5bu6k0GJBa+ufn6pUk=
Received: from mail.dfn.de (mail.dfn.de [IPv6:2001:638:d:c102::150]) by c1004.mx.srv.dfn.de (Postfix) with ESMTPS id 4760212011E for <radext@ietf.org>; Thu, 11 Apr 2024 14:08:19 +0200 (CEST)
Received: from [IPV6:2001:638:d:1010::1003] (unknown [IPv6:2001:638:d:1010::1003]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mspool2.in.dfn.de (Postfix) with ESMTPSA id F0C983D6 for <radext@ietf.org>; Thu, 11 Apr 2024 14:08:18 +0200 (CEST)
Message-ID: <6c93c523-d4de-47cb-b87d-e18275939355@dfn.de>
Date: Thu, 11 Apr 2024 14:08:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: radext@ietf.org
References: <CA9BEA9C-39EF-4764-A0FE-D122413B37F7@deployingradius.com> <18ef8267-474e-49ae-9204-0c6c79d5e50c@dfn.de> <6628c5c8-5071-476f-9ea2-2875d86304e2@dfn.de> <PH0PR11MB5928CD1EB7DBD5349EB84055D2062@PH0PR11MB5928.namprd11.prod.outlook.com>
Content-Language: en-US
From: Jan-Frederik Rieckers <rieckers@dfn.de>
Organization: DFN e.V.
In-Reply-To: <PH0PR11MB5928CD1EB7DBD5349EB84055D2062@PH0PR11MB5928.namprd11.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms020507010701080005040100"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/_QaLlx26xmw5NSb7jRFS0toB1rI>
Subject: Re: [radext] Server identity and RFC7585bis
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, 11 Apr 2024 12:08:29 -0000

Hi Mark,

could you provide an example scenario for this? I can't really picture it.

My naïve understanding is that to phase a server out, you change the SRV 
records to point to a different server, then there should be a timeout 
for the dynamic lookup, and once this timeout triggers and the proxy 
gets the new server, it should redirect all traffic to the new and the 
old shouldn't see any traffic any more.

If it's something that is missing from RFC7585, then this might be 
another argument why we should work on a 7585bis document.

Cheers,
Janfred

On 10.04.24 09:58, Mark Grayson (mgrayson) wrote:
> As it relates to 7585, WBA recently had to clarify the same in terms of 
> cache TTL,
> 
> but also recommendation on maximum TCP lifetime for dynamic connections:
> 
> there are some scenarios where significant traffic between access providers
> 
> and identity providers means any idle timeout is never triggered and the
> 
> dynamic connection becomes persistent, which then prevents the identity
> 
> provider from gracefully terminating connections on an old server instance.
> 
>   * M

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieckers@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822