netdev - Re: [PATCH net-next 3/5] net: implement QUIC protocol code in net/quic directory

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CADvbK_c1ibnyFx-u+Vh2FUy7iMMo4jORrSAz2un8tWsYtKmGHg@mail.gmail.com>
Date: Tue, 10 Sep 2024 11:17:33 -0400
From: Xin Long <lucien.xin@...il.com>
To: "D. Wythe" <alibuda@...ux.alibaba.com>
Cc: network dev <netdev@...r.kernel.org>, "David S . Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	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>, 
	Stefan Metzmacher <metze@...ba.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>, Steve Dickson <steved@...hat.com>, Hannes Reinecke <hare@...e.de>, 
	Alexander Aring <aahringo@...hat.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 3/5] net: implement QUIC protocol code in
 net/quic directory

On Mon, Sep 9, 2024 at 11:30 PM D. Wythe <alibuda@...ux.alibaba.com> wrote:
>
>
>
> On 9/10/24 10:30 AM, Xin Long wrote:
> > This commit adds the initial implementation of the QUIC protocol code.
> > The new net/quic directory contains the necessary source files to
> > handle QUIC functionality within the networking subsystem:
> >
> > - protocol.c: module init/exit and family_ops for inet and inet6.
> > - socket.c: definition of functions within the 'quic_prot' struct.
> > - connid.c: management of source and dest connection IDs.
> > - stream.c: bidi/unidirectional stream handling and management.
> > - cong.c: RTT measurement and congestion control mechanisms.
> > - timer.c: definition of essential timers including RTX/PROBE/IDLE/ACK.
> > - packet.c: creation and processing of various of short/long packets.
> > - frame.c: creation and processing of diverse types of frames.
> > - crypto.c: key derivation/update and header/payload de/encryption.
> > - pnspace.c: packet number namespaces and SACK range handling.
> > - input.c: socket lookup and stream/event frames enqueuing to userspace.
> > - output.c: frames enqueuing for send/resend as well as acknowledgment.
> > - path.c: src/dst path management including UDP tunnels and PLPMTUD.
> > - test/unit_test.c: tests for APIs defined in some of the above files.
> > - test/sample_test.c: a sample showcasing usage from the kernel space.
> >
>
> Hi Xin,
>
> I was intended to review your implementation, but I didn't know where to
> start. All your implementations
> are in one patch, making it quite difficult to review, so I gave up. 🙁
Hi,

This is a protocol initial, and it's difficult to split it except that
I already moved these APIs related files, building configuration and
documentation. Honestly I couldn't think of a nice way to split more
that could help much for the review.

But you can try https://github.com/lxin/quic/, where you will get more
information including change history, configurations and all kinds of
tests running etc, although its first commit for the protocol initial
is kinda a big patch.

>
> I think maybe you could consider adding interoperability tests with
> other variants of QUIC implementations.
> When we were working on xquic, this helped us discover many
> implementation issues, and it might be
> beneficial for you as well.
>
> You can check it out from https://interop.seemann.io/.
As you may already see from the cover-letter, the current interoperability
tests we've done are via curl http3 over linux QUIC to connect different
http3 servers that use different QUIC implementations, which are mostly
covering handshakes and some version negotiations.

For the link shared, it does offer more coverage and it's nice to include
it in the future.

Thanks for your comment.