Re: [radext] Small issues in the ALPN draft

[Heikki Vatiainen <[e-mail]>]

On Wed, 20 Mar 2024 at 14:38, Alexander Clouter <[e-mail]>
wrote:


> On Wed, 20 Mar 2024, at 03:53, Jan-Frederik Rieckers wrote:
> > 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.
>
> One way to solve this is retain that from the server perspective the token
> is 100% opaque but suggest that client implementations split the token as
> [token|epoch] where this 'epoch' is some local timestamp representation
> (meaningful only to the client) of when the initial request was sent.
>

Here's an example from another AAA protocol, see End-to-End Identifier
definition:
https://datatracker.ietf.org/doc/html/rfc6733#section-3

In any case, I support mandating a counter on the client side. For the
server it's mandated to be opaque.

This would be good for debugging (easy to see the order of messages) and
should not be hard to implement because the counter would exist as a
property of a connection. When the connection is closed, the counter and
its history no longer exists.

The starting value could be random, or perhaps the 12bits construct
End-to-End identifier uses. I'd say this may be a bit fancy since the
counter in question is not used for end-to-end purposes over multiple hops.

-- 
Heikki Vatiainen
[e-mail]