The Internet just changed.

You better be aware of what just changed on the Internet. TCP is being replaced with QUIC. UDP is being used more and more instead of TCP. This affects your firewalls. It affects a lot of your network troubleshooting. HTTP/3 has been standardized. Everything is encrypted with QUIC - welcome to the new world of network troubleshooting and security.
// MENU //
00:00 - The Problem with TCP
00:12 - Introducing//Robin Marx
02:12 - Clean Ship, Clean House//RFCs
03:25 - HTTP Semantics//QUIC//HTTP/3
04:17 - Why the Hell Do We Need HTTP/3?
05:05 - Why QUIC?
08:35 - QUIC & TLS Integration
10:02 - Why Use UDP?
13:50 - Replacing TCP with QUIC
14:28 - Summary So Far
15:22 - Stream Multiplexing
15:40 - Head-of-line blocking
18:40 - Why This Slows Things Down
19:29 - How QUIC Does It Differently
20:58 - TCP vs QUIC//Packet Handling
23:11 - HTTP/3 Prioritization
25:25 - Stats//QUIC Isn't Going Anywhere
26:30 - Firewalls are almost useless
27:20 - Firewalls Blocking QUIC?
28:04 - QUIC & Other Protocols?
29:20 - IPv4 & IPv6//Different for QUIC?
29:54 - Challenges for QUIC's Growth
30:43 - Connection Migration
33:33 - What About Hackers?
36:32 - How Do I Get To Use QUIC?
38:28 - Large Companies Adopting QUIC
39:09 - The Internet is Too Centralized?
40:02 - Header Compression
41:55 - Server Push
43:47 - Practical Examples with Wireshark
50:34 - Thank You & How to Contact Robin
// Robin SOCIAL //
Twitter: / programmingart
LinkedIn: / rmarx
KZbin: / @programmingart
// Robin's Blog articles //
HTTP3 core concepts Part 1: www.smashingmagazine.com/2021...
HTTP3 core concepts Part 2: www.smashingmagazine.com/2021...
HTTP3 core concepts Part 3: www.smashingmagazine.com/2021...
// Chris Greer Videos //
HTTPS Decryption with Wireshark: • HTTPS Decryption with ...
Decrypting TLS, HTTP/2 and QUIC with Wireshark: • Decrypting TLS, HTTP/2...
// David SOCIAL //
Discord: / discord
Twitter: / davidbombal
Instagram: / davidbombal
LinkedIn: / davidbombal
Facebook: / davidbombal.co
TikTok: / davidbombal
KZbin: / davidbombal
// MY STUFF //
www.amazon.com/shop/davidbombal
// SPONSORS //
Interested in sponsoring my videos? Reach out to my team here: [e-mail]
http
https
quic
tcp
udp
http/1
http/2
http/3
wireshark
firewall
firewall quic
quic firewall
http/3 firewall
#http3 #quic #tcp

[@davidbombal]

// MENU // 00:00 - The Problem with TCP 00:12 - Introducing//Robin Marx 02:12 - Clean Ship, Clean House//RFCs 03:25 - HTTP Semantics//QUIC//HTTP/3 04:17 - Why the Hell Do We Need HTTP/3? 05:05 - Why QUIC? 08:35 - QUIC & TLS Integration 10:02 - Why Use UDP? 13:50 - Replacing TCP with QUIC 14:28 - Summary So Far 15:22 - Stream Multiplexing 15:40 - Head-of-line blocking 18:40 - Why This Slows Things Down 19:29 - How QUIC Does It Differently 20:58 - TCP vs QUIC//Packet Handling 23:11 - HTTP/3 Prioritization 25:25 - Stats//QUIC Isn't Going Anywhere 26:30 - Firewalls are almost useless 27:20 - Firewalls Blocking QUIC? 28:04 - QUIC & Other Protocols? 29:20 - IPv4 & IPv6//Different for QUIC? 29:54 - Challenges for QUIC's Growth 30:43 - Connection Migration 33:33 - What About Hackers? 36:32 - How Do I Get To Use QUIC? 38:28 - Large Companies Adopting QUIC 39:09 - The Internet is Too Centralized? 40:02 - Header Compression 41:55 - Server Push 43:47 - Practical Examples with Wireshark 50:34 - Thank You & How to Contact Robin You better be aware of what just changed on the Internet. TCP is being replaced with QUIC. UDP is being used more and more instead of TCP. This affects your firewalls. It affects a lot of your network troubleshooting. HTTP/3 has been standardized. Everything is encrypted with QUIC - welcome to the new world of network troubleshooting and security. // Robin SOCIAL // Twitter: twitter.com/programmingart LinkedIn: www.linkedin.com/in/rmarx/ KZbin: kzbin.info/door/yqPrNfndJ7OPhPdYJG-mmQvideos // Robin's Blog articles // HTTP3 core concepts Part 1: www.smashingmagazine.com/2021/08/http3-core-concepts-part1/ HTTP3 core concepts Part 2: www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/ HTTP3 core concepts Part 3: www.smashingmagazine.com/2021/09/http3-practical-deployment-options-part3/ // Chris Greer Videos // HTTPS Decryption with Wireshark: kzbin.info/www/bejne/fX6xgIdnlr-gepo Decrypting TLS, HTTP/2 and QUIC with Wireshark: kzbin.info/www/bejne/r6DHdZWdpKihgq8 // David SOCIAL // Discord: discord.com/invite/usKSyzb Twitter: twitter.com/davidbombal Instagram: instagram.com/davidbombal LinkedIn: www.linkedin.com/in/davidbombal Facebook: facebook.com/davidbombal.co TikTok: tiktok.com/@davidbombal KZbin: kzbin.info // MY STUFF // www.amazon.com/shop/davidbombal // SPONSORS // Interested in sponsoring my videos? Reach out to my team here: [e-mail]

[@nqobilemahlangu3812]

Thank you for the great learning tools and this video too. Quick one David, is the QUIC's feature of persistant Connection IDs similar to MPTCP?

[@RobotronSage]

Please dont replace TCP, it will destroy the internet.

[@TheExileFox]

I can't wait for websites to exploit the priorities to serve the ads first, everything else second. Even with an adblocker, this is gonna be a downside.

[@jamesm5192]

So the whole thing about the internet being more centralized was no meaningful response. It is. Who cares which company did more hard. They are all working together to. Mozilla censors as well. So are your new protocols going to make it easier for them to centralize?

[@EveryDooDarnDiddlyDay]

So we're turning the internet over to Google? Yeah, this wont be used to spy on people AT ALL

[@chamaileon81]

So many years went by since I last educated myself with networking technologies. The way Robin breaks down this complicated issue is amazing, I was kinda bored when I saw that this video is almost an hour long, but at the end I didn't even notice it, it was great knowledge and was given in such a great way. Congrats to everyone, this was amazing.

[@LAWRENCESYSTEMS]

One other issue that I did not hear brought up is how many firewall vendors suggest you block QUIC as it breaks many firewall web filtering methods. I covered this in my recent Web Filtering video and it's one of the reasons we choose the filter each endpoint instead of at the firewall for my clients.

[@davidbombal]

Thanks Tom! We covered Firewall blocking at 27:20 in the interview. What's the link to your video where you discuss this in more detail?

[@hauby121]

@@davidbombal His video: kzbin.info/www/bejne/nIu7Y6mqq92Ce80

[@davidbombal]

Thanks Zac!

[@xaeyl]

@@davidbombal Enterprise organisations have a tendancy to block KZbin and Facebook. Firewalls will then have to do what they do now with SSL Deep packet inspection, but adapt it on a QUIC protocol instead, The Problem with this would be the re-encryption and delivery to the destination as the CID would be different so may just fail.

[@DmnkRocks]

I would be interested what - if any - Firewall/UDM Vendors are in the communications or even contributing to this standard. It feels very much like almost all vendors just blanket it by recommending to block QUIC entirely - and non of the vendors I work with have any official or unofficial plans to work on implementing anything but a block rules/mechanisms.

[@jaimerosariojusticia]

A video I didn't asked but needed to watch. Thanks again to David Bombal and his team, and also the guest for this video. This interview/podcast (whatever you want to call it) is pure gold content.

[@davidbombal]

Glad you enjoyed the video Jaime!

[@liquidpebbles]

Fantastic interview and talk. I wasn't aware of quic until now and the high level explanation was understandable and easy to follow. Big thanks for recording and putting out there

[@jplflyer]

Presented exceedingly well. I wasn't aware of what was happening with QUIC, but the level of the discussion was perfect. Thank you.

[@massivecumshot]

Wow. Great talk. I haven't used any TCP/IP programming skills for 15 years, but listening to these guys brought everything back in seconds. Great to hear the IETF is still chugging along.

[@Superkuh2]

The IETF's rubber stamping of google's proprietary quic after their forced rollout in chrome for google services doesn't imply it's doing well.

[@melnewcomb5029]

This is the best, most informative video on Quic that I have seen. I really enjoyed it and understood much more than I thought I would. Thanks!

[@nova8585]

Just wanted to say I appreciate all the small cuts/edits you made to make the video flow seamlessly. It made the long video very pleasant to watch.

[@timothyblazer1749]

QUIC is basically a way to create a protocol layer that will ignore firewalls. It's also trying to centralize and deanonymize the internet, as it will be used. If a protocol is dependent on TLS, you can decide that certain authorities are not valid. If you do this on a network level, you can totally control end points. And this is just the easy to explain thing about it. Many other people here are mentioning other problems. We didn't need an encrypted protocol layer. We just needed a tune up. Unfortunately, the Googles of the world have outsized influence at the IETF.

[@vylbird8014]

Some of the objections are the opposite: QUIC does a very good job of keeping things private and secure. Potentially too good a job. Companies have good reasons for filtering their employee's internet connections. Schools even more so. Without the ability to intercept traffic they are reduced to crude IP and DNS blocks. The same technologies that your office uses to block Facebook are also used by China to keep their people from reading outside news sources, and QUIC makes life more difficult for them both.

[@timothyblazer1749]

@@vylbird8014 yes, but it puts that power into the hands of the application providers, and the PKI around certificates. Unless you can obviate PKI and roll your own at will without OS or application objection, you're effectively removing the ability of independent engineers to distribute code.

[@TheExtinctDinosaur]

What a great video. So easily understandable, yet so informative. The questions were so thoughtful and I am so glad they were asked. It provided so much interesting detail. As someone who is just starting to learn QUIC this is a brilliant introduction on getting the big picture.

[@-morrow]

This is the thing I can't get my head around with the QUIC design decisions: Most header data is encrypted to prevent middleboxes from breaking future changes to QUIC. But this is precisely the reason why many firewalls block and will continue to block QUIC, the packets can't be inspected, logged and reported by firewall’s web protection features. This will straight up prevent the adoption in many use cases. I don't understand why slow adoption (it takes years for middleboxes to be replaced) isn't preferrable to impossibility of adoption (without leaving a gaping hole in your network's security).

[@TricksterRad]

Most firewalls shouldn't even be doing DPI in this way in the first place. In corporate environments, you have the option of deploying an internal CA, which allows you to effectively bypass the encryption for traffic to corporate devices and continue doing DPI. In any other case, the only reason for this is censorship. Blocking HTTPS/TLS today is not an option. QUIC is going to be the same.

[@0raj0]

@@TricksterRad Being able to identify protocol details cannot be considered DPI. And in this case -as it has been said in the video - without decryption, firewalls won't even know it's QUIC; all they would see are just UDP packets with random data. How to decide whether to allow or deny it?

[@BattousaiHBr]

why do firewalls NEED to inspect the encrypted headers? the ones that really matter are still unencrypted, mainly the port. only practical downside i can see is if the firewall is also doing QoS, which would probably depend on the encrypted headers to know whether to prioritize the packet or not. but even then it would still work, it just wouldn't get prioritized.

[@shrddr]

This is a most succinct and on point video I've seen for a while and the same time being almost an hour long :)

[@Lulu_dowwg]

Thank you David sir! these topics are really helpful, please do more of those interviews like these. Thank you for keeping me up with new topologies.

[@ozzman530]

Holy smokes, this is amazingly in-depth and technical. Can't wait to see PCAPs using not only HTTP3 but when other protocols start filtering in, like SSH, as mentioned.

[@davidbombal]

Glad you enjoyed the video! Definitely be covering more videos and Wireshark in additional videos.

[@autohmae]

A protocol like SSH might use QUIC, not HTTP3 of course.

[@rakaperbawa]

Thanks for this very precious explanation about QUIC, now I can explain much clearer to my boss why I am blocking QUIC for now 😂

[@cokegen]

I know I'm going to get back to this video very often in the future. Thanks David and Robin !

[@johnmodlin6697]

Robin does a great job with the details, RFC's, and in-depth look at QUIC. Super job!

[@MrSlpkntmaggot]

Thanks David for making your content, I have been binge watching your videos for a few weeks now. and thank you Robin for breaking this down in an easy to understand way. My networking knowledge is very entry level/beginner and I was able to watch this video and make a nice large note in CherryTree to understand the basic of HTTP/QUIC, and have a nice reference to look back on. This will be extremely helpful when this topic comes up in my upcoming classes for cyber security. I will definitely be giving you a follow.

[@davidbombal]

Thank you Emmett!

[@KwanLowe]

Kudos. You presented this in a way that even I could understand. Thanks for the illumination.

[@FF-rw6fi]

The stream id concept of Quic is surely a really strong point that will make this protocol replace TCP in a lots of applications. Nice video!

[@ChrisGreer]

Great job David and Robin! Robin can explain the details around QUIC and H3 like nobody else. Don't just block QUIC for no reason. QUIC is here. It will continue to take over workload on web services on the internet. Instead, work to understand how it works and why it helps secure and optimize web apps and API's. Solid content David! 👏

[@davidbombal]

Thank you Chris! Looking forward to our next video!

[@SplitZeroOne]

The main problem with QUIC is the unecrypted connection ID?

[@guillaumelavoie1544]

​@@SplitZeroOne This is why they implemented Linkability prevention; 33:33 - What About Hackers? If I understand correctly, the real problem is if somebody is already watching your connection and they get the first uncrypted CID, they can follow through your others encrypted CID. But maybe I got it wrong.

[@yuriychernichenko7554]

The fact that something is here does not mean you have to push it to your prod environment. After all, you are the one responsible for data entrusted to you by your clients.

[@programmingart]

@@guillaumelavoie1544 Then I think you might have misunderstood. Even if hackers see the first CID, they can't follow you along with the subsequent CIDs. The CIDs themselves are not encrypted, but they are negotiated/exchanged between the client and server in an encrypted way, so there's no way for a hacker to know they map to the same underlying connection when CIDs are switched (at least as long as the CIDs are random/different enough from each other).

[@PaulMisner]

This is the best video on QUIC I've seen. Thank you so much for posting this.

[@onemorebastard]

Great walk through enjoyed this one immensely. Thanks David. Concise and clear, great insight. Thanks Robin.

[@davidbombal]

Glad it was helpful!

[@FelicioSantos]

Fantastic content, David and Robin! Thanks for sharing it :D

[@rakeshn5070]

Thanks David and Robin. What a wonderful insight its been. Robin explained it very clearly, when David asked the right question. Its exciting times to see new technologies emerging !!!

[@davidbombal]

Glad you enjoyed the video Rakesh!

[@rakeshn5070]

@@davidbombal yes, I did David. Thank you.

[@ontrucktoit6166]

I just passed my CCNA exam with the huge help of your CCNA course. Thanks! But videos like this are also great, showing that it is essential to constantly learn in this industry Thank you for helping us!

[@awdwadawda352]

Congratz! I'm also busy on it. Got any tips/resources that helped you pass it?

[@bistronauta]

Hurray 🙌 I am also curious about the materials you used to get it.

[@ontrucktoit6166]

@@awdwadawda352 Thanks! So it was primarily Official Cert Guide by Wendell Odom, premium edition with online practice exam. At the beginning I was studying the book and watched videos in David's course on his website. These videos are great as he is focused on troubleshooting and configuring realistic scenarios. I also watched videos from Keitch Barker. He also has many interesting labs on his website with step by step guidance on his YT channel.But all of that gave me only about 75% on my practice exams. In the last two weeks I was constantly doing those practice exams, split into separate categories. Let's say one day everything related to WiFi, next day IP services, basic networking+STP and so on. When you take such a practice exam in study mode you can take screenshots of your wrong answer with the correct answer and explanation. After each such a practice exam I was checking what's missing in my knowledge, going through all the screenshots I made and checking for further explanations if the one given by the practice exam engine wasn't clear enough for me. On the last day before the exam I prepared my desk as I was taking my exam online, early in the morning the next day, and I didn't want to be in a hurry right before the exam. I didn't study on the last day, maybe I just checked some notes. So for me the cherry on top were those constant practice exams in the last 10-14 days. Keep in mind that you have 120 minutes for all the questions and it isn't that much. For me this time pressure was significant, and it was stressful during the test, I had to hurry up. But I managed to answer all the questions. I know that this is pretty long answer, so that's it :) Good luck guys!

[@davidbombal]

HUGE congratulations!!! Well done!

[@bistronauta]

@@ontrucktoit6166 Wow, it seems to be pretty overwhelming. How long did it take for you to feel like you can pass the exam?

[@zxborg9681]

This is really well explained, and very significant. Glad I stumbled across this.

[@fionnbracken]

Technical topic but it was explained very clearly. Well done.

[@lerneninverschiedenenforme7513]

Best video on explaining QUIC / HTTP/3. I think 1) Changing the title to something more explanatory and 2) Changing the thumbnail to something some serious (not "will your firewall become useless) might help people finding this excellent video! Thank you very much for the effort!

[@dimononas4230]

I am still new to networking, but the explanations are very clear...thanks so much David for your lovely videos

[@davidbombal]

You're very welcome Dimon!

[@Chavecito]

Great video David!! Robin is a genius, he explains all this subject in a very easy way to understand

[@colinofay7237]

Thanks for this. I can't wait for this to be integrated properly. I read the rfc's and I'm so nerdily excited

[@sanfords]

I love the way this was produced. Great care in focusing on the information and keeping un-needed stuff out of the way.

[@bistronauta]

Thanks for the up-to-date content David!

[@davidbombal]

You're welcome!

[@ciCCapROSTi]

I never bothered much with networking, I know TCP, UDP, basics of most low level protocols, have a general idea about the application level ones, but that's about it. This could still be followed by me, and contained a lot of great info. Good job, guys!

[@BobBob-qm2bm]

Thank you for this technical awareness video. I was totally unaware of these changes. David Bombal keeping it real and relevant

[@davidbombal]

You're welcome!

[@greob]

Superb presentation / interview. Very interesting, clearly explained, and very nice work on the editing too!

[@davidbombal]

Thank you Njul! Glad you enjoyed it!

[@jsandppr]

This is a wonderful educational video! Accessible yet deep, an hour just flew by. Excellent and of course incredibly well-placed presenter on the effort being described! Great editing (which must have taken a fair amount of work) to place & remove the video heads where and as needed, slowly zoom focus to parts of diagrams & provide insets etc. to just be seamless - and with out toooo much “cuteness” inserts of stock clips for levity. Thoughtful chapter marks making a long video easy to revisit. Just really great. Subscribed!

[@programmingart]

Thanks a lot @JNDenver. Comments like this make my day ;)

[@jsandppr]

@@programmingart Updated my comment with more to say. The All-Powerful KZbin Algorithm made my day by bringing this to me this morning - I hadn’t even been watching stuff in this general topic area recently. Bravo you, and thank-you algorithm :) Give your editor a raise, too - and if you’re the editor, treat yourself to ice cream

[@davidbombal]

Glad you enjoyed it! And thank you for the fantastic comment :)

[@networkingcat5160]

Informative. Brilliant work as always!

[@davidbombal]

Thank you! Glad you enjoyed it!

[@alexanderschwaighofer1550]

Wholeheartedly agree! What indispensable insight into the IETF‘s workings and the truths behind HTTP3 + QUIC. Thank you David for the awesome interview!

[@SonOfSofaman]

Great job by Robin Marx explaining a complicated topic.

[@rafaelbianco252]

What a nice video! Amazing content! Congrats to both of you! Thanks for sharing!

[@thomasegjoergensen]

This is very interesting and Robin Marx is a very capable at conveying the information. Very impressive! Thanks a lot for the info!

[@betadyne9559]

Thank you, as a System and Network Administrator, learned a lot for future planning !

[@cdevito63]

Excellent presentation of a highly complex topic, thank you.

[@jasonpitts8395]

Another great video David. It's obvious you put in the time to book relevant guests. 👍

[@davidbombal]

Thank you Jason!

[@HKhandelwal007]

Awesome creation david. You are one of the best technical host too as..It was almost like whenever I would ask a question to myself while watching the video ... david would ask it to the guest. Instant gratification I must say. You are my new guru ..towards my newfound passion ... cheers .. big fan already.

[@zambrota747]

Thank David and your guest. Great video

[@MyDancingirl]

Great breakdown of info and great interview. Thanks!

[@davidbombal]

Thank you! Glad you enjoyed it!

[@Pongsn]

Just last week I had an exam for the course Multimedia Networks (studying computer science) and HTTP2/3 / QUIC was a major part of the exam. Happy to see my Professor chose some VERY up to date topics to teach us. Also some of the graphics you guys used were used in my lectures :D

[@shazzz_land]

70 percent of people use old sistems thus making quic useless like IPv6 is useless

[@TGears314]

@@shazzz_land that’s like saying “oh man this wheel John invented is useless! We all just carry things! Who would need to use that?”

Great explanation of HTT3/QUIC. Thank you.

[@Psychotroop]

I love the new format of the channel. wow!

[@KitsuneAlex]

Super nice video! Insane to see what kind of thought goes into designing a new, backwards-compatible protocol standard :)

[@jamesreilly7684]

About 25 years ago I filed for patent on what eventually became "push technology" (The name of the company was PointCast). The patent has long since expired but the concept lives on. I am personally thrilled to have server push as part of the http3 quik standard as it will eventually be deployed everywhere and therefore likely make my original IP one of the most utilized patents worldwide. The only one that is likely to be more ubiquitous is the original csma/cd by Dr Rober Metcalfe (who was my boss at 3com) (and of course TCP by Vinton Cerf). Both of them will be horrified that a mere mortal such as yours truly should even be mentioned next to their names. But I personally am thrilled as it will make me completely insufferable when i mention i t to all of my friends :)

[@vinny142]

I'm so glad you're humble enough not to brag about this, except here on youtube. Why didn't you hold on to the patent and become a millionaire?

[@jamesreilly7684]

@@vinny142 I signed it over to the company as they paid for my salary and patent documents and famously the CEO was voted the anti entrepreneur of the decade for his running pointcast into the ground after Rupert Murdoch offered $450 million for the company. (By then i had left in disgust as the company was controlled by the family members not the vcs and they turned it down)

[@OEFarredondo]

you are a boss my man.

[@prashanthb6521]

Congrats sir. Very few emotions can match such a success.

[@happydawg2663]

Congrats man, happy for you.

[@kamur]

Excellent in-detail presentation and discussion.

[@davidbombal]

Glad you liked it Kamal!

[@jarrod752]

Learning about connection migration alone is worth the watch. So much of this will affect how I do my job going forward.

[@dis_root]

Wow, Robin spoke great in this, I was able to completely follow along and actually learn something

[@WilliamTomFrank]

Great video and excellent information, as usual. Cheers.

[@davidbombal]

Thank you! Glad you enjoyed the video!

[@protek7028]

Worth listening made some notes of it. The thing that i like about this video or channel in general is the perspective and the big picture behind any new emerging tech Thanks David Sir

[@davidbombal]

Thank you!

[@seanwilkinson2291]

This is an excellent video, very informative. Thank you!

[@davidbombal]

You're very welcome! Glad you enjoyed the video Sean!

[@riaanbotes1187]

This was very informative. Thanks guys.

[@Chewbucksa]

Very interesting. Thank you for this interview.

[@dinushkam2444]

Great video... very interesting conversion, lots of information

[@mikeclark1024]

Very interesting and absolutely essential for everyone in web tech to know!

[@DarkSider667]

Great Video overall. However the connection ID stuff is a bit contradictory. First you explain, that the connection id is one of very few unencrypted fields in the header, so load balancer and middle boxes can keep the connection persistent even if IPs / Ports change due to the connection migration feature. However the next part explains, that the migrated connection uses a totally different set of connection IDs that have been negotiated previously through the encrypted channel. So how do the load balancers know (as they can't view the encrypted traffic) what to do with the post connection migration connection IDs? For any load balancer this just looks like a 100% new connection!

[@quentinquaadgras]

This is a good point, that I would like to see addressed by somebody.

[@victorroque7]

I was about to ask the same question…

[@nine8731]

I would be very interested on how to loadbalance VOIP, IPPhones and other appliances that would use that...

[@terrasque]

I had the same question, in addition wouldn't this make spoofing or stream disruption more easy? Don't even have to spoof the IP, just send a packet with same connection id. I guess to his defense of the load balancing part, he did say that the connection id swapping wasn't really used and was more of a theoretical thing.

[@satibel]

You could still somewhat infer what kind of traffic is used by which connection id and route like that, large packets would be downloads, while small frequent packets would be voip. Or having an extra tag for low/normal/high priority packets would be nice.

[@duaneatnofroth]

So... "Trust us, this is secure" (TM)

[@greenseed666]

exactly , big tech is here to help you! (TM)

[@gg-gn3re]

I've used QUIC for ~7 years, absolutely fantastic

[@duaneatnofroth]

@@gg-gn3re Is that as a user or system administrator for a business? For the record, I don't think everything about QUIC is bad; I think it's a mostly positive development. I have two issues with it: It makes it impossible for firewalls and other security appliances to do their job and; the part of its specification regarding compression (iirc) is so complex that no developers are making use of that part. Sure, for end-users it's faster and may provide more privacy but maybe it also opens them up to more malware attacks.

[@sviktor4]

This QUIC thing looks like someone just try to reinvent the wheel and say "I gonna optimise the network traffic and its all encripted" and in the process remove all the features that made possible to optimise traffic in the last 20 years. It feels like the dynamically loading webpages, they are totally messed up and unnecessary, but here to stay because nobody has the gut to admit they screwd up. I bet if you reintroduce pages for the younger generation, they blow their mind how easy to just page rather than scroll. Hiding behind UDP just messes up for the future, because guess whats gonna happen stays that way forever. Transition is never easy and always slow but gonna happen eventually like traktors and horses not allowed on highways. What I see in the current stage is lots of optimisation and security issues, of course people don't wanna implement it. The middle men can't guarantee the client security anymore, for now on you have to trust in google facebook etc. end to end, of course big companies pushing this technology so even goverments can't stop them in the future. Totally OFF topic I love the "MINDSET IS EVERYTHING" picture in the background, poor fish thinks it's smart, but if a shark comes it comes below and see that is not another shark, if a fisherman throws the bait the fish still hook on it and the fisherman still catches is. The fish can only scare the people on the beach who newer was a real thret for the fish.

[@LiEnby]

It seems fine to me ..

[@saltywater236]

Thank you for the excellent video!

[@bugs181]

Exciting stuff! And easy to follow along. Great video! Liked + Subbed

[@jonathanmartins7744]

incredible talk! tanks for sharing

[@ManoZeuss]

Fantastic talk. I learned a lot, thanks!

[@gatty.]

Fantastic video! Keen to see more like this one David! :D

[@davidbombal]

Thank you! Glad you enjoyed it Gatty!

[@MrRobot222]

Great video, thanks David!

[@dirkl9652]

Awesome interview and even awesome explainations. I approve this message. 😁

[@davidbombal]

Awesome! Thank you Dirk!

[@JonnyClark]

Loved the Video Thanks David !

[@iamdestructoman]

Thanks for explaining this... awesome vid!

[@juliusrowe9374]

Awesome content David!

[@cleightthejw2202]

That is some seriously interesting and fun sounding stuff to learn and understand :)

[@hauby121]

This was a well edited video!

[@macrominutes]

All I can think about while listening to this new implementation is.... the number of exploits that will come about. The more things change the more they stay the same.

[@dougspindler4947]

Excellent presentation.

[@lifelimitless1710]

And all these years I grew up learning "Disable or Block QUIC protocol to force Google Chrome web browsers to use TLS/SSL and guarantee a proper SSL inspection".

[@-morrow]

probably a good thing. because with quic also the malicious traffic will be encrypted.

[@MrBitviper]

thanks for another great video David. awesome stuff

[@davidbombal]

Thank you! Glad you enjoyed it!

[@aapqjwjgwg8832]

Bro, This channel is just an insane treasure

[@davidbombal]

Thank you!

[@187lockedown]

this is intense but managed to get my aging head around the next gen protocols with the fantastic explanation

[@rick.d]

Nice work, thank you.

[@upelister]

Great information about Quick, thank you.

[@davidbombal]

You're welcome! Glad it was helpful!

[@AlbertAltman]

Bigger problem here! First of, thank you for a wonderful interview! All SSO(single sign on) and most web based access control solutions are not compatible with QUICK. So most banks, internally and on customer side applications will not work with this. Many other big corporation applications will also break. We will have to run in parallel with HTTP2 for dacades before the industry will adapt. Mostly due to the huge funds required to update all the products.

[@zaq_hack4987]

I mean, it is a new standard. No standard is adopted instantly across the whole internet, anyway. To me, SSO is probably going to be one the EASIER ways to start getting access to it. Hard to think that Okta isn't going to support it pretty quickly if Google, Amazon, Apple, and Microsoft are already in the game ... The bigger problems are going to be the firewalls and proxy servers, I would think. I'd like to see how Cisco, Juniper, Watchguard, Fortinet, etc respond to it. They may have additional tweaks that make it more plausible to adopt, but "accept UDP from Google" is probably not going to fly, most places.

[@dinieshvc8069]

Nice explanation and useful topic to know/learn

[@lohphat]

The challenge with QUIC is that since there are multiple file streams in one request, ad servers can't be blocked as with TCP since the ad stream may be embedded in a single QUIC request to the FQDN of the main web server. Google and MSFT serve ads from "inside the house" so that tools to block ads based upon FQDN are now bypassed since the ads are just another stream inside the initial QUIC request. That's Evil.

[@0raj0]

But one does block ads usually in browser, that is, on application layer, where everything is cleanly separated again, right?

[@LiEnby]

@@0raj0 yeah it just stops say network wide blocking

[@agrimm61]

Since QUIC relies on UDP, how are reflection attacks addressed? The packets are huge, compared to TCP handshakes where you can mitigate such attacks from the start. UDP lacks that handshake, isn't that dangerous?

[@wishusknight3009]

yup it is.

[@surewhynot6259]

You still have the QUIC handshake. QUIC reimplements most of TCP's features.

[@autohmae]

QUIC re-implements TCP (like slow start) and if I'm not mistaken the connection IDs in QUIC are bigger than TCP so allows for more security. Also a size and packet count limit is placed on responding to the initial packet I believe ? I've not read the RFC, but they put a lot of thought into it.

[@0raj0]

@@autohmae But it must be done on application level, as QUIC is totally encrypted. Firewall can't look into the packets so can't mitigate the attack.

[@autohmae]

@@0raj0 that's true, they can't

[@sebastienloyer9471]

Very eye opening experience

[@connorfowler1578]

Thanks for the Vid David and Robin great content as usual. Quick question for anyone, I am a little new to networking, but if you could encrypt headers so to bypass middle box "interrogation/interpretation" could an attacker not do the same with malware packets or "bad" packets (as in encrypt the malware so that the firewall will pass it through?). thanks for your responses.

[@robertroxxor]

great video, it explains a very complex topic in a simple to follow way. a bit too much meme'ing imho but otherwise perfect. would love to see a deep-dive video about the security implications (firewalling, ssl decrption, etc).

[@ganeshg786]

Hello Mr David thanks for the video.

[@equid0x]

I've already had problems with users of 4K video streams served over QUIC. It would appear some ISPs are either rate limiting or can't handle the large volume of UDP traffic. This results in stuttering video that won't buffer that's basically impossible to diagnose due to the encrypted protocol and being served from CDNs. I think the corps have not given any thought to the real world implications of this change in production environments. It only serves to increase traceability. Its possible to roam TCP connections over an ipsec VPN using mobike and nat-t while still allowing traffic to be inspected and firewalled.

[@TrashPandamonium]

I am excited about QUIC but totally anticipate existing firewall / traffic monitoring vendors to block it because it does make their solution useless. As others have pointed out too, it does also allow for malicious traffic to use QUIC for nefarious purposes - well, I guess the vendors can look for weird usage patterns in the amount of QUIC traffic going out but that's about it, given the absolute majority of the payload, including the headers, is encrypted. What I did want to point out though is that I would imagine QUIC to be susceptible to DDOS attacks and other "common TCP attacks". Basically, with QUIC, traffic is either allowed or blocked, meaning the burden of processing the packets is on the destination server, NOT the routers in between. So I theorize that you can basically bring down a server to an halt by: a) replaying valid packets (sending a valid payload) b) sending long invalid packets (sending an invalid payload) I would imagine both of these would cause a considerable amount of load on the destination server given they wouldn't be blocked by the providers themselves and would be allowed to reach the destination before being interpreted - in fact, I would even go as far as to say that "all the TCP denial of service attacks we've seen over the last 40+ years will be applicable to this" given the server will have the burden of validating ALL traffic at destination. Are there built-in protections against this, David Bombal or Robin Marx? Given the header information is inside the encrypted payload, I don't think there is a way around this?

[@autohmae]

Please tell me how QUIC and HTTPS are different from a firewall / traffic monitoring perspective ? The only difference is that the vendor might not yet support the UDP-based protocol. Surprisingly on the server side their is a bigger problem: good UDP offloading support. A good fast path in and out of the server through the whole stack. That said: QUIC itself (with help of TLS/1.3) as I understood it for regular traffic puts less load on the server than what came before it (especially TLS/1.2)

[@TricksterRad]

I mean, are firewall vendors blocking HTTPS/TLS? Because in the way, QUIC is identical.

[@user-lb1ib8rz4h]

@@TricksterRad corporate firewalls may use SNI rather than IP addresses for filtering, and using SNI involves more work in QUIC

[@truegret7778]

Fascinating update. Thank you Will other protocols (FTP/SFTP/SMTP/TFTP/DNS) be updated as well?

[@bryancourage1788]

Great content ❤️

[@davidbombal]

Thank you!

[@TheDirge69]

Excellent video, thanks!

[@davidbombal]

Glad you liked it!

[@drtrend4995]

Sir david bombal i respect and like your videos you are great👍

[@davidbombal]

Thank you so much 😀

[@cyberdevil657]

I respect people who respect David 😁