RFC 3514 | Evil Bit_rfc3514-优快云博客

本文链接：https://blog.youkuaiyun.com/u013669912/article/details/145695261

注：本文为 “Evil Bit” 相关文章、规范合辑。

机翻，未校。

The Evil Bit

邪恶位

APR 01 2013
BY LUIS ROCHA
INTRUSION ANALYSIS

It was in 2003 that the Internet Engineering Task Force (IETF) released the Request For Comments (RFC) 3514 “The Security Flag in the IPv4 Header” authored by Steve Bellovin.

2003 年，互联网工程任务组（IETF）发布了由 Steve Bellovin 撰写的征求意见书（RFC）3514 “IPv4 报头中的安全标志”。

This RFC brought to the Internet community what could have been the security silver bullet. What do you mean? Well, due to the fact that security devices like firewalls, intrusion detection systems, proxies and others have a hard time trying to determine if a packet has malicious intent or is rather normal. Steve Bellovin came up with the idea of creating the Evil bit, taking advantage of the unused high - order bit of the IP Flags field.

此 RFC 为互联网社区带来了本可能成为安全灵丹妙药的东西。这是什么意思呢？嗯，由于防火墙、入侵检测系统、代理等安全设备很难判定一个数据包是具有恶意意图还是正常的。Steve Bellovin 想出了创建 “邪恶位” 的主意，利用 IP 标志字段中未使用的高阶位。

Very simple mechanism! Consider this: benign packets should have the Evil Bit set to 0 and those that have malicious intent will have the Evil Bit set to 1.

非常简单的机制！设想一下：良性数据包的 “邪恶位” 应设置为 0，而具有恶意意图的数据包的 “邪恶位” 应设置为 1。

How does it work? When using offensive tools or crafting packets with malicious intent. The software or the attacker must set the Evil bit. For example fragments that are dangerous must have the Evil bit set. When executing a port scanning if the intent is malicious the Evil bit should be set. When sending an exploit via Metasploit the Evil bit should be set and the list goes on. On the other hand if the packets don’t have malicious intent the bit should not be set.

它是如何工作的呢？当使用攻击性工具或恶意构造数据包时，软件或攻击者必须设置 “邪恶位”。例如，危险的分片必须设置 “邪恶位”。执行端口扫描时，如果意图是恶意的，就应设置 “邪恶位”。通过 Metasploit 发送漏洞利用程序时，也应设置 “邪恶位”，诸如此类。另一方面，如果数据包没有恶意意图，就不应设置该位。

How should the security systems process such packets?

安全系统应如何处理此类数据包呢？

When processing packets, devices such as firewall should check the Evil Bit. If it is set they must drop all packets. If the Evil bit if off the packets must not be dropped.

在处理数据包时，像防火墙这样的设备应检查 “邪恶位”。如果该位被设置，就必须丢弃所有数据包。如果 “邪恶位” 未设置，则不应丢弃数据包。

Wonderful idea, but for those who don’t know the RFC was released on the April Fools’ Day. The Evil bit RFC was published on 1st April of 2003. Like many others, this has been another humorous RFC. Humorous Request for Comments have been around for quite some time and is a good read if you have time and want to laugh.

这是个很棒的主意，但对于那些不知道该 RFC 是在愚人节发布的人来说，可能会有所误解。“邪恶位” RFC 于 2003 年 4 月 1 日发布。和许多其他 RFC 一样，这也是一个幽默的 RFC。幽默的征求意见书已经存在很长时间了，如果你有时间并且想开怀一笑，那它是不错的读物。

Apart of the Evil bit one that is really hilarious is the RFC 5841 which proposes a TCP option to denote packet mood. For example happy packets which are happy because they received their ACK return packet within less than 10ms. Or the Sad Packets which are sad because they faced retransmission rates greater than 20% of all packets sent in a session. If you want to read more the Wikipedia as its complete list here or the book “The Complete April Fools’ Day RFC“.

除了 “邪恶位”，RFC 5841 也非常有趣，它提出了一个 TCP 选项来表示数据包的情绪。例如，“快乐数据包” 之所以快乐，是因为它们在不到 10 毫秒内收到了 ACK 返回数据包。而 “悲伤数据包” 则因为在一个会话中面临的重传率超过所发送所有数据包的 20% 而悲伤。如果你想了解更多，可以查看维基百科的完整列表，或者阅读《愚人节 RFC 全集》。

Humor apart and for the sake of curiosity you could try to determine if any system process or reply to such packets. I used Scapy which is a powerful packet crafting and manipulation tool. It is written in python and let’s see how could we generate a TCP Syn packet with the Evil Bit set.

抛开幽默成分，出于好奇，你可以尝试确定是否有任何系统会处理或回复此类数据包。我使用了 Scapy，它是一个强大的数据包构造和操作工具，用 Python 编写。让我们看看如何生成一个设置了 “邪恶位” 的 TCP Syn 数据包。

Before creating the packet lets just refresh our knowledge about the IP Flags field. In the IP header there 3 bits used for flags and according to the RFC 791:

在创建数据包之前，让我们先回顾一下关于 IP 标志字段的知识。在 IP 报头中，有 3 位用于标志，根据 RFC 791：

Bit 0: reserved, must be zero
位 0：保留，必须为零
Bit 1: (DF) 0 = May Fragment, 1 = Don’t Fragment.
位 1：（DF）0 = 可以分片，1 = 不分片。
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.
位 2：（MF）0 = 最后一个分片，1 = 更多分片。

The normal combinations used with Fragmentation flags are shown in the following table:

下表展示了与分片标志一起使用的常规组合：

MF Bit	Frag Offset	Meaning
Not Set	Zero	Not Fragmented
Set	Zero	First Fragment
Set	Non Zero	Middle Fragment
Not Set	Non Zero	Last Fragment

MF Bit	Frag Offset	Meaning
未设置	零	未分片
设置	零	第一个分片
设置	非零	中间分片
未设置	非零	最后一个分片

In our case we want to generate a packet that has the highest order bit of the Fla View Post gs field set i.e. Evil Bit.

在我们的例子中，我们想要生成一个数据包，其 Flags 字段的最高位（即 “邪恶位”）被设置。

Which according to the RFC is reserved and must be set zero. However, we will use Scapy to craft a packet that has the Evil bit set with a fragment offset of zero and send it trough the wire and capture it using tcpdump.

根据 RFC，该位是保留的，必须设置为零。然而，我们将使用 Scapy 构造一个数据包，将 “邪恶位” 设置为 1 且分片偏移量为零，然后通过网络发送它，并使用 tcpdump 捕获它。

#cat myevilpacket.py
#!/usr/bin/python
from scapy.all import *
ip=IP (src="192.168.1.121", dst="192.168.1.2", flags=4, frag=0)
tcpsyn=TCP (sport=1500, dport=80, flags="S", seq=4096)
send (ip/tcpsyn)
# python myevilpacket.py

I will leave the Scapy explanation for another post but would like to briefly mention the usage of flags = 4. As you could see in the IPv4 header image the IP Flags field uses 3 bits. These 3 bits are the highest bits in the 6th byte of the IP Header. To set the Evil bit we need to set the value to 100 in binary or 4 in hex/integer.

简要提及一下 flags = 4 的用法。正如你在 IPv4 报头图中所见，IP 标志字段使用 3 位。这 3 位是 IP 报头第 6 个字节中的最高位。要设置 “邪恶位”，我们需要将值设置为二进制的 100，即十六进制 / 十进制的 4。

The following picture illustrates the packet that was captured using tcpdump when the myevilpacket.py script was invoked You could see the Evil bit on.

下图展示了调用 myevilpacket.py 脚本时使用 tcpdump 捕获的数据包。你可以看到 “邪恶位” 已开启。

Evil bit

邪恶位

The evil bit is a fictional IPv4 packet header field proposed in RFC 3514, a humorous April Fools’ Day RFC from 2003 authored by Steve Bellovin. The RFC recommended that the last remaining unused bit in the IPv4 packet header be used to indicate whether a packet had been sent with malicious intent, thus making computer security engineering an easy problem.

“邪恶位” 是 RFC 3514 中提出的一个虚构的 IPv4 数据包报头字段，RFC 3514 是 Steve Bellovin 在 2003 年愚人节发布的一个幽默的 RFC。该 RFC 建议使用 IPv4 数据包报头中最后一个未使用的位来表示数据包是否是出于恶意发送的，这样一来，计算机安全工程似乎就成了一个简单的问题。

The joke is that it is impossible to come up with a rigorous yes - or - no definition of what constitutes an “evil” packet, which is a necessarily subjective human value judgement. Even if such a definition existed, a host on the other side of an untrusted network could not be trusted to set the bit correctly.

这个笑话的关键在于，要对什么是 “邪恶位” 数据包给出一个严格的是或否的定义是不可能的，这必然是一种主观的人类价值判断。即使存在这样的定义，也不能相信不受信任网络另一端的主机能够正确设置该位。

The evil bit has become a synonym for all attempts to seek simple technical solutions for difficult human social problems, in particular efforts to implement Internet censorship using simple technical solutions.

“邪恶位” 已经成为所有试图为复杂的人类社会问题寻找简单技术解决方案的代名词，特别是那些使用简单技术方案来实施互联网审查的尝试。

The evil bit also became a noteworthy in - joke in Slashdot. News about the publication of this RFC was posted in Slashdot dozens of times, reworded each time, among other April Fools stories, poking humour at the common criticism of Slashdot often posting duplicate stories.

“邪恶位” 在 Slashdot 中也成为了一个值得注意的圈内笑话。关于这个 RFC 发布的新闻在 Slashdot 上被发布了数十次，每次都重新措辞，夹杂在其他愚人节故事中，对 Slashdot 经常发布重复故事的普遍批评进行了幽默调侃。

As a joke, FreeBSD implemented this on the same day but removed the changes on the following day.[1]
开个玩笑，FreeBSD 在同一天实现了这一设定，但在第二天就移除了这些更改。[1]

This RFC has also been quoted in the otherwise completely serious RFC 3675, “.sex Considered Dangerous”, which may have caused the proponents of.xxx to wonder whether the Internet Engineering Task Force (IETF) was commenting on their application for a top - level domain (TLD) - the document was not related to their application.

此 RFC 也在完全严肃的 RFC 3675 “.sex Considered Dangerous” 中被引用，这可能让.xxx 的支持者怀疑互联网工程任务组（IETF）是否在评论他们的顶级域名（TLD）申请 —— 但该文档与他们的申请并无关联。

RFC 3514: The Security Flag in the IPv4 Header

RFC 3514: IPv4 报头中的安全标志

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

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 报头中定义一个安全标志，以此作为区分这两种情况的一种方式。

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.
防火墙 [CBR03]、数据包过滤器、入侵检测系统等通常难以区分具有恶意意图的数据包和那些仅仅是不寻常的数据包。问题是做出这样的判定很困难。为了解决这个问题，我们在 IPv4 [RFC791] 头中定义了一个安全标志，称为 “邪恶位” 位。良性数据包将该位设置为 0；用于攻击的数据包将把该位设置为 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].
本文件中出现的关键词 “必须（MUST）”、“不得（MUST NOT）”、“必需（REQUIRED）”、“应（SHALL）”、“不应（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“建议（RECOMMENDED）”、“可以（MAY）” 和 “可选（OPTIONAL）”，应按照 [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.
IP 片段偏移量字段的高位是 IP 报头中唯一未使用的位。相应地，该位位置的选择并非由 IANA 决定。
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.)
- 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，则数据包具有恶意。安全系统应设法保护自己免受此类数据包的攻击。不安全的系统可能会选择崩溃、被渗透等。

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.
有多种方式可以设置 “邪恶位”。攻击应用程序可以使用合适的 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.
一些主机以一种可能会触发入侵检测系统警报的方式扫描其他主机。如果扫描是良性研究项目的一部分，则绝不能设置 “邪恶位”。如果扫描本身是无害的，但最终意图是恶意的，并且目标站点有这样的入侵检测系统，那么应该设置 “邪恶位”。

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.
防火墙等设备必须丢弃所有设置了 “邪恶位” 的入站数据包。未设置 “邪恶位” 的数据包不得丢弃。丢弃的数据包应记录在相应的 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.
入侵检测系统（IDS）面临更棘手的问题。由于其众所周知的误报和漏报倾向，IDS 在评估 “邪恶位” 时必须应用概率校正因子。如果设置了 “邪恶位”，必须参考合适的随机数生成器 [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.
这些测试的默认概率取决于 IDS 的类型。因此，基于签名的 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.
如前所述，主机对恶意数据包的处理取决于操作系统；然而，所有主机都必须根据其自身特性做出适当反应。

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.
尽管本文档仅定义了 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 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.
对于 IPv6 [RFC2460]，恶意程度通过两个选项来传达。第一个是逐跳选项，用于破坏网络的数据包，如 DDoS 数据包。第二个是端到端选项，用于旨在破坏目标主机的数据包。在这两种情况下，该选项都包含一个 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.
一些链路层，特别是基于光交换的链路层，可能会完全绕过路由器（进而绕过防火墙）。因此，必须使用一些链路层方案来表示恶意。这可能涉及恶意波长、恶意极化等。
DDoS attack packets are denoted by a special diffserv code point.
DDoS 攻击数据包由一个特殊的区分服务代码点（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.
为通过 Web 或电子邮件传播的恶意行为定义了一种应用程序 / 恶意 MIME 类型。其他 MIME 类型可以嵌入恶意部分内部；这使得使用宏病毒等对文字处理文档进行编码变得容易。

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].
本文档定义了该位的 0x0 和 0x1 值对应的安全元素的行为。该位其他值的行为只能由 IETF 达成共识后 [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.
安全机制的正确运行关键取决于 “邪恶位” 的正确设置。如果有故障的组件在适当的时候没有将 “邪恶位” 设置为 1，防火墙将无法正常工作。同样，如果该位在不应设置为 1 的时候被设置了，可能会发生拒绝服务的情况。

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.
[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@acm.org

10. Full Copyright Statement

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.
本文件及其中包含的信息按 “原样” 提供，互联网协会和互联网工程任务组不承担所有明示或暗示的保证，包括但不限于任何关于使用本文信息不会侵犯任何权利的保证，或对适销性或特定用途适用性的任何默示保证。