Re: [radext] Small issues in the ALPN draft

[Alexander Clouter <[e-mail]>]

Hello,

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.

This lets the client to continue to use a random value, but the time element guarantees that there is no reuse within a window; similar to UUID version 1 and 2.  We would need to recommend that this timestamp representation support at least N seconds (~60s+) of modulo window so the client can be sure the server definitely has abandoned the old request.

I think this is okay as already the document suggests strategies for token generation (random or counter). In the case of where an implementer decides:

 * "you picked 'random' as a generation method"
 "you wish not to remember N minutes of token IDs"

Here we can describe this problem and recommend this as a way to solve it.

On this note, may be helpful to the server to know it was a retry so maybe at some stage we assign N bits in the header as a counter for the client to use to communicate how many retries it has done.

Cheers