fw: a fragmented datagram crosses

Only the first fragment of a datagram carries the transport header, so
every later one matched no port, and a rule set written in ports --
which is every rule set in fwrules(6) -- denied it.  Measured, 3000
bytes of UDP over a 1500 mtu, against a rule permitting the port:

	passed 1
	dropped 2

The first fragment crossed and the receiver waited for the rest until
it gave up.  The alternative this replaced was worse: reading ports out
of a later fragment lets one whose payload bytes happen to look like an
open connection through, which is a firewall evasion older than most
firewalls.

So the first fragment decides and the rest of the train inherits.  The
train is what the receiving stack reassembles on -- protocol,
addresses, identification -- and lasts about as long as that stack will
hold the pieces.  A train whose head we never saw is judged on its
addresses alone, and so is normally denied: it is either an attack or
the tail of a datagram we already refused.  Same measurement after:

	passed 3
	dropped 0

and one rule decision for the datagram rather than one per fragment.
IPv6 fragments live in an extension header, which fw does not walk, so
none of this reaches them; that stays in BUGS.

Four checks, three of which fail against the previous fw.c.  The fourth
-- the far stack's own InDatagrams -- is read as a difference across
the exchange, not a total: an IP stack outlives the run that made it,
and reading the total made the check pass on a build that had dropped
two thirds of the datagram.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions