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

Pad path validation in both directions #4241

Merged
merged 9 commits into from Oct 20, 2020
Merged
4 changes: 2 additions & 2 deletions draft-ietf-quic-transport.md
Expand Up @@ -2218,13 +2218,13 @@ data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. An
endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE
frame unless constrained by congestion control.

A PATH_RESPONSE frame SHOULD be sent on the network path where the
A PATH_RESPONSE frame MUST be sent on the network path where the
PATH_CHALLENGE was received. This ensures that path validation by a peer only
succeeds if the path is functional in both directions. This requirement MUST
NOT be enforced by the endpoint that initiates path validation as that would
enable an attack on migration; see {{off-path-forward}}.

An endpoint SHOULD expand datagrams that contain a PATH_RESPONSE frame to at
An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame to at
least the smallest allowed maximum datagram size of 1200 bytes. This verifies
that the path is able to carry datagrams of this size in both directions.

Expand Down