moq-wg / moq-transport

draft-ietf-moq-transport
Other
79 stars 18 forks source link

Client and/or server initiated handshake #242

Open kixelated opened 1 year ago

kixelated commented 1 year ago

Splitting discussion in #212 into a separate issue.

The current draft states that the client initiates the session via a CLIENT_SETUP message and then server replies with a SERVER_SETUP. The client sends a list of supported versions and its role, while the server chooses a version and reaffirms the role. This is done via a bidirectional stream opened by the client.

However, depending on the underlying transport, the client won't always be the first endpoint allowed to send a flight, so this incurs a half-RTT of latency:

kixelated commented 1 year ago

I think we should emulate HTTP/3 SETTINGS. That means endpoints can send the SETUP in parallel.

SETUP
supported_versions: [ 1, 3, 4, ... ]
supported_roles: "publisher" | "subscriber" | "both" 

As far as I understand, this doesn't support from version negotiation attacks, since it's over an established QUIC connection.

Alternatively, QUIC could use the ALPN to transmit this SETUP information. Unfortunately no such mechanism exists for WebTransport (yet).

fluffy commented 7 months ago

so I am working on the assumption the vast majority of connections, measured by numbers of connection, will be 0-RTT, not 1. I was assuming this because what the MoQ client sends in that would be "SAFE" in the HTTP replay sen. I realize other on this thread have thought about this lots. Any particular reason 0-RTT would not be common in MoQ ?

kixelated commented 7 months ago

so I am working on the assumption the vast majority of connections, measured by numbers of connection, will be 0-RTT, not 1. I was assuming this because what the MoQ client sends in that would be "SAFE" in the HTTP replay sen. I realize other on this thread have thought about this lots. Any particular reason 0-RTT would not be common in MoQ ?

Well, WebTransport does not support 0-RTT. Even if it did, MoQ would be subject to a replay attacks depending on how authentication is performed.

vasilvv commented 7 months ago

Note that in case of WebTransport, the question of 0-RTT is orthogonal to the question of which side speaks first (it just lets you skip a round trip that occurs before the WebTransport session is established).

ianswett commented 6 months ago

We now have a clearer definition of Role, so the 'server' from the perspective of a QUIC connection could initiate a MoQ session with a CLIENT_SETUP message I believe?

I'm going to park this for now unless this is currently causing problems. Currently the control stream is bidi and unidirectional streams are for Objects, so this would be a non-trivial change.

afrind commented 5 months ago

the 'server' from the perspective of a QUIC connection could initiate a MoQ session with a CLIENT_SETUP message

Did we intend to allow this?

martinduke commented 1 month ago

@kixelated: this will require a new version negotiation design, because SERVER_SETUP currently depends on CLIENT_SETUP. So you can progress this issue by (1) closing it, (2) starting a discussion a new design, or (3) filing a PR.

martinduke commented 1 month ago

Reassigning to @ianswett, as the author of the ALPN PR.