Subject: Re: ip_flow.c
To: Ignatios Souvatzis <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/27/1999 15:27:52
> 1) There's no need to check both ipforwarding and ipflow_inuse.
No-one has disagreed with this yet...
> 2) There's no need to check the header checksum.
Nope. rfc1812 says you have to check it. You can elide recomputing it
on ouptut If, and only if, change the TTL field is modified, using
incremental checksum update, as per rfc1812. The algorithm is in
rfc1624 (whcih is informational only); rfc1812 cites 1141, but the
algorithm there has a bug.
> 3) There's no need to check the IP packet length.
Wrong. rfc1812, sec 5.2.2. Five checks are mandatory. The fifth mandatory
test is to check the IP total length is big enough for a minimum-sized
header. Thats the only use of ip_len I can find in ip_flow.c.
We should even do better, IMHO: the marginal cost to also check the IP
total length against m_pkthdr.len is trivial (we've already pulled out
ip_len and converted it to host byteorder).
It's also recommended (ibid):
Additionally, the router SHOULD verify that the packet length
reported by the Link Layer is at least as large as the IP total
length recorded in the packet's IP header. If it appears that the
packet has been truncated, the packet MUST be discarded, the error
SHOULD be logged, and the router SHOULD respond with an ICMP
Parameter Problem message whose pointer points at the IP total length
If a router is getting a lot of packets with bad header checksums (and
My data (I'm gathering real traces of bad packets and retransmits)
says 1 in 5,000 is a lot. Even a sysctl doesn't make much sense here:
checking the sysctl flag will cost as much as the length check.
I'd just leave the m_pkthdr check in.
That just leaves trimming packets received in padded frames. Bill
Sommerfeld's answer was solid. I'd just add that, roughly, one in
every 3 TCP packets is a bare ACK, so the padding objection of
Ethernet into (ATM cells or slow links) is fairly weighty.