Agora ficou f�cil ;-) * Marcus Voloch ([EMAIL PROTECTED]) wrote: > > -----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/
-- Giovanni P. Tirloni http://www.tirloni.org _______________________________________________________________ Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
