Summary

  • The November MoQ relay DoS draft adds a concrete threat: a misbehaving relay can send many clients a GOAWAY naming a third-party host. Their connection attempts arrive together, even if the host runs no MoQT service.
  • The MoQT transport draft says a client receiving a server's control-stream GOAWAY must use its non-empty New Session URI for the new session. The protocol field names a destination; the threat draft asks how the client knows that destination has authority to receive the move.

Picture a relay with a large audience. It is allowed to end a session gracefully and give clients a new URI. That is useful for migration, until the relay chooses someone else's server. One GOAWAY per connected client can turn the relay's subscribers into a burst of connection attempts aimed at a host that never offered to serve them. The new paragraph in revision 02 explicitly says the victim need not implement MoQT. The host still receives the attempts; it cannot stop clients from making them before they arrive.

The mechanics are sharply bounded, which makes the missing authority rule sharper. Section 9.2 of the working-group transport draft allows a server's control-stream GOAWAY to carry a New Session URI. If the URI is non-empty, the client MUST use it for a new session. A client cannot send a non-empty destination URI back to a server; that is a role violation. The URI is capped at 8,192 bytes, and a peer cannot keep sending GOAWAY on the same control stream. None of those limits asks whether the named host belongs to the service being migrated. A request-stream GOAWAY has a different rule: the requester SHOULD re-issue that particular request at the specified URI. The mass-audience scenario in the threat draft concerns the server directing connected clients.

The July revision 01 lacked the third-party GOAWAY paragraph. The November text therefore supplies a new, specific risk rather than a generic reminder that relays use resources. Its proposed remedy is equally specific: clients need some assurance that a new URI is authoritative before following it. The threat draft leaves that rule to the transport specification. TLS may reject an unsuitable endpoint later in the attempt; the connection burst has already reached the named host. No incident or measured overload is reported in these official files. The IETF tracker still identifies the threat document as an individual draft.

The decision for a relay operator and client implementer is whether an established session gives the relay a blank cheque to redirect the audience. A migration trace should record the original relay, the new URI, the rule that admitted that URI, the number and timing of attempts and the receiving host's load. Without that sequence, “migration succeeded” may be a tidy label for a third party's unexpected traffic bill.