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 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 6 additions & 6 deletions draft-ietf-quic-transport.md
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.

A successful response to a PATH_CHALLENGE frame sent in a datagram that was not
expanded to at least 1200 bytes validates the peer address, but it does not
validate the path MTU. 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