IETF Logo Mail Archive

[radext] Server identity and RFC7585bis (was: Review of draft-ietf-radext-radiusdtls)

Jan-Frederik Rieckers <rieckers@dfn.de> Wed, 10 April 2024 07:35 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 50DBBC14F5FF for <radext@ietfa.amsl.com>; Wed, 10 Apr 2024 00:35:07 -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 Jp-36Lc2Psuo for <radext@ietfa.amsl.com>; Wed, 10 Apr 2024 00:35:02 -0700 (PDT)
Received: from b1004.mx.srv.dfn.de (b1004.mx.srv.dfn.de [194.95.235.6]) (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 15425C14F5FE for <radext@ietf.org>; Wed, 10 Apr 2024 00:35:00 -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=1712734496; x=1714548897; bh=mYDNS/ev4c8uiJny4VMKjg8SMSY2DNXc6ho5SJGzW+g=; b= BYig8gkajzrc9BrvpDeaem/Iwjb2sg6jL2FTCDbeZb+ueTAdXv0sJmH3I748LE7C sPq/PEY4unlZPEeYkX4m3vjk1CxUJwFCBrXlsv/QzwTpz3MMaqrAbBWIpnhGoETi ypnNRC4wqVLOD8w/W24EY1ESaSSiA1iimF6Ok83Q3Vg=
Received: from mail.dfn.de (mail.dfn.de [194.95.245.150]) by b1004.mx.srv.dfn.de (Postfix) with ESMTPS id D56F52200DA for <radext@ietf.org>; Wed, 10 Apr 2024 09:34:56 +0200 (CEST)
Received: from [IPV6:2001:638:d:1016::1002] (unknown [IPv6:2001:638:d:1016::1002]) (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 A82F23D6 for <radext@ietf.org>; Wed, 10 Apr 2024 09:34:56 +0200 (CEST)
Message-ID: <6628c5c8-5071-476f-9ea2-2875d86304e2@dfn.de>
Date: Wed, 10 Apr 2024 09:34:55 +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>
Content-Language: en-US
From: Jan-Frederik Rieckers <rieckers@dfn.de>
X-Enigmail-Draft-Status: N11222
Organization: DFN e.V.
In-Reply-To: <18ef8267-474e-49ae-9204-0c6c79d5e50c@dfn.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms020008010401040302070304"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/9vdDZIcV82uSoAeTIXccnRfIzaY>
Subject: [radext] Server identity and RFC7585bis (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: Wed, 10 Apr 2024 07:35:07 -0000


On 20.03.24 03:55, Jan-Frederik Rieckers wrote:
>>     ... If a RADIUS/(D)TLS client has multiple connection to a server, 
>> it MUST NOT decide to mark the whole server as DOWN until all 
>> connections to it have been marked DOWN.
>>
>>    Maybe add a discussion of what, exactly, is a "server". Destination 
>> IP?  How is this affected by RFC 7585 dynamic DNS lookups?
> 
> I've added a TODO for after the IETF.

I've started to write a section to explain how a server is uniquely 
identified, but I am failing to come up with anything other than 
destination IP address and destination port.
Is there some better qualifier?

I'm not sure if this warrants a whole section "Server Identity" which 
basically just says "If it's the same IP addr and port, its the same 
server".

This would probably still be the same with dynamic lookups. If you 
already have a standing session with the server, then you wouldn't need 
to open a new connection. Just save the reference to the server in your 
dynamic lookup table.


This also opens up the discussion about RFC 7585 again.
This is currently an experimental RFC too, with one Erratum in "hold for 
document update", so we could issue a -bis document there too.

I'd be happy to get the ball rolling on that one too, if there is interest.


Cheers,
Janfred
-- 
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

v2.23.0 | Report a Bug | By Email