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

181–190 of 246 posts

Re: QUIC is now RFC 9000

#181

Post by BlueTemplar »

10000truths wrote: post #176
BlueTemplar wrote: post #159

Earlier quoted context omitted.

Thankfully, this is going away now with IPv6.

Unfortunately not. Most consumer and SOHO routers have reflexive ACLs enabled by default, and your average Joe doesn’t know or care to turn it off.

Oh, interesting, what is it exactly ?

Surprising that with over a year of discussions about this subject I only first hear of it ?

Would this be the reason why at least tens of millions of consumer routers don't have IPv6 firewalls (technically, opt-in firewalls, but you know how that goes...), and don't have their networks hacked ?

Wait, does it even work with UDP, which doesn't have a concept of "connection" ? (Especially IPv6 (no NAT) UDP ?)

Re: QUIC is now RFC 9000

#182

Post by BlueTemplar »

jjoonathan wrote: post #161
BlueTemplar wrote: post #159

Earlier quoted context omitted.

Thankfully, this is going away now with IPv6.

I want to believe!

Well, IPv6 seems to be today (both in popularity and speed of adoption) where UTF-8 was about a decade ago. So, hopefully in a decade..?

Re: QUIC is now RFC 9000

#183

Post by bcoates »

throwawaaarrgh wrote: post #163
cormacrelf wrote: post #64

Earlier quoted context omitted.

The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…

Ah, the old middleboxes excuse. Changing TCP would break the middleboxes, so instead we'll invent a brand new protocol which is (theoretically) ignored by the middleboxes. The idea being if you slip something in via UDP, nobody will notice, and then you encrypt it so the middleboxes give up on it. This assumes that lack of transparency is the only way forward. I'd argue that IP and TCP ossified not because of transpa…

Nah, middleboxes are garbage. The security features they claim to offer are all snakeoil checkbox-ware, businesses and government agencies/state-controlled telcos use them because they have a nominal compliance obligation to do a thing so they buy a middlebox that they can wave their arms at when the auditor/commissar comes around.

Generalized "optimizer" middleboxes don't actually work in real world performance testing, with the possible exception of machines that apply dumb global queue discipline to fix a defective buffering device somewhere else in the network, but these don't need to do packet inspection at all, just byte-counting/early-drop.

Traffic shaping mostly only works in the endpoint, but aside from that, all you need is src/dest/byte count to do as good as traffic shaping as it is possible to do without being circumvented trivially (by the far end, without the users knowledge, thanks to the web letting the server script the client)

If you want to run a totalitarian state, do what actually competent totalitarian states do and take over the endpoints.

Re: QUIC is now RFC 9000

#184

Post by cbsmith »

throwawaaarrgh wrote: post #163
cormacrelf wrote: post #64

Earlier quoted context omitted.

The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…

Ah, the old middleboxes excuse. Changing TCP would break the middleboxes, so instead we'll invent a brand new protocol which is (theoretically) ignored by the middleboxes. The idea being if you slip something in via UDP, nobody will notice, and then you encrypt it so the middleboxes give up on it. This assumes that lack of transparency is the only way forward. I'd argue that IP and TCP ossified not because of transpa…

I don't know that I'd hold up HTTP as an example of the way forward. ;-)

That said, the TLS v1.3 thing has been interesting. I tend to look at it more as a case of projecting one security context onto everyone else's security context, and the consequent problems involved. Security is tough like that.

Re: QUIC is now RFC 9000

#185

Post by KirillPanov »

tialaramex wrote: post #112
KirillPanov wrote: post #109

Earlier quoted context omitted.

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

For example, gQUIC has its own custom encryption "QUIC crypto" while as you will see in these RFCs the final IETF QUIC design uses the existing TLS 1.3 (existing now, it didn't exist when Google made gQUIC) for encryption. Or at a philosophical level, gQUIC is an HTTP replacement, it doesn't do anything else except a better HTTP, so it doesn't need to care about any features you might want for, say, SMTP or IMAP or I…

Thanks for the reply!

It's coming back now; I definitely remember reading some early drafts and thinking "boy it's sad this is just HTTP 3.0-rc1". I always liked SCTP; I'm glad IETF-QUIC has moved back towards being (sort of) SCTP-over-UDP as well as a better HTTP.

On the encryption front I don't remember reading about a non-TLS version (I probably missed it). I'm kinda sad that got dropped. TLS is just crazy complicated in ways that are unnecessary for non-web things like ssh and wireguard.... X.509 and the whole certificate authority trainwreck.

I really hope we get a "QUIC with non-TLS encryption" at some point in the future.

Re: QUIC is now RFC 9000

#186

Post by cbsmith »

bcoates wrote: post #183
throwawaaarrgh wrote: post #163

Earlier quoted context omitted.

Ah, the old middleboxes excuse. Changing TCP would break the middleboxes, so instead we'll invent a brand new protocol which is (theoretically) ignored by the middleboxes. The idea being if you slip something in via UDP, nobody will notice, and then you encrypt it so the middleboxes give up on it. This assumes that lack of transparency is the only way forward. I'd argue that IP and TCP ossified not because of transpa…

Nah, middleboxes are garbage. The security features they claim to offer are all snakeoil checkbox-ware, businesses and government agencies/state-controlled telcos use them because they have a nominal compliance obligation to do a thing so they buy a middlebox that they can wave their arms at when the auditor/commissar comes around. Generalized "optimizer" middleboxes don't actually work in real world performance test…

I'll give you that a lot of the middlebox problems are because they are garbage, however...

Dismissing the security features they are ostensibly delivering snakeoil is more than a bit unfair. There is a legit security context where absolute transparency & auditability is the right design objective, rather than absolute privacy. I'd argue the greatest failing we've seen with the evolution of TLS was the failure to recognize and address that reality.

Re: QUIC is now RFC 9000

#187

Post by Matthias247 »

touisteur wrote: post #87
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?

Well you know that someone is gonna implement it in ebpf sooner than later.

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.

Re: QUIC is now RFC 9000

#188

Post by cbsmith »

throwawaaarrgh wrote: post #164
jjoonathan wrote: post #152

Earlier quoted context omitted.

All cloud services. Personal computers and devices are not allowed to talk to each other on the internet. They are only allowed to talk to specially designated servers -- specially designated by virtue of having a public IPv4 and open port. Enforcement happens through liability: if you put data in a cloud service and the cloud service gets hacked, it's the cloud service's fault, but if you run a program on an open po…

NAT is literally the only thing stopping every single personal device in the world from being hacked. It may be a kludge, but it's the best kludge in all of technology. And what do you have against QoS? Would it be better if your VoIP calls stuttered every time you loaded a fat web page?

It's really not. Like, really, really not. I won't try to make the case here, but just know that assertions like that aren't going to come across as credible. The systemic effects from NAT have actually made things worse.

Re: QUIC is now RFC 9000

#189

Post by KirillPanov »

cormacrelf wrote: post #64
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” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…

Are deep packet inspection and modification boxes really that prevalent outside of the Great Firewall of China and its imitators (Russia has something similar now)?

If QUIC gets in the way of these countries they will simply set up a decrypt-and-recrypt TLS proxy and block connections that don't honor its certificate. Lots of banks and trading firms already do this to their employees for regulatory purposes; there is no technical hurdle.

Re: QUIC is now RFC 9000

#190

Post by Matthias247 »

fanf2 wrote: post #155
MichaelMoser123 wrote: post #102

Earlier quoted context omitted.

you can do that, if you can to accept the overhead of a system call per outgoing/incoming frame.

or use sendmmsg(2) and recvmmsg(2) https://www.man7.org/linux/man-pages/man2/sendmmsg.2.html

Those work and will reduce the system call overhead. But testing showed that it isn't actually the main culprit (e.g. you might gain 5% efficiency by going for it).

A far bigger bottleneck with the kernel stack is that e.g. the route lookup, iptable rules and similar things will be evaluated per packet - which is taking up most of the time. That will happen independent of you deliver one packet per system call or multiple of those.

UDP Generic segmentation offload (GSO - https://lwn.net/Articles/752184/) reduces that overhead by amortizing all in-kernel and driver operations over batches of datagrams. It makes a far bigger difference in efficiency than purely reducing syscalls (e.g. to +100% efficiency - but it will all depend on the other work the application and QUIC stack does and what drivers support).

Post reply on HN