STANDARD.md: connect token lifecycle states and the mandatory restart rule - #183
Merged
Conversation
A connect token history entry now carries a state. It is created pending when the server accepts a connection request for a token it has not seen, and becomes consumed when the server accepts the connection response and installs the client. A pending entry admits a retransmitted connection request from the same address, so a handshake that loses a packet still completes. A consumed entry admits nothing, whatever the source address, so the keys a connect token carries encrypt exactly one session. Entries live until their connect token expires. A history whose entries all hold unexpired tokens refuses a new connect token instead of evicting one, and an entry's time is set at creation and never refreshed. The restart rule is mandatory: the server is configured with the maximum connect token lifetime its deployment issues, and ignores any connection request whose connect token expire timestamp minus that lifetime is earlier than the server start time. Persisting the history stays optional, and is meaningful only together with the consumed state. Nothing on the wire moves and the protocol version stays NETCODE 1.02. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The spec half of the connect token lifecycle work. STANDARD.md only, no code and no wire change: the protocol version stays NETCODE 1.02 and no packet layout moves.
Connect token history
A new Connect Token History section states the rules that were previously spread across one line of the connection request steps:
The connection request steps now defer to that section, and the connection response steps mark the entry consumed.
Server restarts
Rejecting connect tokens that could have been issued before the server started is now mandatory: the server is configured with the maximum connect token lifetime its deployment issues, and ignores any connection request whose connect token expire timestamp minus that lifetime is earlier than the server start time. It needs no persistent state and no data beyond the expire timestamp already in the connection request packet.
Persisting the connect token history stays optional, and the section now says it is meaningful only together with the consumed state, since a restored entry is only useful if it refuses the address that used the token as well as every other address.
The implementation of all of this in netcode.c follows in a second PR on top of this one.
🤖 Generated with Claude Code