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

Reword unpadded PATH_CHALLENGE language #4580

Merged
merged 4 commits into from
Jan 7, 2021
Merged
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
12 changes: 6 additions & 6 deletions draft-ietf-quic-transport.md
Original file line number Diff line number Diff line change
Expand Up @@ -2301,12 +2301,12 @@ the data that was sent in a previous PATH_CHALLENGE frame. A PATH_RESPONSE
frame received on any network path validates the path on which the
PATH_CHALLENGE was sent.

If the PATH_CHALLENGE frame that resulted in successful path validation was sent
in a datagram that was not expanded to at least 1200 bytes, the endpoint can
regard the address as valid. The endpoint is then able to send more than three
times the amount of data that has been received. However, the endpoint MUST
initiate another path validation with an expanded datagram to verify that the
path supports required MTU.
If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not expanded
to at least 1200 bytes, and if the response to it validates the peer address,
the path is validated but not the path MTU. As a result, the endpoint can now
send more than three times the amount of data that has been received. However,
the endpoint MUST initiate another path validation with an expanded datagram to
verify that the path supports the required MTU.

Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is
not adequate validation, since the acknowledgment can be spoofed by a malicious
Expand Down