QUIC is now RFC 9000 • Hacker News Board

Re: QUIC is now RFC 9000

#221

Post by touisteur » Sat, May 29, 2021, 12:06 PM UTC

Orphis wrote: post #140

touisteur wrote: post #91

Earlier quoted context omitted.

Sctp over UDP is a thing and still hasn't gained much general public use over the net... Sadly!

SCTP over DTLS over ICE over UDP is used quite a lot though! That's how DataChannels in WebRTC were specified a while ago, and it's the only mechanism to do browser to browser communication.

Oh yes, when I discovered SCTP I felt so sad for all time I and hundred others had implemented part of its featureset over the last 30 years... I mean, it was packed with great features like separate streams, packet-based, multi-homing and multipath. It felt so right playing with it. Alas, even in my company I failed to convince it was a great replacement for layers upon layers of working udp code. I think it came too late...

Re: QUIC is now RFC 9000

#222

Post by zamadatix » Sat, May 29, 2021, 2:25 PM UTC

cbsmith wrote: post #215

zamadatix wrote: post #211

Earlier quoted context omitted.

If it's legitimate security it should've done via an explicit proxy not an attempt to break into every conversation and hope it works right 5 years from now.

Yeah, it's that kind of lack of understanding & consideration of the context that got us in to this mess.

I deploy these kinds of network security solutions to large enterprises as part of my job (typically healthcare customers, from a network MSP/MSSP VAR perspective these days) and as much as I like being paid to continually "fix" broken implicit systems it's not the way to go and never should have been. Either you control the systems or you don't, if you don't fully control you're going to fail at reliably breaking into the conversations to a meaningful level and you probably shouldn't have such critical information on systems you don't control anyways. That or you're trying to control/inspect someone else's system which is exactly what these things are trying to prevent.

Re: QUIC is now RFC 9000

#223

Post by throwawaaarrgh » Sat, May 29, 2021, 5:23 PM UTC

throw0101a wrote: post #206

throwawaaarrgh wrote: post #197

Earlier quoted context omitted.

The fact that a kid with a port scanner can't remotely connect to and exploit your printer is due to NAT not being able to route the traffic, whether you have a stateful firewall or not. The majority of internet-addressable devices in the world do not have firewalls. Hence, NAT keeps most devices safe from drive-by RCE. There are plenty of attacks to get around that, but by default , nothing else protects random devi…

> The majority of internet-addressable devices in the world do not have firewalls. Hence, NAT keeps most devices safe from drive-by RCE. According to System Preferences, my Mac's firewall is currently turned off. Here are the current non-NATed IPv6 addresses on it: $ ifconfig en1 | grep inet6 | grep -v fe80 inet6 2607:f2c0:93c7:fe00:144f:b9a3:bcd4:ef6 prefixlen 64 autoconf secured inet6 2607:f2c0:93c7:fe00:e04c:f356:…

Well first, IPv6 doesn't need NAT, and mostly never uses NAT. If IPv6 devices used NAT, they would be protected. But since they aren't using NAT, they aren't protected. You're right that devices that enable IPv6 (and network routers that give out IPv6 addresses) are not protected by NAT, but luckily it's still a small amount of traffic/devices worldwide. But this is changing, and so NAT won't help people for much longer.

Second, SPI isn't used for security here. It's true that SPI is used by NAT, and that SPI can be used to prevent, say, a specially crafted packet from passing from a public network through a router into a private network. But something other than SPI has to actually enforce that. That "something" is usually extra features of the network stack, like disabling source-routing, reverse-path filtering, ARP filtering, etc. All SPI is doing is helping the NAT engine track the connections it is translating.

For "good faith" traffic (that is, not crafted by an attacker to work around crappy NAT routers) NAT still provides security. Actually it's not NAT at all that's providing the security - it's just the routing. You can't pass traffic from a public network into a private network, and almost all devices behind NAT are on private networks. So NAT provides security merely by keeping devices on a private network.

Re: QUIC is now RFC 9000

#224

Post by skyde » Sun, May 30, 2021, 12:48 AM UTC

throwawaaarrgh wrote: post #35

> The internet transport ecosystem has been ossified for decades now, and QUIC breaks out of this ossification But it's still just a layer on top of UDP, and still implemented at the application, like in the past. So how is the ossification broken? Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a…

« Every app has to implement it itself rather than calling a syscall » It actually will be part of the Windows kernel similar to Http.sys

Re: QUIC is now RFC 9000

#225

Post by Spivak » Sun, May 30, 2021, 2:18 AM UTC

overgard wrote: post #167

zajio1am wrote: post #97

Earlier quoted context omitted.

It is not really question of OS vs library, but question of standardized API vs ad-hoc API. Most basic networking API is standardized (sockets in POSIX API).

OS's defining the "standard" is very much a 1990s thing; at this point libraries and languages are much more relevant to standardizing things. If you're writing rust, or ruby, or javascript, or C#, or python, or whatever, you're going to be using what your language ecosystem provides you. OS libraries are usually only relevant to C developers writing something low level, and usually they need to write a lot of wrappe…

How do you think those languages actually implement those features? Because I can assure you that they aren't bundling their own userspace TCP stacks.

Re: QUIC is now RFC 9000

#226

Post by janaiyengar » Sun, May 30, 2021, 4:18 AM UTC

KirillPanov wrote: post #109

jeltz wrote: post #96

Earlier quoted context omitted.

I have spoken with Daniel Stenberg about this and if I recall correctly he disagreed and said that the QUIC which ended up being standardized is quite different from Google's QUIC.

I'd be interested in knowing what major design directions were changed/deleted/added.

@KirillPanov -- you might find this article useful: https://www.fastly.com/blog/maturing-of-quic

Re: QUIC is now RFC 9000

#227

Post by throwawaaarrgh » Sun, May 30, 2021, 5:00 AM UTC

KirillPanov wrote: post #219

throwawaaarrgh wrote: post #191

Earlier quoted context omitted.

> there is no technical hurdle As someone who has been forced to use ZScaler, there is a slew of technical challenges. 80% of the traffic can be handled "easily" with a custom CA cert, and the rest have varying issues ranging from client problems to server problems to problems in the proxy itself. Just trying to clone a GitHub repo over HTTPS breaks with ZScaler.

I can't comment on this specific product, but if the transparent proxy is causing you so much grief why not just explicitly configure your machine to use the HTTPS proxy? HTTPS proxies are not voodoo. There are plenty that work quite well.

Actually there is "voodoo" in both transparent and non-transparent proxies, but the bigger problem is that ZScaler's entire raison d'etre is to be a transparent proxy using Carrier-grade NAT. But the point is, ZScaler is a widely-deployed commercial solution, and it does indeed have technical hurdles. Whether it should theoretically work or not, I'm telling you in practice there are problems, and this shouldn't be dismissed out of hand as an outlier.

Re: QUIC is now RFC 9000

#228

Post by dzamo_norton » Sun, May 30, 2021, 5:43 AM UTC

lxgr wrote: post #66

throwawaaarrgh wrote: post #51

Earlier quoted context omitted.

Anything can be implemented in a kernel. But unless it's natively supported in other kernels, networks, and systems, that just means that one kernel is easier to work with. The big idea behind TCP/IP is that it's a stack which you can use anywhere and everywhere. Not just any network, but any host. To do that, you need it to be portable and ubiquitous. And there is no protocol above OSI layer 4 that is ubiquitous. By…

> By nature of being above UDP, QUIC is layer 5 or higher. That doesn't seem like a fair characterization. In some TLS-based VPNs, IP is sent over TLS – does that make it a layer 7 protocol?

This is a tunneled scenario. By definition, you cannot not sensibly use it draw conclusions about network layers.

Re: QUIC is now RFC 9000

#229

Post by KirillPanov » Sun, May 30, 2021, 6:24 AM UTC

throwawaaarrgh wrote: post #227

KirillPanov wrote: post #219

Earlier quoted context omitted.

I can't comment on this specific product, but if the transparent proxy is causing you so much grief why not just explicitly configure your machine to use the HTTPS proxy? HTTPS proxies are not voodoo. There are plenty that work quite well.

Actually there is "voodoo" in both transparent and non-transparent proxies, but the bigger problem is that ZScaler's entire raison d'etre is to be a transparent proxy using Carrier-grade NAT. But the point is, ZScaler is a widely-deployed commercial solution, and it does indeed have technical hurdles. Whether it should theoretically work or not, I'm telling you in practice there are problems, and this shouldn't be di…

You really seem to have a beef with this one particular commercial product that I don't have access to.

I've used plenty of other HTTPS proxies and the well-written ones all worked fine. Many are open source. I think you need to direct these comments to whoever is charging you money for this "Zscaler" thing.

Re: QUIC is now RFC 9000

#230

Post by dzamo_norton » Sun, May 30, 2021, 9:21 AM UTC

anyfoo wrote: post #170

capableweb wrote: post #123

Earlier quoted context omitted.

> You'd be super sad if you could not reference a function defined later in a source file. Would you? Most of the environments I'm in requires you to define the thing before you can use it, I'm not that sad about that. In fact, that seems to make a lot more sense than that you can define something after you use it, I'd expect that to lead to a compiler/interpreter error.

What environments are those?

E.g. Python