<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>RFC 9000 on</title><link>https://seemann.io/tags/rfc-9000/</link><description>Recent content in RFC 9000 on</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Wed, 08 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://seemann.io/tags/rfc-9000/index.xml" rel="self" type="application/rss+xml"/><item><title>Using nftables for QUIC load balancing</title><link>https://seemann.io/posts/2026-04-08---nftables-quic-load-balancing/</link><pubDate>Wed, 08 Apr 2026 00:00:00 +0000</pubDate><guid>https://seemann.io/posts/2026-04-08---nftables-quic-load-balancing/</guid><description>Using nftables to load balance QUIC connections</description></item><item><title>A p2p Vision for QUIC</title><link>https://seemann.io/posts/2024-10-26---p2p-quic/</link><pubDate>Sat, 26 Oct 2024 00:00:00 +0000</pubDate><guid>https://seemann.io/posts/2024-10-26---p2p-quic/</guid><description>Using QUIC to achieve everything needed for NAT traversal, from address discovery to proxying UDP</description></item><item><title>Exploiting QUIC’s Connection ID Management</title><link>https://seemann.io/posts/2024-03-19---exploiting-quics-connection-id-management/</link><pubDate>Tue, 19 Mar 2024 00:00:00 +0000</pubDate><guid>https://seemann.io/posts/2024-03-19---exploiting-quics-connection-id-management/</guid><description>&lt;p&gt;QUIC’s connection ID issuance mechanism is vulnerable to a resource exhaustion attack similar to the recently reported &lt;a href="https://seemann.io/posts/2023-12-18-exploiting-quics-path-validation/" target="_blank"&gt;attack against QUIC’s path validation mechanism&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;I discovered this vulnerability in December 2023 and disclosed it to the IETF QUIC working group. Among 17 QUIC stacks surveyed, 11 were found vulnerable, including my own (&lt;a href="https://github.com/quic-go/quic-go" target="_blank"&gt;quic-go&lt;/a&gt;), &lt;a href="https://github.com/cloudflare/quiche" target="_blank"&gt;Cloudflare quiche&lt;/a&gt;, &lt;a href="https://github.com/mozilla/neqo" target="_blank"&gt;Neqo&lt;/a&gt; (Mozilla), &lt;a href="https://github.com/litespeedtech/lsquic" target="_blank"&gt;lsquic&lt;/a&gt; (LiteSpeed) and &lt;a href="https://github.com/microsoft/msquic" target="_blank"&gt;MsQuic&lt;/a&gt; (Microsoft). Due to the large number of affected implementations, and the lengthy release cycles of some of them, the disclosure of this vulnerability only happened on March 12th. Since then, most affected implementations have released fixes.&lt;/p&gt;</description></item><item><title>Exploiting QUIC's Path Validation</title><link>https://seemann.io/posts/2023-12-18---exploiting-quics-path-validation/</link><pubDate>Mon, 18 Dec 2023 00:00:00 +0000</pubDate><guid>https://seemann.io/posts/2023-12-18---exploiting-quics-path-validation/</guid><description>&lt;p&gt;QUIC supports connection migration, allowing the client to migrate an established QUIC connection from one path to the other.
QUIC’s path validation mechanism can be used to attack the peer and make it consume an unbounded amount of memory. While there have been a number of vulnerabilities in various QUIC implementations, this vulnerability is the first attack against the QUIC protocol itself, i.e. any RFC 9000-compliant implementation is necessarily vulnerable to this attack.&lt;/p&gt;</description></item></channel></rss>