Date: Wed, 13 Mar 2024 12:03:09 -0400
From: Xin Long <lucien.xin@...il.com>
To: Stefan Metzmacher <metze@...ba.org>
Cc: network dev <netdev@...r.kernel.org>, davem@...emloft.net, kuba@...nel.org, 
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Steve French <smfrench@...il.com>, Namjae Jeon <linkinjeon@...nel.org>, 
	Chuck Lever III <chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>, 
	Sabrina Dubroca <sd@...asysnail.net>, Tyler Fanelli <tfanelli@...hat.com>, 
	Pengtao He <hepengtao@...omi.com>, 
	"linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>, 
	Samba Technical <samba-technical@...ts.samba.org>
Subject: Re: [RFC PATCH net-next 0/5] net: In-kernel QUIC implementation with
 Userspace handshake

On Wed, Mar 13, 2024 at 4:56 AM Stefan Metzmacher <metze@...ba.org> wrote:
>
> Hi Xin Long,
>
> first many thanks for working on this topic!
>
Hi, Stefan

Thanks for the comment!

> > Usage
> > =====
> >
> > This implementation supports a mapping of QUIC into sockets APIs. Similar
> > to TCP and SCTP, a typical Server and Client use the following system call
> > sequence to communicate:
> >
> >         Client                    Server
> >      ------------------------------------------------------------------
> >      sockfd = socket(IPPROTO_QUIC)      listenfd = socket(IPPROTO_QUIC)
> >      bind(sockfd)                       bind(listenfd)
> >                                         listen(listenfd)
> >      connect(sockfd)
> >      quic_client_handshake(sockfd)
> >                                         sockfd = accecpt(listenfd)
> >                                         quic_server_handshake(sockfd, cert)
> >
> >      sendmsg(sockfd)                    recvmsg(sockfd)
> >      close(sockfd)                      close(sockfd)
> >                                         close(listenfd)
> >
> > Please note that quic_client_handshake() and quic_server_handshake() functions
> > are currently sourced from libquic in the github lxin/quic repository, and might
> > be integrated into ktls-utils in the future. These functions are responsible for
> > receiving and processing the raw TLS handshake messages until the completion of
> > the handshake process.
>
> I see a problem with this design for the server, as one reason to
> have SMB over QUIC is to use udp port 443 in order to get through
> firewalls. As QUIC has the concept of ALPN it should be possible
> let a conumer only listen on a specif ALPN, so that the smb server
> and web server on "h3" could both accept connections.
We do provide a sockopt to set ALPN before bind or handshaking:

  https://github.com/lxin/quic/wiki/man#quic_sockopt_alpn

But it's used more like to verify if the ALPN set on the server
matches the one received from the client, instead of to find
the correct server.

So you expect (k)smbd server and web server both to listen on UDP
port 443 on the same host, and which APP server accepts the request
from a client depends on ALPN, right?

Currently, in Kernel, this implementation doesn't process any raw TLS
MSG/EXTs but deliver them to userspace after decryption, and the accept
socket is created before processing handshake.

I'm actually curious how userland QUIC handles this, considering
that the UDP sockets('listening' on the same IP:PORT) are used in
two different servers' processes. I think socket lookup with ALPN
has to be done in Kernel Space. Do you know any userland QUIC
implementation for this?

>
> So the server application should have a way to specify the desired
> ALPN before or during the bind() call. I'm not sure if the
> ALPN is available in cleartext before any crypto is needed,
> so if the ALPN is encrypted it might be needed to also register
> a server certificate and key together with the ALPN.
> Because multiple application may not want to share the same key.
On send side, ALPN extension is in raw TLS messages created in userspace
and passed into the kernel and encoded into QUIC crypto frame and then
*encrypted* before sending out.

On recv side, after decryption, the raw TLS messages are decoded from
the QUIC crypto frame and then delivered to userspace, so in userspace
it processes certificate validation and also see cleartext ALPN.

Let me know if I don't make it clear.

>
> This needs to work indepented of kernel or userspace application.
>
> We may want ksmbd (kernel smb server) and apache or smbd (Samba's userspace smb server)
> together with apache. And maybe event ksmbd with one certificate for
> ksmbd.example.com and smbd with a certificate for smbd.example.com
> both on ALPN "smb", while apache uses "h3" with a certificate for
> apache.example.com and nginx with "h3" and a certificate for
> nginx.example.com.
>
> But also smbd with "smb" as well as apache with "h3" both using
> a certificate for quic.example.com.
>
> I guess TLS Server Name Indication also works for QUIC, correct?
Yes, QUIC is secured by TLS 1.3, almost all extensions in TLS1.3
are supported in QUIC.

In userspace I believe we can use gnutls_server_name_set() to
set SNI on client and process SNI on server after getting SNI
via gnutls_server_name_get() in .post_client_hello_cb().

I think this would be able to work out the multiple certificates
(with different hostnames) used by one smbd server.
>
> For the client side I guess dynamic udp ports are used and
> there's no problem with multiple applications...
>
Right.

Thanks again for your comment.

Powered by blists - more mailing lists