Bug 3471

Summary:	Support for SSH over QUIC.
Product:	Portable OpenSSH	Reporter:	for_bugzilla.mindrot.org_2022-09-08
Component:	Miscellaneous	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	NEW ---
Severity:	enhancement	CC:	dtucker
Priority:	P5
Version:	-current
Hardware:	Other
OS:	All

Description for_bugzilla.mindrot.org_2022-09-08 2022-09-08 12:46:41 AEST

QUIC is described in a series of RFCs, starting from RFC 9000 https://datatracker.ietf.org/doc/html/rfc9000

In short, this is a protocol aiming at providing reliable delivery over UDP, with flow and delivery control implemented at the level above the level 4 transport protocol. In addition, QUIC also supports tunneling unreliable datagrams using he DATAGRAM extension.

QUIC is encrypted by default, using a variation of TLS 1.3, but there is an RFC draft extending QUIC with the SSH key exchange protocol: https://datatracker.ietf.org/doc/html/draft-bider-ssh-quic-09

I would like the OpenSSH developers to consider implementing support for SSH over QUIC.

Why I personally need this?

I have two use-cases which seriously need support for QUIC.

1. I have several machines which are connected to the Internet by _really_ horrible links. Think packet loss 80%. This makes TCP almost unusable, however, if using UDP, there is a way to work around this by using Forward Error-Correcting codes (redundancy coding). In principle, it is possible to implement FEC as a layer below TCP, but this is a huge pain, requires having a VPN link, or something like ip-fue, requires configuration on both sides of the link. With a protocol that is "just UDP", working with lossy channels is much easier.

2. Having a "true" UDP link would allow the -R option to support UDP natively. This would allow forwarding UDP sockets natively, again, without any kind of TCP encapsulation, tcp-over-tcp meltdown, 60k pings, and such. Again, port forwarding is often used to debug HTTP websites, which are increasingly required to support QUIC. This would also greatly simplify exposure of services from behind a NAT.

3. The third use case (which I personally do not use, but which could be useful for a lot of people) is the ssh's -w VPN option. Again, at the moment it is suffering from the tcp-over-tcp meltdown, and in general, TCP VPNs are not as good as UDP VPNs. Native UDP support could substantially improve the lives of people who have to use ssh-vpn.

Admittedly, QUIC is hard to implement. All the RFCs combined which describe QUIC as of 2022, amount to more than 300 pages. But I would still dare to ask for the support to be implemented, because the benefits are just too seductive to ignore.

If I can help somehow, I would try to, but I am not a network programmer by job, I am a physicist who happens to have equipment in remote areas.

Comment 1 Darren Tucker 2022-09-08 13:35:08 AEST

It's very unlikely OpenSSH would support QUIC directly.

That said, if there was a suitable TCP to QUIC proxy client and server available, it should be possible to have the server portion forward to localhost:22 and invoke the client using ssh's ProxyCommand.

Note that since SSH protocol is strictly in-order (out least our implementation, I'm not sure if it's even theoretically possible to do otherwise), this isn't going to help with ssh -w tunneling since it's still going to be subject to TCP-on-TCP exponential retries during packet loss.)