[FUGSPBR] OFF - The Security Flag in the IPv4 Header
Marcus Voloch
bsd em voloch.net
Ter Abr 1 11:46:12 BRT 2003
> -----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/
Mais detalhes sobre a lista de discussão freebsd