DO NOT MERGE! DIVERGENCE FROM STANDARD FOR DITTO USAGE ONLY#1
Draft
Pierre Avital (p-avital) wants to merge 1 commit intomainfrom
Draft
DO NOT MERGE! DIVERGENCE FROM STANDARD FOR DITTO USAGE ONLY#1Pierre Avital (p-avital) wants to merge 1 commit intomainfrom
Pierre Avital (p-avital) wants to merge 1 commit intomainfrom
Conversation
# How to handle this commit? - This commit is intended to be used by Ditto as its `quinn-proto` vendored dependency. - This commit SHOULD NOT be merged in `main`, but stay in a separate branch, which should be rebased on `main@upstream` regularly. # Why does this commit exist? The QUIC standard imposes that packets originating from an unvalidated path be discarded (unless they are specifically probing packets in response to a `PATH_CHALLENGE`, which can only be started once the handshake is completed). This conflicts heavily with our usage in Ditto, where we perform "implicit server address migration" as a way for peers to discover each other's link-local address for unicast links. This implicit migration is performed by allowing the client to address the server through an arbitrary "jumpstart" address; the server then responds, continuing the handshake, using its actual link-local IPv6 as the `src_ip` for its datagrams. From that point onwards, packets from the client will target this newly learnt IP. This is no less secure than discarding packets based on source IP, as spoofing that IP is trivial; the security being instead provided by cryptography that doesn't take IP headers into account. Note that this implicit migration is not implemented here, but is _enabled_ by this commit. The implicit migration is performed by keeping track of a packet's source IP, and setting it as the peer's new IP from the moment the packet has been validated cryptographically; typically by observing that `quinn-proto` raised an event pertaining to it.
This file contains hidden or 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
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.
How to handle this commit?
quinn-protovendored dependency.main, but stay in a separate branch, which should be rebased onmain@upstreamregularly.Why does this commit exist?
The QUIC standard imposes that packets originating from an unvalidated path be discarded (unless they are specifically probing packets in response to a
PATH_CHALLENGE, which can only be started once the handshake is completed).This conflicts heavily with our usage in Ditto, where we perform "implicit server address migration" as a way for peers to discover each other's link-local address for unicast links.
This implicit migration is performed by allowing the client to address the server through an arbitrary "jumpstart" address; the server then responds, continuing the handshake, using its actual link-local IPv6 as the
src_ipfor its datagrams. From that point onwards, packets from the client will target this newly learnt IP.This is no less secure than discarding packets based on source IP, as spoofing that IP is trivial; the security being instead provided by cryptography that doesn't take IP headers into account.
Note that this implicit migration is not implemented here, but is enabled by this commit.
The implicit migration is performed by keeping track of a packet's source IP, and setting it as the peer's new IP from the moment the packet has been validated cryptographically; typically by observing that
quinn-protoraised an event pertaining to it.