Loved all the background information you provided. It made understanding what problems existed before QUIC, where they were and why they existed. It gave me a much better understanding and appreciation of how QUIC worked.
It's cool to enjoy this on a nerd level. great work done all the way from SPDY and now it's an IETF standard and growing fast on the internets. It's been facinating to see the iterations and now its time to finetune our networks. How does QUIC react for example to small burst-commit sizes on policers?
I can't wrap my head around how this cannot get easy spoof attacks with the flexible connectivity (I imagine only the secret key will be needed to read the data but the connection can be spoofed anyways), how UDP data loss is reported by the client to be retransmitted, or the effects retransmission on performance.
A connection ID can be up to 62 bits long. That alone makes it practically impossible for an adversary to guess an existing connection ID. Even if the connection ID is known, the secret key must then _also_ be known, which RFC 9000 §5.2 specifies: datatracker.ietf.org/doc/html/rfc9000#section-5.2 "Packets that are matched to an existing connection are discarded if the packets are inconsistent with the state of that connection. For example, packets are discarded if they indicate a different protocol version than that of the connection or if the removal of packet protection is unsuccessful once the expected keys are available." Packet delivery guarantees and congestion control mechanisms that are traditionally employed by TCP are employed by QUIC itself. See RFC 9000 §4 and §13 for details.
Hmm on reverse proxy we could offload tls1.3 from there on send it to middleboxes like ids,ips,sandbox etc forward it to webserver. Is QUIC is well leveraged to work with existing infra. Or there another way better way to adapt QUIC..?
QUIC is a transport protocol (with builtin encryption provided by TLS1.3 lib), so that http need not to sit on top of another TLS/SSL session. If you have your middle box as an endpoint, then ya you can inspect the quic packets, but then it is not a middlebox anymore.
Intelligent guy and good teacher explains things in a way "normal" people with some knowledge can understand.
Loved all the background information you provided. It made understanding what problems existed before QUIC, where they were and why they existed. It gave me a much better understanding and appreciation of how QUIC worked.
I’ve been trying to learn about quic, and this was the best video. Tell us more of the inside story.
It's cool to enjoy this on a nerd level. great work done all the way from SPDY and now it's an IETF standard and growing fast on the internets. It's been facinating to see the iterations and now its time to finetune our networks. How does QUIC react for example to small burst-commit sizes on policers?
I guess people are looking up more QUIC videos and the algorithm because it recently became a final RFC suggested it to me because of that
⭐️👍⭐️
Great presentation David. you're really know your topic
Can we get the ppt resource as well, it would be really helpful
if the camera is not moving so much *that would be great!
best on yourtube
any more videos explaining how congestion works in quic?
I can't wrap my head around how this cannot get easy spoof attacks with the flexible connectivity (I imagine only the secret key will be needed to read the data but the connection can be spoofed anyways), how UDP data loss is reported by the client to be retransmitted, or the effects retransmission on performance.
A connection ID can be up to 62 bits long. That alone makes it practically impossible for an adversary to guess an existing connection ID. Even if the connection ID is known, the secret key must then _also_ be known, which RFC 9000 §5.2 specifies: datatracker.ietf.org/doc/html/rfc9000#section-5.2
"Packets that are matched to an existing connection are discarded if the packets are inconsistent with the state of that connection. For example, packets are discarded if they indicate a different protocol version than that of the connection or if the removal of packet protection is unsuccessful once the expected keys are available."
Packet delivery guarantees and congestion control mechanisms that are traditionally employed by TCP are employed by QUIC itself. See RFC 9000 §4 and §13 for details.
Those middle box developers 😄
Great presentation！How can I get the slide?
thannks
Hmm on reverse proxy we could offload tls1.3 from there on send it to middleboxes like ids,ips,sandbox etc forward it to webserver.
Is QUIC is well leveraged to work with existing infra.
Or there another way better way to adapt QUIC..?
QUIC is a transport protocol (with builtin encryption provided by TLS1.3 lib), so that http need not to sit on top of another TLS/SSL session. If you have your middle box as an endpoint, then ya you can inspect the quic packets, but then it is not a middlebox anymore.
So sad that he hastily skipped over the most interesting bit...
Jana wallks through those at netdev: ua-cam.com/video/CtsBawwGwns/v-deo.html
the camera shakes too much bro I'm trippin 😂
To think the CCNA mentions nothing of this..
They will in 10 years
It's new.