Re: [radext] Small issues in the ALPN draft

[Jan-Frederik Rieckers <[e-mail]>]

On 19.03.24 08:39, Alan DeKok wrote:
>> Section 4.2.1:
>> Typo: "For An implementation" -> "For an implementation"
> 
>    I can't see that.

3rd paragraph, 3rd sentence.

>> After having read the document again, I'm also not exactly clear about the reasoning behind the 3rd paragraph (closing a connection that re-uses token values).
>> Having a rationale behind this specification would be good.
> 
>    Updated:
> 
>    ...  If it determines that the sender is re-using Token values for distinct outstanding packets, then an error should be logged, and the connection MUST be closed.  There is no way to negotiate correct behavior in the protocol.  Either the parties both operate normally and can communicate, or one end misbehaves, and no communication is possible.
> 
> 
>    The idea is that you can't negotiate your way out of protocol violations.  If a server receives two packets at the same time, with the same Token but different packet contents, then the client is broken.  There's no way to say "please follow the spec".

Ok, after reading the draft again it gets a bit more clear, but I 
believe I found a different problem with that.

My problem with that was at the time of reading, that immediately after 
the "If your peer re-uses a token, then cut him out" came the "remember 
the responses for at least 5 seconds", so the "distinct outstanding 
packets" wasn't as clear.

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.

In RFC 5080, if a server sees a duplicate, it silently discards it.
So this behavior would be a significant change in the RADIUS protocol, 
as far as I see it.

Cheers,
Janfred

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

E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
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