In-kernel QUIC implementation with Userspace handshake | Hacker News Reader

In-kernel QUIC implementation with Userspace handshake

github.com

75 pointswseqyrku7 comments

> Kernel Use like NFS and SMB over QUIC

By the way, are there any living examples of using WebDAW over HTTP/3? I would prefer both client and server parts of my network shares to work in the userspace minimizing involvement of the OS but HTTP3/QUIC sounds great to replace previous versions of HTTP in this use case. I've done some googling but could only find that Windows was going to do SMB over QUIC to replace WebDAV.

That may be the first implementation of SMB that isn’t unusably slow. Every time an IT group gives me an SMB share, I beg them for SFTP access, which usually falls on deaf ears.

Everyone I know have given up using SMB long ago. Techies use SFTP, non-techies use cloud services (including those self-hosted in companies intranets as well as Google Drive and competitors) and apps, some use WebDAV for some cases it suits Ok.

And I have never seen anybody using NFS (despite it seeming quite popular according to its mentions on the web). I looked at it as it sounded interesting but gave up the Idea once I found out it does broadcats - I wanted file servers to be passive and only respond to direct requests.

Regarding Microsoft - they say they are updating SMB to use QUIK for sake of eliminating the need in VPNing access to remote shares thanks to its encrypted nature (as I understood, they previously meant WebDAV to be used instead of SMB for VPNless remote file sharing). Nevertheless I doubt many people are going to find courage for exposing company file servers running Windows directly to open Internet without using a firewall and a VPN.

If you go to a big data center/colo/on premise server room and ask for some space usually the choice is either NFS or iSCSI. On the workstation/end-user area the choice is obviously different/wider.

Maybe I’ve been reading about 0days and spyware too much recently, but this just seems like it’s going to speed run privilege escalation.

Simple wire protocols, including cryptographic ones, are not concerning. They are easy to validate and do not operate on complex inputs, which is why something like Wireguard can exist in the kernel.

The issue is complex super-protocols like TLS, with handshakes, negotiations, numerous operational modes and so forth. Splitting this so the kernel only sees a simple wire protocol - with anything involving complexity and decision-making happening in user-space - removes any concern.

How much faster is this compared to a fully userspace implementation?

Reply on news.ycombinator.com