RFC 3514

The Security Flag in the IPv4 Header

📅 published April 2003, from ietf

okay bestie, we're doing RFC 3514 today 🎀 it's titled The Security Flag in the IPv4 Header ✨

Request for Comments: 3514 Author: Steven M. Bellovin (S. Bellovin), AT&T Labs Research 🦋 Category: Informational (it's info only, not a standard!) 🌸 Date: 1 April 2003 🍓 Obsoletes / Updates: neither. The title block doesn't list anything it replaces or changes 🫶

Status of this Memo 💅

this memo gives info to the Internet community. it doesn't specify an Internet standard of any kind. distribution is unlimited, so share it with everyone 💖

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🌈

okay so firewalls, packet filters, intrusion detection systems, and the like have a hard time telling apart packets that are actually malicious from ones that are just weird 💀 this RFC defines a security flag in the IPv4 header to help them tell the difference 🧚

1. Introduction ✨

firewalls [CBR03], packet filters, IDSes, and friends struggle to tell malicious packets from merely unusual ones, and honestly that's because figuring it out is genuinely hard 😭 so we made a security flag, called the "evil" bit, in the IPv4 [RFC791] header. benign packets keep it at 0, and any packet used for an attack has it set to 1 🔥

1.1. Terminology 💜

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].

2. Syntax 🦋

the high-order bit of the IP fragment offset field is the only unused bit in the IP header, so IANA doesn't get to pick the bit position. it's locked in 🔒

the bit field looks like this:

             0
            +-+
            |E|
            +-+

currently assigned values:

  • 0x0: if the bit is 0, the packet has no evil intent. hosts, network elements, etc. SHOULD assume it's harmless and SHOULD NOT take any defensive measures. (fun fact: lots of common desktop OSes already do this, so this part is already real 🙈)
  • 0x1: if the bit is 1, the packet has evil intent. secure systems SHOULD try to defend themselves against it. insecure systems MAY choose to crash, get penetrated, etc. 💀

3. Setting the Evil Bit 😈

there are a few ways the evil bit can get set. attack applications can use a suitable API to ask for it to be set. systems that don't have other mechanisms MUST provide such an API, and attack programs MUST use it 🫶

multi-level insecure operating systems might have special levels for attack programs. the evil bit MUST be set by default on packets coming from programs running at those levels. however, the system MAY provide an API to let it be cleared for non-malicious activity by users who normally engage in attack behavior 👑

fragments that are dangerous on their own MUST have the evil bit set. if a packet with the evil bit set gets fragmented by an intermediate router and the fragments aren't dangerous by themselves, the evil bit MUST be cleared in the fragments, and MUST be turned back on in the reassembled packet. the glow-up arc is real 🦋

intermediate systems are sometimes used to launder attack connections. packets sent to those systems that are meant to be relayed to a target SHOULD have the evil bit set.

some applications hand-craft their own packets. if those packets are part of an attack, the application MUST set the evil bit by itself. no one's doing it for it 💅

in networks protected by firewalls, it's axiomatic that all attackers are outside the firewall. so hosts inside the firewall MUST NOT set the evil bit on any packets. 🙅‍♀️

because NAT [RFC3022] boxes modify packets, they SHOULD set the evil bit on such packets. "transparent" http and email proxies SHOULD set the evil bit on their reply packets to the innocent client host 🧚

some hosts scan other hosts in a way that can set off intrusion detection systems. if the scanning is part of a benign research project, the evil bit MUST NOT be set. if the scanning itself is innocent but the ultimate intent is evil, and the destination site has such an intrusion detection system, the evil bit SHOULD be set. 🔍

4. Processing of the Evil Bit 🔥

devices like firewalls MUST drop all inbound packets that have the evil bit set. packets with the evil bit off MUST NOT be dropped. dropped packets SHOULD be noted in the appropriate MIB variable. 🗑️

intrusion detection systems (IDSs) have a harder problem 😭 because they're known to produce false negatives and false positives, IDSs MUST apply a probabilistic correction factor when evaluating the evil bit. if the evil bit is set, a suitable random number generator [RFC1750] must be consulted to decide whether the attempt should be logged. similarly, if the bit is off, another random number generator must be consulted to decide whether it should be logged anyway.

the default probabilities for these tests depend on the type of IDS. so a signature-based IDS would have a low false positive value but a high false negative value. a suitable administrative interface MUST be provided so operators can reset these values 🎛️

routers that aren't intended as security devices SHOULD NOT examine this bit. that way they can pass packets at higher speeds 🚀

as outlined earlier, host processing of evil packets depends on the operating system. however, all hosts MUST react appropriately according to their nature. 💖

this document only defines the IPv4 evil bit, but there are complementary mechanisms for other forms of evil. we'll sketch a few here 🧚

for IPv6 [RFC2460], evilness is conveyed by two options. the first is a hop-by-hop option, used for packets that damage the network, like DDoS packets. the second is an end-to-end option, for packets meant to damage destination hosts. in either case, the option has a 128-bit strength indicator, which says how evil the packet is, and a 128-bit type code that describes the particular kind of attack intended. ⚡

some link layers, notably ones based on optical switching, can bypass routers (and so firewalls) entirely. so some link-layer scheme MUST be used to denote evil. this might involve evil lambdas, evil polarizations, etc. 🌈

DDoS attack packets are denoted by a special diffserv code point 💜

an application/evil MIME type is defined for web- or email-carried mischief. other MIME types can be embedded inside evil sections, which permits easy encoding of word processing documents with macro viruses, etc. 🦠

6. IANA Considerations 🍓

this document defines the behavior of security elements for the 0x0 and 0x1 values of this bit. behavior for other values of the bit may be defined only by IETF consensus [RFC2434]. 🫶

7. Security Considerations 🚨

okay this section is SERIOUS 😭 correct functioning of security mechanisms depends critically on the evil bit being set properly. if faulty components don't set the evil bit to 1 when appropriate, firewalls won't be able to do their jobs. similarly, if the bit is set to 1 when it shouldn't be, a denial of service condition may occur. 💀

the stakes are literally the whole security stack. set the bit right, bestie 🎀

8. References 📚

[CBR03]   W.R. Cheswick, S.M. Bellovin, and A.D. Rubin, "Firewalls
          and Internet Security: Repelling the Wily Hacker", Second
          Edition, Addison-Wesley, 2003.

[RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
          1981.

[RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness
          Recommendations for Security", RFC 1750, December 1994.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
          IANA Considerations Section in RFCs", BCP 26, RFC 2434,
          October 1998.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
          (IPv6) Specification", RFC 2460, December 1998.

[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
          Address Translator (Traditional NAT)", RFC 3022, January
          2001.

9. Author's Address 🦋

Steven M. Bellovin
AT&T Labs Research
Shannon Laboratory
180 Park Avenue
Florham Park, NJ 07932

Phone: +1 973-360-8656
EMail: bellovin@acm.org

Copyright (C) The Internet Society (2003). All Rights Reserved.

this document and translations of it can be copied and handed out to others, and derivative works that comment on or explain it, or help with implementing it, can be made, copied, published, and distributed, in whole or in part, without restriction of any kind. the condition is that the above copyright notice and this paragraph are included on all copies and derivative works. but this document itself can't be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations. the exception is if it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or if it's being translated into languages other than English 🌍

the limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns. 🫶

this document and the info in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙃

Acknowledgement 🌈

funding for the RFC Editor function is currently provided by the Internet Society. thank you, Internet Society 🫶💜

📦 where this page comes from