Skip to content

VPN RPC protocol does not have good support for version negotiation #15601

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
deansheather opened this issue Nov 20, 2024 · 0 comments · Fixed by #15687
Closed

VPN RPC protocol does not have good support for version negotiation #15601

deansheather opened this issue Nov 20, 2024 · 0 comments · Fixed by #15687
Assignees
Labels
networking Area: networking

Comments

@deansheather
Copy link
Member

Currently we're using apiversion.APIVersion as our version type for the VPN RPC code. This code was originally written for client=>server version negotiation where only the server would support multiple versions, and the client would only send it's best version. In the VPN RPC protocol though, we would conceivably have situations where either side could be newer and so both sides should be able to negotiate the best version.

Proposal

Change our codervpn header/handshake format from codervpn <version> <role_enum> to codervpn <role_enum> <versions...>.

The sent versions in the header would be each major version and the maximum supported minor version on that major version. E.g. codervpn manager 1.3 2.2 3.0 means: 1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 3.0 are supported by this peer.

Once each end of the connection receives it's peer's handshake, it will compare the versions against each other to determine the highest mutual version. E.g. with codervpn peer1 1.3 2.2 3.0 and codervpn peer2 1.3 2.1 the version used will be 2.1. If the peers decide that no version is shared, they should log/notify the user and close the connection.

We will most likely need a new type to store these API versions and compare them. Maybe it should go in the apiversion package but we rename the old type and give this type a different name.

The validation method should have a signature like so, returning the best major/minor combination or an error if the two peers are not compatible.

func (v Version) NegotiateVersion(peer Version) (int major, int minor, err error) {}
@coder-labeler coder-labeler bot added the networking Area: networking label Nov 20, 2024
deansheather added a commit that referenced this issue Dec 4, 2024
Changes the RPC header format from `codervpn <version> <role>` to
`codervpn <role> <version1,version2,...>`.

The versions list is a list of the maximum supported minor version for
each major version, sorted by major versions.

E.g. `1.0,2.3,3.1` means `1.0, 2.0, 2.1, 2.2, 2.3, 3.0, 3.1` are
supported.

When we eventually support multiple versions, the peer's version list
will be compared against the current supported versions list to
determine the maximum major and minor version supported by both peers.

Closes #15601
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
networking Area: networking
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant