Network Working Group S. Bellovin
Request for Comments: 3514 AT&T Labs Research
Category: Informational 1 April 2003
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
IPv4标头中的安全标志
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.
版权所有（C）互联网协会（2003年）。版权所有。
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.
防火墙、数据包过滤器、入侵检测系统等通常难以区分具有恶意意图的数据包和那些仅仅是不寻常的数据包。我们在IPv4报头中定义一个安全标志，作为区分这两种情况的方法。
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.
防火墙[CBR03]、数据包过滤器、入侵检测系统等通常难以区分具有恶意意图的数据包和那些仅仅是不寻常的数据包。问题是做出这样的决定很难。为了解决这个问题，我们在IPv4[RFC791]头中定义了一个安全标志，称为“邪恶”位。良性数据包将该位设置为0；用于攻击的将把位设置为1。
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].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[RFC2119]中的说明进行解释。
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.
IP片段偏移量字段的高位是IP报头中唯一未使用的位。因此，位位置的选择不留给IANA。
The bit field is laid out as follows:
位字段的布局如下所示：
0 +-+ |E| +-+
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.)
0x0如果位设置为0，则数据包没有恶意。主机、网元等应假定数据包是无害的，不应采取任何防御措施。（我们注意到规范的这一部分已经由许多常见的桌面操作系统实现。）
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.
0x1如果位设置为1，则数据包具有恶意。安全系统应设法保护自己免受此类数据包的攻击。不安全的系统可能会选择崩溃、被穿透等。
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.
有很多种方法可以设置邪恶位。攻击应用程序可能会使用合适的API请求对其进行设置。没有其他机制的系统必须提供这样的API；攻击程序必须使用它。
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.
多级不安全操作系统可能具有针对攻击程序的特殊级别；在默认情况下，必须对运行在此类级别的程序发出的数据包设置邪恶位。但是，系统可能会提供一个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 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.
在受防火墙保护的网络中，所有攻击者都位于防火墙外部是不言而喻的。因此，防火墙内的主机不得在任何数据包上设置邪恶位。
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.
因为NAT[RFC3022]框修改数据包，所以它们应该在这些数据包上设置邪恶位。“透明”http和电子邮件代理应将其回复数据包上的邪恶位设置为无辜的客户端主机。
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.
一些主机以一种可以向入侵检测系统发出警报的方式扫描其他主机。如果扫描是良性研究项目的一部分，那么就不能设置有害位。如果扫描本身是无辜的，但最终目的是邪恶的，并且目标站点有这样的入侵检测系统，那么应该设置邪恶位。
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.
防火墙等设备必须丢弃所有设置了邪恶位的入站数据包。不能丢弃带有邪恶比特的数据包。丢弃的数据包应记录在相应的MIB变量中。
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.
入侵检测系统（IDSs）有一个更难的问题。由于已知的误报和误报倾向，IDSs在评估恶意比特时必须应用概率校正因子。如果设置了邪恶位，则必须咨询合适的随机数生成器[RFC1750]，以确定是否应记录尝试。类似地，如果该位关闭，则必须咨询另一个随机数生成器，以确定是否应记录该位，而不考虑设置。
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.
这些测试的默认概率取决于ID的类型。因此，基于签名的IDS将具有较低的误报值，但具有较高的误报值。必须提供适当的管理界面，以允许操作员重置这些值。
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.
如前所述，恶意数据包的主机处理依赖于操作系统；但是，所有主机必须根据其性质做出适当的反应。
Although this document only defines the IPv4 evil bit, there are complementary mechanisms for other forms of evil. We sketch some of those here.
尽管本文档仅定义了IPv4邪恶位，但其他形式的邪恶也有补充机制。我们在这里画了一些。
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
对于IPv6[RFC2460]，邪恶通过两个选项传递。第一个是逐跳选项，用于损坏网络的数据包，如DDoS数据包。第二个选项是端到端选项，用于打算损坏目标主机的数据包。在这两种情况下
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.
选项包含一个128位强度指示器（表示数据包有多邪恶）和一个128位类型代码（描述特定类型的攻击）。
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.
一些链路层，尤其是基于光交换的链路层，可能会完全绕过路由器（从而绕过防火墙）。因此，必须使用一些链路层方案来表示邪恶。这可能涉及邪恶的lambdas、邪恶的极化等。
DDoS attack packets are denoted by a special diffserv code point.
DDoS攻击数据包由一个特殊的diffserv代码点表示。
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.
为Web或电子邮件承载的恶意行为定义了应用程序/恶意MIME类型。其他MIME类型可以嵌入到邪恶的部分中；这使得使用宏病毒等对字处理文档进行简单编码成为可能。
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].
本文档定义了该位的0x0和0x1值的安全元素的行为。位的其他值的行为只能由IETF共识[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 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.
安全机制的正确运行关键取决于正确设置的邪恶位。如果有故障的组件在适当的时候没有将邪恶位设置为1，防火墙将无法正常工作。类似地，如果该位不应设置为1，则可能发生拒绝服务情况。
[CBR03] W.R. Cheswick, S.M. Bellovin, and A.D. Rubin, "Firewalls and Internet Security: Repelling the Wily Hacker", Second Edition, Addison-Wesley, 2003.
[CBR03]W.R.Cheswick、S.M.Bellovin和A.D.Rubin，“防火墙和互联网安全：击退狡猾的黑客”，第二版，Addison-Wesley，2003年。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]Eastlake，D.，3rd，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
Steven M. Bellovin AT&T Labs Research Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932
Steven M.Bellovin AT&T实验室研究香农实验室新泽西州弗洛勒姆公园公园大道180号，邮编07932
Phone: +1 973-360-8656
EMail: bellovin@acm.org
Phone: +1 973-360-8656
EMail: bellovin@acm.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。