[Bug 3471] New: Support for SSH over QUIC.

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3471

            Bug ID: 3471
           Summary: Support for SSH over QUIC.
           Product: Portable OpenSSH
           Version: -current
          Hardware: Other
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: for_bugzilla.mindrot.org_2022-09-08 at lockywolf.net

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.