Skip to content
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

Increase resilience to spoofed Version Negotiation packets #524

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 21 additions & 7 deletions draft-ietf-quic-transport.md
Original file line number Diff line number Diff line change
Expand Up @@ -927,13 +927,16 @@ If the packet contains a version that is acceptable to the server, the server
proceeds with the handshake ({{handshake}}). This commits the server to the
version that the client selected.

When the client receives a Version Negotiation packet from the server, it should
select an acceptable protocol version. If the server lists an acceptable
version, the client selects that version and reattempts to create a connection
using that version. Though the contents of a packet might not change in
response to version negotiation, a client MUST increase the packet number it
uses on every packet it sends. Packets MUST continue to use long headers and
MUST include the new negotiated protocol version.
A client MUST discard a Version Negotiation packet that does not contain Packet
Number and Version fields that match those fields in a packet that the client
previously sent. This doesn't guarantee that the Version Negotiation packet is
genuine, but it reduces the chances that the packet is spoofed.

A client that receives a valid Version Negotiation packet selects an acceptable
protocol version from those listed by the server. The client then reattempts to
create a connection using that version. Though the contents of a packet might
not change in response to version negotiation, a client MUST choose a new packet
number it uses on every packet it sends.

The client MUST use the long header format and include its selected version on
all packets until it has 1-RTT keys and it has received a packet from the server
Expand Down Expand Up @@ -1230,6 +1233,17 @@ client MUST terminate with a QUIC_VERSION_NEGOTIATION_MISMATCH error code if
version negotiation occurred but it would have selected a different version
based on the value of the supported_versions list.

If the client receives a Version Negotiation packet and these validation checks
subsequently fail, it is possible that the client received a spoofed Version
Negotiation packet. A client MAY attempt to create a new connection and ignore
any Version Negotiation packets that match those that caused the connection to
fail.

Note:

: The version list from the transport parameters is not authenticated until
after the cryptographic handshake is complete.


## Stateless Retries {#stateless-retry}

Expand Down