RFC 3514 Gave IPv4 an "Evil Bit" That Attack Packets Must Set So Firewalls Can Drop Them

The premise fits in one sentence of the spec. “Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1.” Bellovin picked his real estate carefully: “The high-order bit of the IP fragment offset field is the only unused bit in the IP header,” and RFC 3514 claims it.

From there the document follows the form of a standards-track spec with a straight face. Attack software has to ask for the bit: “Attack applications may use a suitable API to request that it be set. Systems that do not have other mechanisms MUST provide such an API; attack programs MUST use it.” Hosts behind a firewall MUST NOT set it, because “it is axiomatic that all attackers are on the outside of the firewall.” Firewalls “MUST drop all inbound packets that have the evil bit set.” A receiving host that sees the bit at 0 “SHOULD assume that the packet is harmless,” followed by the parenthetical that “this part of the spec is already implemented by many common desktop operating systems.” One that sees a 1 may respond in kind: “Insecure systems MAY chose to crash, be penetrated, etc.”

It goes further than the header. IPv6, the RFC says, will need a “128-bit strength indicator, which says how evil the packet is,” and an “application/evil” MIME type is defined for good measure. The security considerations section names the only weak spot it admits to: “If faulty components do not set the evil bit to 1 when appropriate, firewalls will not be able to do their jobs properly.”

Some people took it at face value. Bellovin keeps a page of reactions to RFC 3514 that includes emails from readers asking whether the bit was real, among them a message signed with a Microsoft Corporation signature asking “what keeps the hacker from spoofing this process by setting the bit to “good”?” The same page records that FreeBSD developer mdodd committed “Implement support for RFC 3514” at 00:21 Pacific on April 1, 2003, with a socket option named IP_EVIL_INTENT, sysctls called net.inet.ip.hear_no_evil and net.inet.ip.speak_no_evil, a ping -E flag, and a counter for evil packets seen. Bellovin later wrote on the NANOG mailing list in 2012 that “Code was added to FreeBSD to set it (though I think the commit was later reverted).”

The joke had a working test case by 2015. Ben Cox patched a Linux kernel to set the bit on every outgoing packet, writing that “I have not been able to find any attempt at having this in the Linux kernel, so I made a patch,” and measured what broke. Two weeks of everyday browsing turned up a failure at freedesktop.org, and all of Portland State University’s address space dropped the packets. A scan of popular domains found 23 that failed only for the evil-bit machine: 13 universities, four banking or payment sites, and six software companies, Kaspersky and TeamViewer among them. “I highly suspect the thing that links all of these sites together is a common appliance,” he wrote. Bellovin’s reactions page notes the same thing from another Linux build that always sets the bit: “Unfortunately, it turns out that there are sites that always block such packets.” Which appliance does it, and whether it still does, nobody has published.

The likely outcome, with high confidence, is that the evil bit outlives everyone who wrote the filter that drops it, because firewall rule sets get copied far more often than they get audited. With lower confidence, a vendor will one day quietly remove the check once a real protocol needs that header bit and a customer complains. The fun one, speculative, is that a future “zero trust” product cites RFC 3514 in its marketing without the joke.