netdev - Re: [PATCH net-next v2 07/15] quic: add connection id management

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7fd0f513-df05-43f4-b1dc-0fdb74e78378@akamai.com>
Date: Fri, 22 Aug 2025 13:10:33 -0400
From: Jason Baron <jbaron@...mai.com>
To: Xin Long <lucien.xin@...il.com>, network dev <netdev@...r.kernel.org>
CC: <davem@...emloft.net>, <kuba@...nel.org>,
        Eric Dumazet
	<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
        Simon Horman
	<horms@...nel.org>, Stefan Metzmacher <metze@...ba.org>,
        Moritz Buhl
	<mbuhl@...nbsd.org>, Tyler Fanelli <tfanelli@...hat.com>,
        Pengtao He
	<hepengtao@...omi.com>, <linux-cifs@...r.kernel.org>,
        Steve French
	<smfrench@...il.com>,
        Namjae Jeon <linkinjeon@...nel.org>,
        Paulo Alcantara
	<pc@...guebit.com>, Tom Talpey <tom@...pey.com>,
        <kernel-tls-handshake@...ts.linux.dev>,
        Chuck Lever <chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>,
        Benjamin Coddington <bcodding@...hat.com>,
        Steve Dickson <steved@...hat.com>, Hannes Reinecke <hare@...e.de>,
        "Alexander
 Aring" <aahringo@...hat.com>,
        David Howells <dhowells@...hat.com>,
        Cong Wang
	<xiyou.wangcong@...il.com>,
        "D . Wythe" <alibuda@...ux.alibaba.com>,
        illiliti
	<illiliti@...tonmail.com>,
        Sabrina Dubroca <sd@...asysnail.net>,
        "Marcelo
 Ricardo Leitner" <marcelo.leitner@...il.com>,
        Daniel Stenberg
	<daniel@...x.se>,
        Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v2 07/15] quic: add connection id management

Hi Xin,

On 8/18/25 10:04 AM, Xin Long wrote:
> !-------------------------------------------------------------------|
>    This Message Is From an External Sender
>    This message came from outside your organization.
> |-------------------------------------------------------------------!
> 
> This patch introduces 'struct quic_conn_id_set' for managing Connection
> IDs (CIDs), which are represented by 'struct quic_source_conn_id'
> and 'struct quic_dest_conn_id'.
> 
> It provides helpers to add and remove CIDs from the set, and handles
> insertion of source CIDs into the global connection ID hash table
> when necessary.
> 
> - quic_conn_id_add(): Add a new Connection ID to the set, and inserts
>    it to conn_id hash table if it is a source conn_id.
> 
> - quic_conn_id_remove(): Remove connection IDs the set with sequence
>    numbers less than or equal to a number.
> 
> It also adds utilities to look up CIDs by value or sequence number,
> search the global hash table for incoming packets, and check for
> stateless reset tokens among destination CIDs. These functions are
> essential for RX path connection lookup and stateless reset processing.
> 
> - quic_conn_id_find(): Find a Connection ID in the set by seq number.
> 
> - quic_conn_id_lookup(): Lookup a Connection ID from global hash table
>    using the ID value, typically used for socket lookup on the RX path.
> 
> - quic_conn_id_token_exists(): Check if a stateless reset token exists
>    in any dest Connection ID (used during stateless reset processing).
> 
> Signed-off-by: Xin Long <lucien.xin@...il.com>
> ---

Thanks Xin for all your work on this!

For QUIC-LB, where the server endpoint may want to choose a specific 
source CID to enable 'stateless' routing, I don't currently see an API 
to allow that? It appears source CIDs are created with random values and 
while userspace can get/set the indexes of the current ones in use, I 
don't see a way to set specific CID values?

For reference here is a proposal around it -
https://datatracker.ietf.org/doc/draft-ietf-quic-load-balancers/

In the reference above, the source CID is encrypted to help protect 
traceability if the connection migrates. Thus, if the kernel were to 
support such a feature, I don't think it wants to enforce a specific 
encoding scheme, but perhaps it might want to be a privileged operation, 
perhaps requiring CAP_NET_ADMIN to set specific source CIDs.

Thanks,

-Jason