Will QUIC Kill TCP? // Wireshark Talk 

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

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 ❤️

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?

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!

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

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

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

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

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

Gold video, helped so much on understanding network.

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

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!

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.

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

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.

Thanks, Chris

well explained..... nice

Genial presentación. Gracias

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

Really new . Thx man .

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 .

Hi Chris video topic is absolutely awesome .Thanks a lot ! en... May I ask how can I capture key log from client side?

As always, great video. How does Quic determine the MSS it can use on a path? In TCP this was something that could be set on a middle box. I'm guessing as Quic is encrypted, this can't be "manipulated" anymore. So do we see some round-trips getting wasted for every new connection as Quic tries to figure out the MSS it can use?

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!

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

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!

Excellent presentation! How do you see the tools/processes evolving when needing decryption keys to do any meaningful analisys? It's one thing to do it on your desktop but how will this work in the real world and what will tools like wireshark have to include to make this easier? Maybe its a non issue and is obvious but I am just thinking of complexity in enterprise environments as QUIC evolves over the years. I have started reading the rfc's and found it immediately helpful to see practical examples of the info embedded in RFC8999-9002. I hope Apache integrate QUIC sooner rather than later. I may have to spin up Nginx in the lab and start messing around. Cheers

Good information about QUIC. What I did notice the audio of this video is from time to time dropping ang hanging. Same as an old mobile phone telephone call connection. @Chris, will you take a look into this problem?

How do you add "stream id", I didn't found that column.

Does Quic provide a non-reliable mode as well? If I want to use Quic for a new VoIP application, Is the loss detection and retransmission built in (hardcoded) or can I use it as a best effort protocol and still benefit from the built-in encryption?

Hello, some security question. I think that SSL inspection is not possible in this protocol? So all this current deep packet inspection techniques will be useless? I would say that this will reduce security if this protocol gain some popularity.

when TCP/IP and IPV4 as well as IPV6 go OBSOLETE; - I will return to my life as a Fisherman / Olive Farmer / General farm hand...... ......might do some more driveways with my fellow men of the road..........

So TCP/IP is around 40 years old this month and I've been thinking about that. Google is at 35% of visitors use IPv6. And growing by 10% per year. So if we are not on IPv6 in 10 years (and probably we'll be on QUIC too) we should be all very disappointed. We can't fit all of the world on IPv4, we don't all want to be stuck behind Carrier Grade NAT, right ? So maybe in 10 years: IPv4 will be replaced by IPv6 and TCP by QUIC ? So can we still call it TCP/IP ? I guess we'll just call it IP.

All in all it shows how dangerous it is to have one huge monopoly. I mean yes QUIC might be a good solutions, but (and there is always a but) Google can basically do whatever they want nowadays and not all will be for the best.

So network analysis is about to get much tougher and this is just version one of quick?

Will you be posting on Rumble?

Good afternoon Misters please show subtitles in spanish and english I am foreigner from Colombia thank you

I agree with the HTTP issues, but TCP is brilliant. You haven't given TCP its due. HTTP/2 went to production too early. This is riskier and less certain. Network failure is possible. I'd like QUIC to succeed, but this is a job for computer scientists, not software engineers or developers. Not saying Google couldn't have done it, but it would be unprecedented. Even Go failed to obsolete C. TCP is a smaller project than C, but they are both at Goku power levels.

doesn't look like a quic kill atm

not another protocol!

Interesting topic but you kind of made an hour video from 20 minutes worth of information. Your delivery on the subjects was definitely not QUIC :(