Will QUIC Kill TCP? // Wireshark Talk

In this session we discussed the newly minted QUIC RFC's and how this protocol stands poised to take on much of the TCP workload over the web.

Like/Share/Subscribe for more Wireshark content!

== More On-Demand Training from Chris ==

== Live Wireshark Training ==

== Private Wireshark Training ==

[manangandhi]

Thank Yo so much for your videos chris. i use your videos for interview preparation so many insights. Thank You again.

[wtfanupam]

As a Cybersecurity Analyst I was not that fond of networking. but this guy make me fall in love with networking. Now I'm daily watching and learning new things from his videos 🔥 awesome man ❤️ thanks for creating Soo many free clips ❤️ really appreciate it ❤️

[Derbauer]

Amazing! Came here from David Bombal, staying for these kind of deep dives. Can you do one about VPNs and how they look in Wireshshark?

[frankenbox]

You are one of the only IT educators that I have come across that you can instantly, and genuinely know that you have real world experience on top of having the ability to educate and not bore your students to death. Seriously thank you!

[xrZt]

Love your videos Chris, thank you so much for putting in so much work and sharing your knowledge!

[nathansherrard]

Hey Chris - another great video! I've been tearing through your channel the past several days.

One thing that caught my eye around @53:10 was that the QUIC Transport Parameters are just yet another TLS Extension, even though they're somewhat unrelated to TLS itself.

Now, TLS Extensions have already been used for things outside the scope of crypto (i.e., ALPN), though that seemed to be to saved a Round Trip by figuring out the app protocol during the handshake, instead of after.

But here, it seems the QUIC Extensions could have gone anywhere else on the wire in a more "natural" spot with other QUIC info, but I guess since there were requirements to authenticate the parameters (and also encrypt the server's) [RFC 9000], then the TLS Extension area was a convenient fit, even though it seems odd at first glance?

Finally, I found this comment in RFC 9001 (Using TLS to Secure QUIC) : "QUIC transport parameters are carried in a TLS extension. Different versions of QUIC might define a different method for negotiating transport configuration."

[IgetTings]

Thank you! Great video. It seems kind of counter productive to me that we are trying to set the expectation that *because it is more secure* we are going to need client/server encryption keys. That perspective that the service provider/ IT department needs to decrypt the payload to fix the problem feels like a slippery slope.

[alexanderwitte]

hey Chris ive been spending the last week finding all your content to watch. love your teaching style! would be cool to have a video on multipath protocols (mptcp or mp quic) at some point. thanks again!

[arhat-hierofante]

thnxs for the information $G$white hats always watching$G$

[dono]

Excellent talk. I learned a lot. Thank you. A few years back I used to manage a small office network and often saw UDP 443 packets in the firewall logs. I knew it was a Google experimental protocol, but many network admins at the time suggested blocking it (or not whitelisting it) as it was non-standard (at the time) and there was little to no protocol support in the firewall stack. It seems that decision was pre-mature. Hopefully we'll see more firewall support in the near future.

[MrBitviper]

thanks for this wonderful video chris. you are a godsend
love your stuff. keep up the good work

[anandrajm]

Great stuff, as thorough as your TCP videos. Fan of this channel!

[parkyang]

Gold video, helped so much on understanding network.

[fritzbiederstadt]

Outstanding video...you probably saved me about at Least a full work day needed to reverse engineer some QUIC streams / frame in RFC 9000...Of course I'd have to sweep up my eyeballs afterward...Thanks!!

[greob]

Nice presentation, easy to understand and very interesting. Thanks for sharing!

[everydaymacrocooking]

Going to share this one with my co workers good video thankyou!

[aleks.lambreca]

Great talk but how are you supposed to troubleshoot QUIC in a production network?

[Dave-kqgv]

What a cool video! I think I met you briefly at SF 2017, but am not sure...did you go to the Pittsburgh one? Regardless, neat showcase!

[toddmarshall]

What's really disconcerting is that ATM has done this all along...amazingly fast; amazingly efficient; with minimal hardware; a splendid protocol...and we discarded it? Why? You tell me. At the time they complained about the 10% "cell tax"...the bits of overhead in each cell to effect the protocol. Well, just like government, that tax got swamped by complexity.

I got fired from a carrier for pointing out that IP has to have at least 6 protocols (e.g. IPSEC; DIFFSRV; INTSRV; MPLS;...) to do what ATM does natively. ATM was truly elegant. IP (TCP/IP) was a kludge...and it just kept getting worse. The carriers were "provisioning" all their layer 2 traffic manually using PVC's (Permanent Virtual Circuits). But ATM had SVC's (Switched Virtual Circuits) designed in at the same time. SVC's are essentially dynamic "connections". What is TCP? It's a dynamic connection (but at layer 3...not at layer 2). What's even more stupid was my running across a paper where someone was illustrating how ATM could be emulated using TCP/MPLS. How utterly stupid! You can probably google and find it.

And now, when we should be eliminating carriers altogether by going to mesh networks where every user is a network element (node) we have ditched the protocol that would make it work...ATM. IP has just 20 hops time (1/8th second) to keep the connection viable. In that time ATM can do 20, 000 or more hops with less latency!

[amirmohamed]

Great content like every day .
I have a question plz : what is the difference between using wireshark alone and using it with Arp spoofing, because in the both i will monitor the traffic in my home wifi . Plz i need to understand . Thank you a lot .