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

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] [day] [month] [year] [list]

Message-ID: <CADvbK_f4v916nbx4t0fnkCj44S-buTytj_Paurd3j3Ro2tLDsQ@mail.gmail.com>
Date: Sun, 24 Aug 2025 13:57:48 -0400
From: Xin Long <lucien.xin@...il.com>
To: John Ericson <mail@...nericson.me>
Cc: network dev <netdev@...r.kernel.org>, draft-lxin-quic-socket-apis@...f.org
Subject: Re: [PATCH net-next v2 00/15] net: introduce QUIC infrastructure and
 core subcomponents

On Sat, Aug 23, 2025 at 11:21 AM John Ericson <mail@...nericson.me> wrote:
>
> (Note: This is an interface more than implementation question --- apologies in advanced if this is not the right place to ask. I originally sent this message to [0] about the IETF internet draft [1], but then I realized that is just an alias for the draft authors, and not a public mailing list, so I figured this would be better in order to have something in the public record.)
>
> ---
>
> I was surprised to see that (if I understand correctly) in the current design, all communication over one connection must happen with the same socket, and instead stream ids are the sole mechanism to distinguish between different streams (e.g. for sending and receiving).
>
> This does work, but it is bad for application programming which wants to take advantage of separate streams while being transport-agnostic. For example, it would be very nice to run an arbitrary program with stdout and stderr hooked up to separate QUIC streams. This can be elegantly accomplished if there is an option to create a fresh socket / file descriptor which is just associated with a single stream. Then "regular" send/rescv, or even read/write, can be used with multiple streams.
>
> I see that the SCTP socket interface has sctp_peeloff [2] for this purpose. Could something similar be included in this specification?
Hi, John,

That is a bit different. In SCTP, sctp_peeloff() detaches an
association/connection from a one-to-many socket and returns it as a
new socket. It does not peel off a stream. Stream send/receive
operations in SCTP are actually quite similar to how QUIC handles
streams in the proposed QUIC socket API.

For QUIC, supporting 'stream peeloff' might mean creating a new socket
type that carries a stream ID and maps its sendmsg/recvmsg to the
'parent' QUIC socket. But there are details to sort out, like whether
the 'parent-child relationship' should be maintained. We also need to
consider whether this is worth implementing in the kernel, or if a
similar API could be provided in libquic.

I’ll be requesting a mailing list for QUIC development and new
interfaces, and this would be a good topic to continue there.

Thanks for your comment.