> -----Original Message----- > From: Russ [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 01, 2003 6:49 AM > To: [EMAIL PROTECTED] > Subject: The Security Flag in the IPv4 Header > > Network Working Group S. Bellovin > Request for Comments: 3514 AT&T Labs Research > Category: Informational 1 April 2003 > > > The Security Flag in the IPv4 Header > > Status of this Memo > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > Abstract > > Firewalls, packet filters, intrusion detection systems, and the like > often have difficulty distinguishing between packets that have > malicious intent and those that are merely unusual. We define a > security flag in the IPv4 header as a means of distinguishing the two > cases. > > 1. Introduction > > Firewalls [CBR03], packet filters, intrusion detection systems, and > the like often have difficulty distinguishing between packets that > have malicious intent and those that are merely unusual. The problem > 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] header. Benign packets have this bit set to 0; those that > are used for an attack will have the bit 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. Accordingly, the selection of the bit position > is not left to IANA. > > > > > > Bellovin Informational [Page 1] > > > RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 > > > The bit field is laid out as follows: > > 0 > +-+ > |E| > +-+ > > Currently-assigned values are defined as follows: > > 0x0 If the bit is set to 0, the packet has no evil intent. Hosts, > network elements, etc., SHOULD assume that the packet is > harmless, and SHOULD NOT take any defensive measures. (We note > that this part of the spec is already implemented by many common > desktop 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. > > 3. 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 to request that it be set. > Systems that do not have other mechanisms MUST provide such an API; > attack programs MUST use it. > > Multi-level insecure 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 to allow it to be cleared for non-malicious > activity by users who normally engage in attack behavior. > > 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 themselves are not dangerous, > the evil bit MUST be cleared in the fragments, and MUST be turned > back on in the reassembled packet. > > Intermediate systems are sometimes used to launder attack > 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 > part of an attack, the application MUST set the evil bit by itself. > > In networks protected by firewalls, it is axiomatic that all > attackers are on the outside of the firewall. Therefore, hosts > inside the firewall MUST NOT set the evil bit on any packets. > > > > Bellovin Informational [Page 2] > > > RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 > > > 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 fashion that can 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 > has such an intrusion detection system, the evil bit SHOULD be set. > > 4. 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 variable. > > Intrusion detection systems (IDSs) have a harder problem. Because of > their known propensity for 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 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 > despite the setting. > > The default probabilities for these tests depends on the type of IDS. > Thus, a signature-based IDS would have a low false positive value but > a high false negative value. A suitable administrative interface > MUST be provided to permit operators to reset these values. > > Routers that are not intended as as security devices SHOULD NOT > examine this bit. This will allow them to pass packets at higher > speeds. > > As outlined earlier, host processing of evil packets is operating- > system dependent; however, all hosts MUST react appropriately > according to their nature. > > 5. Related Work > > Although this document only defines the IPv4 evil bit, there are > complementary mechanisms for other forms of evil. We sketch some of > those here. > > For IPv6 [RFC2460], evilness is conveyed by two options. The first, > a hop-by-hop option, is used for packets that damage the network, > such as DDoS packets. The second, an end-to-end option, is for > packets intended to damage destination hosts. In either case, the > > > > Bellovin Informational [Page 3] > > > RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 > > > 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 intended. > > Some link layers, notably those based on optical switching, may > bypass routers (and hence firewalls) entirely. Accordingly, some > link-layer scheme MUST be used to denote evil. This may 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 of evil sections; > this permit 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 > > 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 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. > > 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. > > > > Bellovin Informational [Page 4] > > > RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 > > > [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: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bellovin Informational [Page 5] > > > RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 > > > 10. Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is 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. > > > > > > > > > > > > > > > > > > > > Bellovin Informational [Page 6] > > > > _______________________________________________ > RI mailing list > [EMAIL PROTECTED] > http://postal.trusecure.com/mailman/listinfo/ri > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > Delivery co-sponsored by TruSecure Corporation > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > TICSA - Anniversary Special - Limited Time > > Become TICSA certified for just $221.25 US when you register before 3/31/03 > with PROMO "TS0103" at www.2test.com. NO membership fees, certification > good for 2 years. Price for international delivery just $296.25 US, with > this offer. Offer cannot be combined with any other special and expires > 3/31/03. Visit www.trusecure.com/ticsa for full details. > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > -------------------------------------------------------------------------- -- > The information transmitted in this message is intended only for the person > or entity to which it is addressed and may contain confidential and or > privileged material. If you are not the intended recipient or the employee > or agent responsible for delivering this message to the intended recipient, > you are hereby notified that any use, review, retransmission, dissemination, > distribution, reproduction or any action taken in reliance upon this message > is strictly prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and deleting it from > your computer. Views expressed in the above communication are those of the > individual sender and may not necessarily reflect the views of the > corporation. > Thank you, Trialon Corporation. >
_______________________________________________________________ Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
