[FUGSPBR] OFF - The Security Flag in the IPv4 Header
Giovanni P. Tirloni
gpt em tirloni.org
Ter Abr 1 12:05:54 BRT 2003
Agora ficou fácil ;-)
* Marcus Voloch (bsd em voloch.net) wrote:
> > -----Original Message-----
> > From: Russ [mailto:Russ.Cooper em RC.ON.CA]
> > Sent: Tuesday, April 01, 2003 6:49 AM
> > To: NTBUGTRAQ em LISTSERV.NTBUGTRAQ.COM
> > 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: bellovin em acm.org
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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
> > RI em postal.trusecure.com
> > 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/
Mais detalhes sobre a lista de discussão freebsd