RFC 3514:The Security Flag in the IPv4 Header
RFC-Ref

Bit


Click on the red underlined text to get to the source

... is that making such determinations is hard. To solve this problem, we define a security flag, known as the "evil" bit, in the IPv4 [RFC791 ...
... [RFC791] header. Benign packets have this bit set to 0; those that are used for an attack will have the bit ...
... bit set to 0; those that are used for an attack will have the bit set to 1. ...


... The high-order bit of the IP fragment offset field is the only unused ...
... IP fragment offset field is the only unused bit in the IP header. Accordingly, the selection of the bit position ...
... bit in the IP header. Accordingly, the selection of the bit position is not left to IANA. ...
... IANA. The bit field is laid out as follows: 0 ...
... Currently-assigned values are defined as follows: 0x0 If the bit is set to 0, the packet has no evil intent. Hosts, network elements ...
... operating systems.) 0x1 If the bit is set to 1, the packet has evil intent. Secure systems SHOULD try to defend themselves against such packets. Insecure systems MAY chose to crash, be penetrated, etc. ...


... Setting the Evil Bit ...
... There are a number of ways in which the evil bit may be set. Attack applications may use a suitable API ...
... operating systems may have special levels for attack programs; the evil bit MUST be set by default on packets emanating from programs running at such levels. However, the system MAY provide an API ...
... Fragments that by themselves are dangerous MUST have the evil bit set. If a packet with the evil bit set is fragmented by an ...
... Fragments that by themselves are dangerous MUST have the evil bit set. If a packet with the evil bit set is fragmented by an intermediate router and the fragments ...
... router and the fragments themselves are not dangerous, the evil bit MUST be cleared in the fragments, and MUST be turned back on in the reassembled packet. ...
... connections. Packets to such systems that are intended to be relayed to a target SHOULD have the evil bit set. Some applications hand-craft their own packets. If these packets are ...
... Some applications hand-craft their own packets. If these packets are part of an attack, the application MUST set the evil bit by itself. In networks ...
... hosts inside the firewall MUST NOT set the evil bit on any packets. Because NAT ...
... NAT [RFC3022] boxes modify packets, they SHOULD set the evil bit on such packets. "Transparent" http and email proxies SHOULD set ...
... email proxies SHOULD set the evil bit on their reply packets to the innocent client host. ...
... alert intrusion detection systems. If the scanning is part of a benign research project, the evil bit MUST NOT be set. If the scanning per se is innocent, but the ultimate intent is evil and the destination site ...
... destination site has such an intrusion detection system, the evil bit SHOULD be set. ...


... Processing of the Evil Bit ...
... Devices such as 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 ...
... 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. ...
... IDSs MUST apply a probabilistic correction factor when evaluating the evil bit. If the evil bit is set, a suitable random number generator ...
... MUST apply a probabilistic correction factor when evaluating the evil bit. If the evil bit is set, a suitable random number generator [RFC1750 ...
... [RFC1750] must be consulted to determine if the attempt should be logged. Similarly, if the bit is off, another random number generator must be consulted to determine if it should be logged ...
... Routers that are not intended as as security devices SHOULD NOT examine this bit. This will allow them to pass packets at higher speeds. ...


... Although this document only defines the IPv4 evil bit, there are complementary mechanisms for other forms of evil. We sketch some of those here. ...
... destination hosts. In either case, the option contains a 128-bit strength indicator, which says how evil the packet is, and a 128-bit type code ...
... option contains a 128-bit strength indicator, which says how evil the packet is, and a 128-bit type code that describes the particular type of attack ...


... security elements for the 0x0 and 0x1 values of this bit. Behavior for other values of the bit may be defined only by IETF ...
... 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 ...


... Correct functioning of security mechanisms depend critically on the evil bit being set properly. If faulty components do not set the evil bit to 1 when appropriate, firewalls ...
... evil bit being set properly. If faulty components do not set the evil bit to 1 when appropriate, firewalls will not be able to do their jobs properly. Similarly, if the bit ...
... bit to 1 when appropriate, firewalls will not be able to do their jobs properly. Similarly, if the bit is set to 1 when it shouldn't be, a denial of service condition may occur. ...



Google
Web
RFC-Ref