IETF Logo Mail Archive

[radext] Accounting and Protocol-Error (was: Review of draft-ietf-radext-radiusdtls)

Jan-Frederik Rieckers <rieckers@dfn.de> Wed, 10 April 2024 07:59 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 F3892C14F5FE for <radext@ietfa.amsl.com>; Wed, 10 Apr 2024 00:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 Py0tRB28mu1n for <radext@ietfa.amsl.com>; Wed, 10 Apr 2024 00:58:59 -0700 (PDT)
Received: from a1004.mx.srv.dfn.de (a1004.mx.srv.dfn.de [IPv6:2001:638:d:c301: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 81681C14F68E for <radext@ietf.org>; Wed, 10 Apr 2024 00:58:58 -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=1712735929; x=1714550330; bh=gFPNT3EG7wIi2p3UiETSseUGuziLylWqKSlu/ulYOHw=; b= gqvqYFN8oSa9I+cnnBGxjqUGO1Uwftk/ir3v/K12+rCttzSjKU3DT9hhwupYANwW ijyhP8b2nymBWWcF5lc4yJsk4fjD9Jex1UFiEroZbLnN1Yfx0ekDiZZxyBacZyMp rM9efYWvnxJ43QNcmMp0oQ5jWANj+526Xj23OxRFARw=
Received: from mail.dfn.de (mail.dfn.de [194.95.245.150]) by a1004.mx.srv.dfn.de (Postfix) with ESMTPS id 1A7202000E4 for <radext@ietf.org>; Wed, 10 Apr 2024 09:58:49 +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 DFBAE41C for <radext@ietf.org>; Wed, 10 Apr 2024 09:58:48 +0200 (CEST)
Message-ID: <a0538e50-9219-47db-9cf8-87a52a9413c1@dfn.de>
Date: Wed, 10 Apr 2024 09:58:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: radext@ietf.org
References: <CA9BEA9C-39EF-4764-A0FE-D122413B37F7@deployingradius.com> <47fb04d9-a224-457f-b169-d94e29fe007e@dfn.de>
Content-Language: en-US
From: Jan-Frederik Rieckers <rieckers@dfn.de>
Organization: DFN e.V.
In-Reply-To: <47fb04d9-a224-457f-b169-d94e29fe007e@dfn.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms020009000509030900090703"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/0D_t5A6eJMPjRWLW4GPxfXLOGz0>
Subject: [radext] Accounting and Protocol-Error (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:59:04 -0000


On 20.03.24 07:59, Jan-Frederik Rieckers wrote:
>> 4.4.
>>
>>     ... When an unwanted packet of type 'Accounting-Request' is 
>> received, the RADIUS/(D)TLS server SHOULD reply with an 
>> Accounting-Response ...
>>
>>    Perhaps Protocol-Error would be better here?  The temptation for 
>> proxies would be to simply return any Accounting-Response packet 
>> without examining it.  Which does not meet the goal of hop-by-hop 
>> signalling.
> 
> This would mean a deviation from the original spec.
> I'm not familiar with Accounting (since it is not used in eduroam), I'll 
> have a closer look at it.
> 
> For now I've added a TODO

Protocol-Error is defined in RFC7930, which is experimental, as far as I 
can see.
(Could we just ask the IESG to change this to Proposed Standard without 
a bis document? I'm not sure about the process here. I haven't read the 
document fully yet, but it's on my reading list.)

I don't have a very strong opinion about this, but since this changes 
the original RFC6614/7360 spec, we should make an informed decision, 
especially because this affects clients.
Clients are the part where the current bis document changes the least, 
i.e. by not mandating both TLS and DTLS.

Changing the response from Accounting-Response to Protocol-Error would 
mean that clients need to adjust their implementation.

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