Hi fellow QUIC enthusiast, RFC 9000 states:
> Path validation can be used at any time by either endpoint. - https://www.rfc-editor.org/rfc/rfc9000.html#section-8.2-4 and > This document limits migration of connections to new client > addresses, except as described in Section 9.6. Clients are > responsible for initiating all migrations. Servers do not send non- > probing packets (see Section 9.1) toward a client address until they > see a non-probing packet from that address. If a client receives > packets from an unknown server address, the client MUST discard these > packets. - https://www.rfc-editor.org/rfc/rfc9000.html#section-9-6 I understand the reasons to limit connection migration solely to clients (glare, migration and rebinding attacks). But why limit path initiation to clients? Specifically, why is the following sentence not sufficient? > If a client receives **non-probing** packets from an unknown server address, > the client MUST discard these packets. The MUST comes from this PR: https://github.com/quicwg/base-drafts/pull/2031. The motivation is to limit connection migration to clients (which I agree with), but it doesn't explain why path probing/initiation is only done by clients. I'm hoping someone here could provide more context. I also notice a similar constraint with the Multipath Extension for QUIC: > Note that in this extension, a QUIC server does not initiate the creation of a > path, but it has to validate a new path created by a client. - https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-20#section-1-6 Looking through the git history, the sentence was introduced in `fe326a26` as part of an overview, and the corresponding text specifying clients initiating the path is present since the first substantive commit. Possibly this was just to be in line with RFC 9000, but I'd be grateful if anyone could provide more context here as well. If the argument against server initiated paths is to protect against migration and rebinding attacks, a on-path attacker would only be able to successfully redirect non-probing packets which could be tricky to identify. They wouldn't be able to force a migration, a client would still need to choose to migrate. I ask this because I'm working on the latest draft for Alternative Server Address Frames (formerly New Preferred Address), and it may be useful if servers could initiate paths as well. After initiating and validating a path, the server would still need the client's cooperation to do the connection migration. If the client is behind a NAT, it is less likely that the server will be able to initiate a path to the client of course, but there are deployments where not all clients are behind NATs. A couple of months ago, someone brought a similar use case to the QUIC slack chat. I'll start a separate thread for discussions on the Alternative Server Address frames. In this thread I hope to learn: - Why is path initiation not symmetric in RFC 9000? - Why is path initiation not symmetric in the Multipath Extension for QUIC? - Are there any security concerns about allowing servers to initiate paths? Thanks, -Marco
