the evil bit
loresecuritynetworking
The April Fools' RFC proposing that malicious packets simply set a header bit to declare themselves evil.
Steve Bellovin's RFC 3514 (April 1, 2003) defines a security flag in the IPv4 header: benign packets set it to 0, attack packets must set it to 1, and firewalls need only drop the marked ones. It is the field's favorite satire of every product that promises to detect intent from the wire. Whenever someone proposes trusting the sender's self-declaration, an engineer will ask if it checks the evil bit.
RFC 3514, published on 1 April 2003, proposes using a spare bit in the IPv4 header to indicate malicious intent: attackers set the evil bit, firewalls check it, security is solved. It is written entirely in specification language, complete with requirements about how compliant implementations must behave.
The joke is a critique with a precise target. Security cannot be delegated to the party being defended against, and any scheme that depends on an attacker honestly declaring themselves is not a control. Stated that plainly it is obvious, and the RFC exists because the assumption keeps reappearing in real designs.
It has aged into a genuinely useful reference. Client-side validation trusted by the server, authorization decisions based on a header the client controls, and rate limiting keyed on an identifier the caller supplies are all the evil bit with a different name, and they ship regularly. When reviewing a design, asking whether a check depends on the attacker cooperating is a fast way to find this class of flaw, and having a canonical joke to point at makes the conversation shorter than an explanation would.
Also known as: RFC 3514