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: <CADvbK_dwH2WXWZFym5R2wbjBW0qkoLyxip+uRT751ELGqk0rog@mail.gmail.com>
Date: Sat, 23 Aug 2025 12:15:53 -0400
From: Xin Long <lucien.xin@...il.com>
To: Jason Baron <jbaron@...mai.com>
Cc: network dev <netdev@...r.kernel.org>, 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

On Fri, Aug 22, 2025 at 1:11 PM Jason Baron <jbaron@...mai.com> wrote:
>
> 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.
>
Hi, Jason,

We currently support only the finalized QUIC RFCs. Drafts like
'Load Balancers' and 'Multipath' aren’t covered yet. I think
we will plan the APIs after they are standardized.

Thanks for pointing out this RFC.