ktls-utils
ktls-utils copied to clipboard
oracle
tlshd / netlink upcall should support QUICv1
QUICv1 is specified by [RFC 9000] (https://www.rfc-editor.org/rfc/rfc9000.html).
Because a QUICv1 connect transaction makes use of the TLS v1.3 handshake, we believe that in-kernel support for the QUIC transport protocol can and should make use of tlshd and its netlink upcall to perform that handshake on behalf of kernel consumers (such as SMB).
There is an upstream submission including both kernel and userspace:
we should invite the author to collaborate here.
Thanks, Hannes,
As I mentioned in the cover letter, I do have plans to move the QUIC handshake code eventually in here ktls-utils.
Is that okay if I will build it as libquic.so(maybe better) or libtlshd.so in ktls-utils? as I expect QUIC handshake functions also to be used by Userspace consumers with common socket APIs.
Once the Kernel part goes to net-next and the Userspace part comes to ktls-utils, we can drop the current repo: lxin/quic. Users won't need to build any extra/new packages to use this Linux QUIC.
I don't have issues with that, but you'll have to check with Chuck if licensing allows for that.
The best thing to do is propose a pull request and we can see what the particular technical and licensing issues might be.
The shared code (library) would be QUIC-specific, so I might prefer libquic.so, linked with tlshd.
@lxin do you have a time frame for when this code might be available to integrate into ktls-utils? I would like to plan the feature set of the next release -- if it's going to be a while, I'll release 0.11 sooner rather than later.
@chucklever Is that okay if I add libquic.so to ktls-utils without the kernel part integrated into the upstream kernel yet? if yes, I can do it in the next 2 weeks. Otherwise, I expect to post the kernel part to netdev in 2-3 months after I improve the congestion control part.
@chucklever Is that okay if I add libquic.so to ktls-utils without the kernel part integrated into the upstream kernel yet? if yes, I can do it in the next 2 weeks.
If that part has been fairly stable, I think sending a ktls-utils PR before June would be great. My only requirements are that it builds successfully and does not break the existing features.
https://github.com/oracle/ktls-utils/pull/56 is created for this, feel free to check.
I am marking this closed, now that the QUIC PR has been merged. If there are new details to discuss, let's open a fresh issue.