Use msquic with SSH: howto start a connection from another?

[stefbon]

Hi,

I would like to try msquic with SSH. I've got my own SSH implementation

see:

https://github.com/stefbon/OSNS

and have a client (osns_client) and working on ssh server (osns_ssh_server) and sftp subsystem (osns_sftp_subsystem).
Now within SSH if you want to enable setting up of an extra connection over UDP for datatransfer, you need an extension:

https://tools.ietf.org/html/rfc8308

Now in short: if the extensionmechanism is enabled on client and server, you need an extension to setup a data connection like:

a. client requests setup extra connection over udp with quic.
b server responds with quic versions supported
c client accepts one of the versions
d server sends a port/address to connect to and a timeout: after that the port is closed

Do you have examples with other protocols like HTTP(s) ? For inspiration and to prevent inventing the wheel.

Thanks in advance,

Stef Bon

PS earlier I've posted this on the /proto-quic group, but no response for some weeks now. So I'll try it here, maybe you know something.

[nibanks]

I'm unclear on exactly what the ask is? Can you break it down to simple, explicit asks for MsQuic? Are you just looking for examples or what?

[stefbon]

Is it just me or are you just always this direct and a bit blunt?

The question is how to start a data channel from another one. With webtraffic where the quic protocol is designed for in the first place, the main connection is the normal tcpip connection on 80/443. So after the client (webbrowser) and the server have established this connection, they (initiated probably by the client) want to setup an extra connection using quic.
My question is now: how is this done? Are there RFC's describing this? Or Drafts? That is what I want to know. To prevent reinventing the wheel and for inspiration for making this work with SSH.
Not so hard though?
Thanks any way,

Stef Bon

[nibanks]

I definitely apologize if I came off negatively. That was not my intention. I truly just didn't understand the question enough to answer it.

So, it sounds like you just generally trying to understand how to use QUIC at a protocol layer? For HTTP, the client first connects with TCP (HTTP/2 or HTTP/1.1 possibly). Then HTTP sends a message where it advertises support for HTTP/3 (QUIC) with the necessary information on how to connect (hostname/IP and port). Then the client starts the HTTP/3 connection attempt. If it works, then the client drops the TCP connection and continues with the QUIC one. It also remembers this information to reuse for future attempts.

For your own protocol, you may do the same thing, or you could just try to always race both QUIC and TCP connections in parallel.

Does this answer your question?

[stefbon]

Hi,

apologies accepted! Well you write in your second post you did not understand my question anough to answer that. My advice: write that to me, and you find me helping it understand. Communicating about how questions come to you with the questioner is very important, and helps both in coming to a sollution.

So thanks for your information. I understand that somewhere in the HTTP headers information is stored about higher versions of the protocol, and that the default is to switch over to this version (including the connection) if both client and server support it.
This is not the way to go I think for SSH. SSH knows two types of messages for data, I do not have an aurgument pro or contra yet. I'll discuss this the coming months on the openssh dev list and send the creator of SSH Ylonen a copy.

You describe the way it goes, but is there an RFC for that? I'm interested in the bits. I have to know how this process goes on bit niveau.

Thanks in advance,

Stef Bon

[nibanks]

The HTTP/3 spec does describe how Alt-Svc (i.e. alternative service) is used to negotiate upgrade to HTTP/3.