Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC is now RFC 9000

fastly.com

Post reply on HN
Print view View original

231–240 of 246 posts

Re: QUIC is now RFC 9000

#231

Post by KirillPanov »

janaiyengar wrote: post #226
KirillPanov wrote: post #109

Earlier quoted context omitted.

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

Thanks! After reading the link you provided, I found out that gQUIC's FEC (Forward Error Correction) was removed from IETF-QUIC, which is a minor bummer.

But it appears that the removal is not permanent, and that it was removed mainly because it is something that can be added later ("QUIC 1.1") in a backward-compatible way.

The other really interesting part was the "spin bit". It's intuitively clear how it could be used by ISPs to monitor the latency impact of their decisions. Unfortunately the cynic in me knows somebody will find a way to use it for fingerprinting. Room 641A really ruined the ISP's credibility in a permanent way.

Re: QUIC is now RFC 9000

#232

Post by throw0101a »

throwawaaarrgh wrote: post #223
throw0101a wrote: post #206

Earlier quoted context omitted.

> 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 lon…

> But since they aren't using NAT, they aren't protected.

I just demonstrated that protection exists without NAT.

> […] but luckily it's still a small amount of traffic/devices worldwide.

I don't think this is correct. Just about all devices on a cellular/mobile network nowadays are probably using IPv6 natively, with CGNAT for IPv4. That's a lot of devices.

* https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mob...

An experiment: temporarily disable Wifi on your cell phone, go to your browser, search of "what is my ip address". Chances are that you'll see an IPv6 address there: if using Google they'll return something an IPv6 address at the top, and a list of different web sites that do the same thing. If you go to a website you'll probably get an IPv6 and an IPv4 address.

> But something other than SPI has to actually enforce that.

Connection tracking is sufficient for most modern protocols (i.e., not (active) FTP):

> A stateful firewall keeps track of the state of network connections, such as TCP streams, UDP datagrams, and ICMP messages, and can apply labels such as LISTEN, ESTABLISHED, or CLOSING.[2] State table entries are created for TCP streams or UDP datagrams that are allowed to communicate through the firewall in accordance with the configured security policy. Once in the table, all RELATED packets of a stored session are streamlined allowed, taking less CPU cycles than standard inspection. Related packets are also permitted to return through the firewall even if no rule is configured to allow communications from that host.

* https://en.wikipedia.org/wiki/Stateful_firewall

* https://en.wikipedia.org/wiki/Firewall_(computing)#Connectio...

> Actually it's not NAT at all that's providing the security - it's just the routing.

Yes, that's exactly my point. And as part of routing packets one can inspect their headers and drop or allow them as desired.

Re: QUIC is now RFC 9000

#233

Post by BenjiWiebe »

quotemstr wrote: post #132
amelius wrote: post #82

Earlier quoted context omitted.

And why does it have to be handled in the OS, if a library would do just fine and provide more flexibility?

Because if it's not in the OS, people are going to cheat more often on congestion control to prioritize their own streams. It's a tragedy of the commons. It's only because TCP is ossified and usually in the kernel that we haven't seen a race to the bottom already.

I'm pretty sure that's not how congestion control works... My ISP doesn't honor my congestion control flags. Whatever congestion control I set up ONLY changes things on my side of the ISP connection. And yes, within my LAN, I definitely can prioritize various streams.

Re: QUIC is now RFC 9000

#234

Post by lxgr »

dzamo_norton wrote: post #228
lxgr wrote: post #66

Earlier quoted context omitted.

> 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.

Would it be very wrong to consider QUIC a new type of layer 4 protocol encapsulated in another one (UDP) for compatibility with NATs and other middle boxes?

SCTP is also usually encapsulated in UDP when used in WebRTC data channels, yet I've never heard it being described as anything other than a transport layer protocol.

Re: QUIC is now RFC 9000

#235

Post by aaravchen »

azernik wrote: post #105
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…

The ossification has nothing to do with the distinction between userspace vs kernel. The kernel can implement layer 5 (there are in-kernel HTTP servers!), and userspace programs can implement layer 4 (using raw sockets). It has to do with the distinction that middleware boxes make between layer 4 and layer 5. NATs and firewalls and assorted traffic optimizers tend to vomit if you pass anything over IP that isn't TCP,…

Ironically, one of the proponent documents of QUIC and HTTP/3 (https://http3-explained.haxx.se/en/the-protocol/feature-udp) actually calls out how QUIC doesn't solve this problem either. Middleware boxes are blocking or deprioritizing UDP packets already, so UDP based 4.5 protocols can't solve the very problem they claim to.

Circumventing badly behaving middleware is obviously not actually possible. You can't account for every protocol-breaking/limiting decision every middleware vendor has ever made, and the "they'll come around" argument is a better argument for NOT using QUIC.

Re: QUIC is now RFC 9000

#236

Post by throwawaaarrgh »

throw0101a wrote: post #232
throwawaaarrgh wrote: post #223

Earlier quoted context omitted.

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 lon…

> But since they aren't using NAT, they aren't protected. I just demonstrated that protection exists without NAT. > […] but luckily it's still a small amount of traffic/devices worldwide. I don't think this is correct. Just about all devices on a cellular/mobile network nowadays are probably using IPv6 natively, with CGNAT for IPv4. That's a lot of devices. * https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-m…

I think we're sort of agreeing on the same things. NAT protects devices, and stateful firewalls protect devices, and if you have neither, you're not protected. My point was that more devices exist behind NAT than come bundled with a stateful firewall, hence NAT protects more devices. The NAT devices/routers might additionally have a stateful firewall (which really only protects the router, not the other devices), but I wouldn't trust it as much as the security of a non-routable network.

Re: QUIC is now RFC 9000

#237

Post by throwawaaarrgh »

touisteur wrote: post #220
Matthias247 wrote: post #187

Earlier quoted context omitted.

As someone with experience in eBPF and QUIC I can tell you it will be a tough one. QUIC is very complicated and requires some rather sophisticated (and long running) algorithms, and eBPF is [intentionally] rather limited on what it can do. However there are some interesting use-cases for eBPF in the context of QUIC. E.g. it can definitely be used to route packets by connection IDs.

You're right. I think on the overall we'll gonna have to learn to restrain/harness ebpf somehow, since it will keep growing. We're already starting to see some complex applications appear over tc+ebpf and I believe I've seen some tcp congestion algorithms prototyped there? Those can be somehow complex already. Crypto could be offloaded to dedicated 'nodes' (as you find in dpdk for example). But, since you can now cha…

> I can imagine some kind of task-graph programming model emerging there allowing for very complex applications

This is why I hate technology. It doesn't need to be this complicated.

Re: QUIC is now RFC 9000

#238

Post by throwawaaarrgh »

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…

What you're saying is that you personally don't need to write network code that performs socket(), bind(), listen(), accept(), send(), recv(), etc. But the programming language and library you're using is using those calls, to talk to the kernel, which is doing a lot of the work, so your language/library doesn't have to. And it does that using a standard API.

This enables less context switching, faster processing, more uniform behavior, and more portable code. It also means your language/library does not need to implement a TCP parser, which can be quite complicated, and it means the kernel can maintain the more complex network settings that affect your TCP connections, benefit from a shared buffer/cache, network filters, routing, etc. Off-loading protocols into the kernel (or even better, the network card) is a boon to the whole OS and to your individual application.

Re: QUIC is now RFC 9000

#239

Post by TingPing »

1vuio0pswjnm7 wrote: post #217
jedisct1 wrote: post #106

Earlier quoted context omitted.

Microsoft has an excellent implementation, too: https://github.com/microsoft/msquic

Why not https://github.com/quictls/openssl This is what the Microsoft implementation relies on

That is just the tls portion.

Re: QUIC is now RFC 9000

#240

Post by throw0101a »

throwawaaarrgh wrote: post #236
throw0101a wrote: post #232

Earlier quoted context omitted.

> But since they aren't using NAT, they aren't protected. I just demonstrated that protection exists without NAT. > […] but luckily it's still a small amount of traffic/devices worldwide. I don't think this is correct. Just about all devices on a cellular/mobile network nowadays are probably using IPv6 natively, with CGNAT for IPv4. That's a lot of devices. * https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-m…

I think we're sort of agreeing on the same things. NAT protects devices, and stateful firewalls protect devices, and if you have neither, you're not protected. My point was that more devices exist behind NAT than come bundled with a stateful firewall, hence NAT protects more devices. The NAT devices/routers might additionally have a stateful firewall (which really only protects the router, not the other devices), but…

> My point was that more devices exist behind NAT than come bundled with a stateful firewall, hence NAT protects more devices.

The popularity of a mechanism does not necessarily correlate with the effectiveness of its security. The fact that we're using IPv4 with NAT+SPI versus IPv6 with SPI is simply an accident of history.

If IPv4 had been designed with 64-bit addresses, or even 48-bit ones (like Ethernet MACs, which we still haven't run out of), then NAT probably would not have been invented, and we'd be using 'simple' (SPI) firewalls (see Cheswick 1994).

> […] but I wouldn't trust it as much as the security of a non-routable network.

Non-routable networks are not more secure than routable ones with SPI; at best the two are equal IMHO. Non-routable networks may actually be worse because of a false sense of security: all it may take is one end-point compromise and the enemy is one the other side of the moat.

Post reply on HN