Re: [radext] Small issues in the ALPN draft

Jan-Frederik Rieckers <rieckers@dfn.de> Wed, 20 March 2024 03:53 UTC

Message-ID: <edcbd00f-860e-4035-9abc-c9f23e8a5560@dfn.de>
Date: Wed, 20 Mar 2024 13:53:14 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: radext@ietf.org
References: <3a5885c2-fa5a-4aae-a1f4-e79b9456ad94@dfn.de> <3C061F54-4D3A-4523-AC5B-E744A22A8EA3@deployingradius.com> <c1a00b2f-e716-4e8e-87d3-0d8dedeb8957@dfn.de> <E2A51B6B-A621-41B7-8371-B5110AD29624@deployingradius.com>
From: Jan-Frederik Rieckers <rieckers@dfn.de>
Organization: DFN e.V.
In-Reply-To: <E2A51B6B-A621-41B7-8371-B5110AD29624@deployingradius.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms080006020809030101080902"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/xpV_6fYWFrje92FHIL2t-yU15b4>
Subject: Re: [radext] Small issues in the ALPN draft
Precedence: list

On 20.03.24 13:35, Alan DeKok wrote:
> On Mar 20, 2024, at 11:49 AM, Jan-Frederik Rieckers <rieckers@dfn.de> wrote:
>> We have the problem of different cache times. If the client (stupidly, but conforming with the spec) implements a lowest-free-token algorithm, and the cache times for client and server don't match, the client may purge an outstanding request after 15 sec and re-use the token value for a new request, but the server identifies this as misbehavior, because it purges outstanding requests only after 30 sec and therefore closes the connection.
> 
>    If the server has replied to a packet for token X, and then receives a *different* packet with token X, then that's fine.

The problem only occurs if the server didn't reply yet.

If there is already a reply, then I agree, this isn't a problem.

But for outstanding packets, the server and client MUST have a matching 
idea of when a token can be reused, in order to have a stable connection.

With RADIUS/UDP, a server would just discard the second (new) packet and 
the client would do retransmission until the server finally throws away 
the first (old) packet and recognizes the second as the new packet for 
this identifier.

I'm not sure how it would work with RADIUS/TCP, I suppose the server 
would just throw away the old packet, since the client clearly lost 
interest in it? (retransmissions are forbidden in RADIUS/TCP, so there 
is no need to do deduplication)

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

Attachment: smime.p7s

[radext] Small issues in the ALPN draft Jan-Frederik Rieckers
Re: [radext] Small issues in the ALPN draft Alan DeKok
Re: [radext] Small issues in the ALPN draft Jan-Frederik Rieckers
Re: [radext] Small issues in the ALPN draft Alan DeKok
Re: [radext] Small issues in the ALPN draft Alexander Clouter
Re: [radext] Small issues in the ALPN draft Alan DeKok
Re: [radext] Small issues in the ALPN draft Jan-Frederik Rieckers
Re: [radext] Small issues in the ALPN draft Heikki Vatiainen
Re: [radext] Small issues in the ALPN draft Alan DeKok

Re: [radext] Small issues in the ALPN draft

Attachment: smime.p7s