> On Sep 18, 2026, at 6:45 PM, Zack Newman <[email protected]> wrote:
>
> I finally had enough time to more thoroughly test this, and I'm
> sufficiently confident the bug is entirely due to the padding bug in the
> WireGuard code. I'll explain what I did to come to this conclusion at the
> end for those that are interested, but we can now focus on just ensuring
> that padding never causes the MTU of wg(4) to be exceeded.
>
> I'll restate what I said in my last e-mail though. Namely that I believe
> it's important for someone with intimate knowledge of WireGuard to
> remain involved. I contacted Jason and the WireGuard team and suggested
> they at least reclassify wireguard-openbsd[^1] as "Abandoned" instead of
> "Active" seeing how much the OpenBSD code has deviated from that repo.
I’m sorry, what? Who are you to suggest changing the status to Abandoned? How
much has the code actually deviated? Browsing through the commit history of
if_wg.c, I am seeing routine OS-specific adjustments as the OS evolves. About
40-45 commits total for if_wg.c since its initial implementation. So one
single fragmentation bug triggered in a rare situation and now the entire thing
is Abandoned?
Is there a major protocol version update that we are missing? Are we a short
time away from becoming incompatible with other OS implementations over the
wire? What is so egregious that you consider the implementation Abandoned? Do
you understand the consequences of the implementation being marked Abandoned?
They could easily stop trying all together to bring OpenBSD up-to-date in the
future if an important change actually comes along.
> While I also politely requested at least a passive audit, that's
> unlikely without at least some correspondence with an OpenBSD dev seeing
> how the team is far more familiar with Linux than OpenBSD.
>
> Until then the best we can do is consult the whitepaper[^2], test code,
> and use the Linux implementation as a rough compass since it's the
> closest thing to a "reference" implementation that exists. I can assist
> with the former two, but I'm of no use for the latter. My formal
> background is in pure math, and I only code in Rust and Haskell-with
> some minor dabbling in formal verification in Rocq and Idris 2.
>
> Section 5.4.6 in the whitepaper talks about how messages are to be sent
> after the initial handshake using a combination of algebraic symbols and
> English prose. The table states the plaintext is padded with 0-octets
> until it has length equal to the smallest multiple of 16 greater than or
> equal to the length of the original plaintext; _however_ it also states
> below that the following:
>
>> The encapsulated packet itself is zero padded (without modifying the IP
>> packet’s length field) before encryption to complicate traffic analysis,
>> though that zero padding should never increase the UDP packet size
>> beyond the maximum transmission unit length.
>
> So the code needs to explicitly guard against padding "overflowing" the
> MTU of wg(4) (i.e., truncate to the MTU of wg(4) in the event it's
> exceeded).
>
> The rest that is written can be ignored for those uninterested in
> understanding the asymmetry with non-vio(4) interfaces or IPv4.
>
> Björn suggested that many VPS networks drop IPv6 fragments, and I was
> apparently too dumb to understand what he meant. I misinterpreted that
> as my VPS provider blocking ICMPv6 type 2 (i.e., "Packet too big") which
> they don't. My VPS provider either explicitly or implicitly via the
> hypervisor blocks egress IPv6 UDP fragments. It has no problem receiving
> IPv6 UDP fragments. I tested this with nc(1) and tcpdump(8). When I send
> a UDP payload greater than 1452 bytes, tcpdump(8) captures multiple
> fragments being sent while also not capturing anything on the target. I
> tested this on a Linux-based OS as well, and the same behavior happened.
>
> As to why IPv4 doesn't experience problems, I asked Claude; but you can
> search using your favorite search engine or ask your favorite LLM. The
> TL;DR provided by Claude was that IPv6 fragmentation handling is much
> more complex than IPv4 and historically a source of evasion bugs, so
> it's common for hardware/software to detect and handle IPv4 fragmentation
> while dropping IPv6 fragments.
>
> [^1]: https://git.zx2c4.com/wireguard-openbsd/
> [^2]: https://www.wireguard.com/papers/wireguard.pdf
>
