My guess is that since the packet is officially reserved and should not be set, a common firewall or other security appliance considers said packets to be malformed and drops them as a default behavior.
> So now we know that sites target this bit to block, but the real question is why? Is it that someone didn’t see the date of the RFC, maybe sarcasm doesn’t translate very well, possibly someone in the real world actually sent the evil bit when doing evil things, and cause some products to target it?
The evil bit could be something of a self-fulfilling prophecy. Because no one uses it, that makes it a source of bugs/vulnerabilities; therefore, anyone setting it deliberately but not maliciously (such as for a joke) will want to turn it off; only those who want to exploit it maliciously will keep it turned on; hence, anything with an evil bit can be safely assumed to be, in fact, evil, and it should be filtered out automatically.
If you're a firewall vendor, it seems like a no-lose situation to drop packets with the evil bit. Either someone's experimenting like in this blog post, and you look cool because you implemented an April Fool's RFC, or someone is actually sending malicious packets, and you look like a competent firewall. Imagine if you didn't drop the packets with the evil bit, and a hacker thinks it's funny to add the bit to their packets while they're exploiting some unrelated vulnerability in your software. The post-mortems and exploit writeups would make you look incompetent - "this firewall vendor can't even stop packets that announce their evil intentions!"
> Packets with the evil bit off MUST NOT be dropped.
That seems to be at odds with standard firewall operation, that may choose to drop packets because of all sorts of reasons unrelated to the "Evil bit". This would seem to constrain their operations unnecessarily, and so I would say that it is in the best interest of security vendors to ignore most of this RFC as frivolous and not binding.
That seems crazy. When a new spec comes out and a previously reserved bit starts meaning something, you really don’t want old software to just drop packets as malformed. Reserved means ignore, not an assertion that it must be zero.
gwern|2 years ago
The evil bit could be something of a self-fulfilling prophecy. Because no one uses it, that makes it a source of bugs/vulnerabilities; therefore, anyone setting it deliberately but not maliciously (such as for a joke) will want to turn it off; only those who want to exploit it maliciously will keep it turned on; hence, anything with an evil bit can be safely assumed to be, in fact, evil, and it should be filtered out automatically.
wwalexander|2 years ago
> Devices such as firewalls MUST drop all inbound packets that have the evil bit set.
TechBro8615|2 years ago
NoZebra120vClip|2 years ago
> Packets with the evil bit off MUST NOT be dropped.
That seems to be at odds with standard firewall operation, that may choose to drop packets because of all sorts of reasons unrelated to the "Evil bit". This would seem to constrain their operations unnecessarily, and so I would say that it is in the best interest of security vendors to ignore most of this RFC as frivolous and not binding.
TZubiri|2 years ago
jackbondpreston|2 years ago
Terr_|2 years ago
unknown|2 years ago
[deleted]
NotYourLawyer|2 years ago
tsimionescu|2 years ago