Re: [PATCH net-next 00/15] net: introduce QUIC infrastructure and core subcomponents

[David Howells <dhowells@redhat.com>]

Xin Long <lucien.xin@gmail.com> wrote:

> Introduction
> ============
> 
> The QUIC protocol, as defined in RFC9000, offers a UDP-based, secure
> transport with flow-controlled streams for efficient communication,
> low-latency connection setup, and network path migration, ensuring
> confidentiality, integrity, and availability across various deployments.
> 
> This implementation introduces QUIC support in Linux Kernel, offering
> several key advantages:
> 
> - Seamless Integration for Kernel Subsystems: Kernel subsystems such as
>   SMB and NFS can operate over QUIC seamlessly after the handshake,
>   leveraging the net/handshake APIs.
> 
> - Standardized Socket APIs for QUIC: This implementation standardizes the
>   socket APIs for QUIC, covering essential operations like listen, accept,
>   connect, sendmsg, recvmsg, close, get/setsockopt, and getsock/peername().
> 
> - Efficient ALPN Routing: It incorporates ALPN routing within the kernel,
>   efficiently directing incoming requests to the appropriate applications
>   across different processes based on ALPN.
> 
> - Performance Enhancements: By minimizing data duplication through
>   zero-copy techniques such as sendfile(), and paving the way for crypto
>   offloading in NICs, this implementation enhances performance and prepares
>   for future optimizations.
> 
> This implementation offers fundamental support for the following RFCs:
> 
> - RFC9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
> - RFC9001 - Using TLS to Secure QUIC
> - RFC9002 - QUIC Loss Detection and Congestion Control
> - RFC9221 - An Unreliable Datagram Extension to QUIC
> - RFC9287 - Greasing the QUIC Bit
> - RFC9368 - Compatible Version Negotiation for QUIC
> - RFC9369 - QUIC Version 2
> 
> The socket APIs for QUIC follow the RFC draft [1]:
> 
> - The Sockets API Extensions for In-kernel QUIC Implementations
> 
> Implementation
> ==============
> 
> The core idea is to implement QUIC within the kernel, using a userspace
> handshake approach.
> 
> Only the processing and creation of raw TLS Handshake Messages are handled
> in userspace, facilitated by a TLS library like GnuTLS. These messages are
> exchanged between kernel and userspace via sendmsg() and recvmsg(), with
> cryptographic details conveyed through control messages (cmsg).
> 
> The entire QUIC protocol, aside from the TLS Handshake Messages processing
> and creation, is managed within the kernel. Rather than using a Upper Layer
> Protocol (ULP) layer, this implementation establishes a socket of type
> IPPROTO_QUIC (similar to IPPROTO_MPTCP), operating over UDP tunnels.
> 
> For kernel consumers, they can initiate a handshake request from the kernel
> to userspace using the existing net/handshake netlink. The userspace
> component, such as tlshd service [2], then manages the processing
> of the QUIC handshake request.
> 
> - Handshake Architecture:
> 
>   ┌──────┐  ┌──────┐
>   │ APP1 │  │ APP2 │ ...
>   └──────┘  └──────┘
>   ┌──────────────────────────────────────────┐
>   │     {quic_client/server_handshake()}     │<─────────────┐
>   └──────────────────────────────────────────┘       ┌─────────────┐
>    {send/recvmsg()}      {set/getsockopt()}          │    tlshd    │
>    [CMSG handshake_info] [SOCKOPT_CRYPTO_SECRET]     └─────────────┘
>                          [SOCKOPT_TRANSPORT_PARAM_EXT]    │   ^
>                 │ ^                  │ ^                  │   │
>   Userspace     │ │                  │ │                  │   │
>   ──────────────│─│──────────────────│─│──────────────────│───│───────
>   Kernel        │ │                  │ │                  │   │
>                 v │                  v │                  v   │
>   ┌──────────────────┬───────────────────────┐       ┌─────────────┐
>   │ protocol, timer, │ socket (IPPROTO_QUIC) │<──┐   │ handshake   │
>   │                  ├───────────────────────┤   │   │netlink APIs │
>   │ common, family,  │ outqueue  |  inqueue  │   │   └─────────────┘
>   │                  ├───────────────────────┤   │      │       │
>   │ stream, connid,  │         frame         │   │   ┌─────┐ ┌─────┐
>   │                  ├───────────────────────┤   │   │     │ │     │
>   │ path, pnspace,   │         packet        │   │───│ SMB │ │ NFS │...
>   │                  ├───────────────────────┤   │   │     │ │     │
>   │ cong, crypto     │       UDP tunnels     │   │   └─────┘ └─────┘
>   └──────────────────┴───────────────────────┘   └──────┴───────┘
> 
> - User Data Architecture:
> 
>   ┌──────┐  ┌──────┐
>   │ APP1 │  │ APP2 │ ...
>   └──────┘  └──────┘
>    {send/recvmsg()}   {set/getsockopt()}              {recvmsg()}
>    [CMSG stream_info] [SOCKOPT_KEY_UPDATE]            [EVENT conn update]
>                       [SOCKOPT_CONNECTION_MIGRATION]  [EVENT stream update]
>                       [SOCKOPT_STREAM_OPEN/RESET/STOP]
>                 │ ^               │ ^                     ^
>   Userspace     │ │               │ │                     │
>   ──────────────│─│───────────────│─│─────────────────────│───────────
>   Kernel        │ │               │ │                     │
>                 v │               v │  ┌──────────────────┘
>   ┌──────────────────┬───────────────────────┐
>   │ protocol, timer, │ socket (IPPROTO_QUIC) │<──┐{kernel_send/recvmsg()}
>   │                  ├───────────────────────┤   │{kernel_set/getsockopt()}
>   │ common, family,  │ outqueue  |  inqueue  │   │{kernel_recvmsg()}
>   │                  ├───────────────────────┤   │
>   │ stream, connid,  │         frame         │   │   ┌─────┐ ┌─────┐
>   │                  ├───────────────────────┤   │   │     │ │     │
>   │ path, pnspace,   │         packet        │   │───│ SMB │ │ NFS │...
>   │                  ├───────────────────────┤   │   │     │ │     │
>   │ cong, crypto     │       UDP tunnels     │   │   └─────┘ └─────┘
>   └──────────────────┴───────────────────────┘   └──────┴───────┘
> 
> Interface
> =========
> 
> 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 [3]. These functions are
> responsible for receiving and processing the raw TLS handshake messages
> until the completion of the handshake process.
> 
> For utilization by kernel consumers, it is essential to have tlshd
> service [2] installed and running in userspace. This service receives
> and manages kernel handshake requests for kernel sockets. In the kernel,
> the APIs closely resemble those used in userspace:
> 
>     Client                             Server
>   ────────────────────────────────────────────────────────────────────────
>   __sock_create(IPPROTO_QUIC, &sock)  __sock_create(IPPROTO_QUIC, &sock)
>   kernel_bind(sock)                   kernel_bind(sock)
>                                       kernel_listen(sock)
>   kernel_connect(sock)
>   tls_client_hello_x509(args:{sock})
>                                       kernel_accept(sock, &newsock)
>                                       tls_server_hello_x509(args:{newsock})
> 
>   kernel_sendmsg(sock)                kernel_recvmsg(newsock)
>   sock_release(sock)                  sock_release(newsock)
>                                       sock_release(sock)
> 
> Please be aware that tls_client_hello_x509() and tls_server_hello_x509()
> are APIs from net/handshake/. They are used to dispatch the handshake
> request to the userspace tlshd service and subsequently block until the
> handshake process is completed.

Can you please put this (or something like this) into Documentation/
somewhere?

Thanks,
David