Re: [radext] Small issues in the ALPN draft

[Alan DeKok <[e-mail]>]

On Mar 20, 2024, at 11:49 AM, Jan-Frederik Rieckers <[e-mail]> wrote:
> 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.

  The issue isn't token re-use.  That's fine.  The issue is sending two different packets with the same Token.

  i.e. where packet 1 is sent with token A, and then *before* a reply comes back, the client sends packet 2 with token B.

> 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.

> 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.

  Once the issues above are clarified, I don't see this as a change to the RADIUS protocol.  We already support ID re-use when the server has sent a reply.  And conflicting IDs are already a problem in RADIUS.  The ALPN document uses Tokens instead of Identifiers, but doesn't change either behavior.

  Alan DeKok.