fix: process packets from different sources before handshake confirmed #2463
+735
−486
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
camshaft
force-pushed
the
camshaft/cm-handshake-confirmed
branch
from
2d8d0f4 to
7e11553
Compare
maddeleine
reviewed
Jan 31, 2025
maddeleine
approved these changes
Feb 1, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes:
This change fixes an issue where clients may (unknowingly) rebind ports/IPs mid handshake and not be able to complete the handshake due to the server dropping packets with reason
ConnectionMigrationDuringHandshake. This behavior is less than desirable, since clients don't have control over their source IP/port. I also couldn't find any requirements in the RFC that stated that we couldn't process these packets. It only states that we can't initiate the migration flow before the handshake is confirmed.Instead, we will process the packet as if it was received on the active path. Keep in mind that as before, until the handshake is confirmed we won't initiate any
PATH_CHALLENGEframes and we won't create a new paths for the new remote address. But if the client is still able to reach the server and wrap the handshake up then we should try our best to make that happen.This ultimately means that the
ConnectionMigrationDuringHandshakereason will no longer be emitted.Testing:
I updated the connection migration and path manager tests that were asserting this behavior to reflect the new expectation.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.