Network Working Group S. Bellovin
Request for Comments: 2316 AT&T Labs Research
Category: Informational April 1998
Network Working Group S. Bellovin
Request for Comments: 2316 AT&T Labs Research
Category: Informational April 1998
Report of the IAB Security Architecture Workshop
IAB安全架构研讨会报告
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 (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning.
1997年3月3日至5日，IAB在新泽西州默里山的贝尔实验室举办了一次安全架构研讨会。我们确定了体系结构的核心安全组件，并指定了几个需要编写的文档。最重要的是，我们同意安全性不是可选的，它需要从一开始就设计好。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. The ultimate goal was to design a security architecture for the Internet. More concretely, we wished to understand what security tools and protocols exist or are being developed, where each is useful, and where we are missing adequate security tools. Furthermore, we wanted to provide useful guidance to protocol designers. That is, if we wish to eliminate the phrase "security issues are not discussed in this memo" from future RFCs, we must provide guidance on acceptable analyses.
1997年3月3日至5日，IAB在新泽西州默里山的贝尔实验室举办了一次安全架构研讨会。最终目标是为互联网设计一个安全架构。更具体地说，我们希望了解现有或正在开发哪些安全工具和协议，它们在哪些方面有用，以及我们在哪些方面缺少足够的安全工具。此外，我们希望为协议设计者提供有用的指导。也就是说，如果我们希望从未来的RFC中删除“本备忘录中未讨论安全问题”这一短语，我们必须就可接受的分析提供指导。
There were twenty-four attendees (their names are listed in Appendix A). Perhaps not surprisingly for such a group, the overwhelming majority used some form of cryptography when connecting back to their home site from the meeting room. But the situation on the rest of the Internet is not nearly as good; few people use encryption, even when they should.
共有24名与会者（他们的姓名列于附录A）。对于这样一个群体来说，绝大多数人在从会议室连接回自己的主页时使用了某种形式的加密技术，这也许并不奇怪。但互联网其他部分的情况却不尽相同；很少有人使用加密，即使他们应该这样做。
The problem is that the rate of attacks is increasing. Apart from the usual few elite hackers -- the ones who find the new holes -- there are many canned exploit scripts around. ("Click here to attack this system.") Furthermore, the attackers have gotten smarter; rather than going after random university machines, more and more are targeting the Internet infrastructure, such as routers, high-level name servers, and the like.
问题是，攻击率正在上升。除了通常为数不多的精英黑客——那些发现新漏洞的黑客——还有许多现成的利用脚本。（“单击此处攻击此系统。”）此外，攻击者变得更加聪明；越来越多的人不再追求随机的大学机器，而是瞄准互联网基础设施，如路由器、高级名称服务器等。
The problem is compounded by organizational laziness. Users and system administrators want "magic security" -- they want whatever they do to be secure, regardless of whether or not it is, or even can be.
组织上的懒惰使问题更加复杂。用户和系统管理员想要“神奇的安全”——他们希望他们所做的一切都是安全的，不管它是否安全，甚至可以安全。
We concluded that in general, end-to-end security is better. Thus, one should use something like PGP or S/MIME for email, rather than relying on an IPsec layer. In general, relying on the security of the infrastructure is a bad idea; it, too, is under attack. Even firewall-protected intranets can be subverted. At best, the infrastructure should provide availability; it is the responsibility of individual protocols not to make unreasonable demands on the infrastructure during an attack.
我们得出的结论是，总体而言，端到端安全性更好。因此，电子邮件应该使用PGP或S/MIME之类的东西，而不是依赖IPsec层。总的来说，依靠基础设施的安全是一个坏主意；它也受到了攻击。甚至受防火墙保护的内部网也可能被破坏。充其量，基础设施应提供可用性；在攻击期间，各协议有责任不对基础设施提出不合理的要求。
Our security problem is compounded by the IETF's inherent structure (or, in some cases, the lack thereof). By intent, we are a volunteer organization. Who should do the security work? The other protocol designers? Often, they have neither the time nor the interest nor the training to do it. Security area members? What if they are not interested in some subject area, or lack the time themselves? We cannot order them to serve.
IETF的固有结构（或者，在某些情况下，缺乏这种结构）加剧了我们的安全问题。出于意愿，我们是一个志愿者组织。谁应该做保安工作？其他协议设计者？通常，他们既没有时间，也没有兴趣，也没有训练去做这件事。安全区成员？如果他们对某个主题领域不感兴趣，或者他们自己缺乏时间，该怎么办？我们不能命令他们服务。
To the extent that the IETF does have management, it is embodied in the working group charters. These are in essence contracts between the IESG and a working group, spelling out what is to be done and on what schedule. Can the IESG unilaterally impose new requirements on existing working groups? What if security cannot be added on without substantial changes to the fundamental structure of a protocol that has been reworked over several years?
就IETF的管理而言，它体现在工作组章程中。这些实质上是IESG和一个工作组之间的合同，详细说明了要做什么以及时间表。IESG能否单方面对现有工作组提出新要求？如果不对经过多年修改的协议的基本结构进行实质性更改就无法增加安全性，该怎么办？
Finally, there is a perception problem: that IPsec will somehow solve the security problem. It won't; indeed, it can't. IPsec provides excellent protection of packets in transit. But it's hard to deploy on individual hosts, does not protect objects that may be retransmitted (i.e., email messages), does not address authorization issues, cannot block against excess resource consumption, etc.
最后，还有一个感知问题：IPsec将以某种方式解决安全问题。不会的；事实上，它不能。IPsec为传输中的数据包提供了极好的保护。但它很难部署在单个主机上，不保护可能被重新传输的对象（即电子邮件），不解决授权问题，无法阻止过度的资源消耗，等等。
Collectively, we decided on several documents that need to be written:
我们共同决定了几个需要编写的文件：
Taxonomy of Attacks In order to defend a protocol against attacks, one must, of course, know the kinds of attacks that are possible. While the specifics differ from protocol to protocol, a number of general categories can be constructed.
攻击分类为了保护协议免受攻击，当然必须知道可能的攻击类型。虽然每个协议的细节不同，但可以构建一些一般类别。
Implementation Hints and Pitfalls Even if a protocol is sound, a host running it can be vulnerable if the protocol is implemented improperly. A variety of common errors can and do subvert the best designs.
实现提示和陷阱即使协议是可靠的，如果协议实现不当，运行该协议的主机也可能容易受到攻击。各种常见的错误都会颠覆最佳设计。
Firewall Issues Firewalls are both a common defense and a much-reviled wart on the Internet. Regardless, they are unlikely to go away any time soon. They have both strengths and weaknesses that must be considered when deploying them. Furthermore, some protocols have characteristics that are unnecessarily firewall-hostile; such practices should be avoided.
防火墙问题防火墙既是一种常见的防御手段，也是互联网上一个备受诟病的弱点。无论如何，他们不太可能很快离开。它们既有优点，也有缺点，在部署它们时必须加以考虑。此外，一些协议具有不必要的防火墙敌对特性；应该避免这种做法。
Workshop Report This document.
研讨会报告此文档。
The actual text in the working group charter is likely to be something fairly simple, like
工作组章程中的实际文本可能相当简单，如
Protocols developed by this working group will be analyzed for potential sources of security breach. Identified threats will be removed from the protocol if possible, and documented and guarded against in other cases.
将对该工作组制定的协议进行安全漏洞潜在来源分析。如果可能，将从协议中删除已识别的威胁，并在其他情况下进行记录和防范。
The actual charter text represents a policy enjoined and enforced by the IESG, and may change from time to time and from charter to
实际的章程文本代表了IESG强制执行的政策，并且可能会随着时间和章程的变化而变化
charter. However, it essentially references and asks for text in documents conforming to the following, which may be very appropriate to include in the RFC.
宪章但是，它基本上引用并要求符合以下要求的文件中的文本，这可能非常适合包含在RFC中。
A "threat" is, by definition, a vulnerability available to a motivated and capable adversary. CERT advisories are quite predictable given a knowledge of the target of the threat; they therefore represent an existence proof, but not a threat analysis. The point is to determine what attacks are possible ("capabilities" of a potential attacker) and formulate a defense against the attacks, or convincingly argue that the attack is not realistic in some environment and restrict use of the protocol to that environment.
“威胁”顾名思义就是一个有动机、有能力的对手可以利用的弱点。鉴于对威胁目标的了解，CERT咨询是相当可预测的；因此，它们代表的是存在性证明，而不是威胁分析。关键是要确定哪些攻击是可能的（“潜在攻击者的能力”），并制定针对这些攻击的防御措施，或者有说服力地论证攻击在某些环境中不现实，并将协议的使用限制在该环境中。
Recommended guidelines:
建议的准则：
All RFCs - MUST meaningfully address security in the protocol or procedure it specifies. It MUST consider that it is giving its data to "the enemy" and asking it to be delivered to its friends and used in the manner it intended. Consideration MUST be given to the ramifications of the inherent danger of the situation.
所有RFC-必须在其指定的协议或程序中有意义地解决安全问题。它必须考虑到它将数据交给“敌人”，并要求它传递给它的朋友，并按照它的意图使用。必须考虑到局势固有危险的后果。
- MUST do "due diligence" to list the threats to which the protocol is vulnerable. Use of legal term does not imply legal liability, but rather the level of responsibility expected to be applied to the analysis. This discussion might occur throughout the document or in the Security Considerations section; if it occurs throughout, it MUST be summarized and referenced in the Security Considerations section.
- 必须进行“尽职调查”，列出协议易受攻击的威胁。使用法律术语并不意味着法律责任，而是指预期应用于分析的责任水平。这种讨论可能贯穿整个文件或在安全考虑部分进行；如果贯穿始终，则必须在“安全注意事项”部分对其进行总结和引用。
- MUST discuss which of those threats are * Ameliorated by protocol mechanisms (example: SYN attack is ameliorated by clever code that drops sessions randomly when under SYN attack)
- 必须讨论哪些威胁*通过协议机制得到改善（例如：SYN攻击通过在SYN攻击下随机丢弃会话的巧妙代码得到改善）
* Ameliorated by reliance on external mechanisms (example: TCP data confidentiality provided by IPSEC ESP)
* 通过依赖外部机制（例如：IPSEC ESP提供的TCP数据机密性）进行改进
* Irrelevant ("In most cases, MIBs are not themselves security risks; If SNMP Security is operating as intended, the use of a MIB to change the configuration of a system is a tool, not a threat. For a threat analysis of SNMP Security, see RFC ZZZZ.")
* 无关（“在大多数情况下，MIB本身不是安全风险；如果SNMP安全按预期运行，使用MIB更改系统配置是一种工具，而不是威胁。有关SNMP安全的威胁分析，请参阅RFC ZZZ。”）
* Not addressed by the protocol; results in applicability statement. ("This protocol should not be used in an environment subject to this attack")
* 议定书未涉及的；适用性声明中的结果。（“不应在受此攻击的环境中使用此协议”）
A variety of security mechanisms exist today. Not all are well-designed; not all are suitable for all purposes. The members of the workshop designated a number of protocols as "core". Such protocols should be used preferentially, if one of them has properties that match the needs of your protocol. The following were designated as core:
今天存在着各种各样的安全机制。并不是所有的设计都很好；并非所有的都适用于所有目的。讲习班成员指定若干议定书为“核心议定书”。如果其中一个协议的属性与协议的需要相匹配，则应优先使用此类协议。以下被指定为核心：
IPsec [RFC 1825] is the basic host-to-host security mechanism. It is appropriate for use any time address-based protection would have been used, including with such programs as rsh and rlogin. If and when platforms support user-based keying, this scope may be expanded.
IPsec[RFC 1825]是基本的主机对主机安全机制。它适用于任何时候使用基于地址的保护，包括rsh和rlogin等程序。如果平台支持基于用户的键控，此范围可能会扩大。
One particular technique used by IPsec, HMAC [RFC 2104], is more generally useful. If cryptographic authentication but not secrecy is needed, and IPsec is not applicable, HMAC should be used.
IPsec使用的一种特殊技术HMAC[RFC2104]通常更有用。如果需要加密身份验证但不需要保密，并且IPsec不适用，则应使用HMAC。
ISAKMP/Oakley [ISAKMP drafts] is the basic key negotiation protocol for IPsec. As such, it should be deployed when IPsec is used. With the appropriate "domain of interpretation" document, it should be used to negotiate pairwise keys for other protocols.
ISAKMP/Oakley[ISAKMP草稿]是IPsec的基本密钥协商协议。因此，应该在使用IPsec时部署它。使用适当的“解释域”文档，它应该用于协商其他协议的成对密钥。
DNSsec [RFC 2065] is not only crucial for protecting the DNS -- cache contamination is the easiest way to launch active attacks -- it's also needed in many situations when IPsec is used.
DNSsec[RFC 2065]不仅对保护DNS至关重要——缓存污染是发起主动攻击的最简单方法——在使用IPsec的许多情况下也需要它。
Security/Multipart [RFC 1847] is the preferred way to add secured sections to MIME-encapsulated email.
安全/多部分[RFC 1847]是将安全部分添加到MIME封装电子邮件的首选方法。
Signed keys in the DNS. There is, as noted, widespread agreement that DNS records themselves must be protected. There was less agreement that the key records should be signed themselves, making them in effect certificates. Still, this is one promising avenue for Internet certificates.
DNS中的签名密钥。如前所述，人们普遍认为DNS记录本身必须受到保护。对于密钥记录应该自己签名，使其成为有效的证书，人们的意见不那么一致。尽管如此，这仍然是一个很有希望获得互联网证书的途径。
X.509v3 is the other obvious choice for a certificate infrastructure. Again, though, there was no strong consensus on this point.
X.509v3是证书基础结构的另一个明显选择。不过，在这一点上也没有达成强烈的共识。
TLS [TLS draft] was seen by some as the preferred choice for transport-layer security, though there was no consensus on this point. TLS is less intrusive to the operating system than IPsec; additionally, it is easier to provide fine-grained protection this way.
TLS[TLS草案]被一些人视为传输层安全的首选，尽管在这一点上没有达成共识。TLS对操作系统的干扰比IPsec小；此外，通过这种方式更容易提供细粒度保护。
Some protocols were designated as "useful but not core". These were insufficiently general, too new, or were substantially duplicative of core protocols. These include AFT/SOCKS, RADIUS, firewalls, GSS-API, PGP, Kerberos, PGP-MIME, PKIX-3, the various forms of per-hop authentication (OSPF, RSVP, RIPv2), *POP, OTP, S/MIME, SSH, PFKey, IPsec API, SASL, and CRAM/CHAP. Obviously, entries on this list may move in either direction.
一些协议被指定为“有用但不是核心”。这些协议不够通用，太新，或者与核心协议有实质性的重复。其中包括AFT/SOCKS、RADIUS、防火墙、GSS-API、PGP、Kerberos、PGP-MIME、PKIX-3、各种形式的每跳身份验证（OSPF、RSVP、RIPv2）、*POP、OTP、S/MIME、SSH、PFKey、IPsec API、SASL和CRAM/CHAP。显然，此列表中的条目可能会朝任何方向移动。
A few protocols were considered "not useful". Primarily, these are ones that have failed to catch on, even though they've been available for some time. These include PEM [RFC 1421, 1422, 1423, 1424] and MOSS [RFC 1848]. (The phrase "not useful" does not imply that they are incorrect, or are lacking in important information. However, they do not describe protocols that we are currently encouraging the use of.)
有几个协议被认为“没有用处”。基本上，这些都是无法流行的，即使它们已经存在了一段时间。其中包括PEM[RFC 1421、1422、1423、1424]和MOSS[RFC 1848]。（短语“无用”并不意味着它们不正确或缺少重要信息。但是，它们没有描述我们目前鼓励使用的协议。）
One security mechanism was deemed to be unacceptable: plaintext passwords. That is, no protocol that relies on passwords sent over unencrypted channels is acceptable.
有一种安全机制被认为是不可接受的：明文密码。也就是说，不接受依赖于通过未加密通道发送的密码的协议。
Participants in the workshop identified three significant missing pieces: object security, secure email, and route security.
研讨会的参与者确定了三个重要缺失部分：对象安全、安全电子邮件和路由安全。
Object security refers to protection for individual data objects, independent of transport. We have one such already -- Secure DNS -- but we need a me general scheme. MIME is a candidate object framework, in part because it is the core of the two most widely used and deployed applications: the web and email. However, securing email has been problematic and the web is not that far in front.
对象安全性是指独立于传输的单个数据对象的保护。我们已经有了这样一个安全的DNS，但我们需要一个通用的方案。MIME是一个候选对象框架，部分原因是它是两个最广泛使用和部署的应用程序的核心：web和电子邮件。然而，保护电子邮件的安全一直是个问题，而网络也并非遥遥领先。
Secure email is a critical need and has been for some time. Two attempts to standardize secure email protocols (PEM and MOSS) have failed to be accepted by the community, while a third protocol (PGP) has become a de facto standard around the world. A fourth protocol, an industry standard (S/MIME), has been gaining popularity. Both of these latter of entered the Internet standards process.
安全电子邮件是一项关键需求，并且已经存在了一段时间。两次试图标准化安全电子邮件协议（PEM和MOSS）的尝试未能被社区接受，而第三个协议（PGP）已成为世界各地事实上的标准。第四种协议，一种工业标准（S/MIME），已经越来越流行。后两者都进入了互联网标准化进程。
Route security has recently become a critical need. The sophistication of the attackers is on the rise and the availability of attacking toolkits has increased the number of sophisticated attacks. This task is especially complex because the requirement for maximum performance conflicts with the goal of adding security, which usurps resources that would otherwise enhance the performance of the router.
路由安全最近已成为一项关键需求。攻击者的复杂程度正在上升，攻击工具包的可用性增加了复杂攻击的数量。这项任务特别复杂，因为对最大性能的要求与增加安全性的目标相冲突，这会占用本来可以提高路由器性能的资源。
Security is not and cannot be a cookie cutter process. There is no magic pixie dust that can be sprinkled over a protocol to make it secure. Each protocol must be analyzed individually to determine what vulnerabilities exist, what risks they may lead to, what palliative measures can be taken, and what the residual risks are.
安全不是，也不能是一个千篇一律的过程。没有神奇的精灵粉尘可以洒在协议上，使其安全。必须对每个协议进行单独分析，以确定存在哪些漏洞，可能导致哪些风险，可以采取哪些缓和措施，以及剩余风险是什么。
This RFC is largely based on the minutes compiled by Thomas Narten, whose work in turn was partly based on notes by Erik Huizer, John Richardson, and Bob Blakley.
本RFC主要基于Thomas Narten编写的会议记录，而Thomas Narten的工作又部分基于Erik Huizer、John Richardson和Bob Blakley的笔记。
[RFC 1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[RFC 1825]阿特金森，R.，“互联网协议的安全架构”，RFC 18251995年8月。
[RFC 2104] Krawcyzk, H., Bellare, M., and R. Canett, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC 2104]Krawcyzk，H.，Bellare，M.和R.Canett，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[ISAKMP drafts] Works in Progress.
[ISAKMP草稿]正在进行中。
[RFC 2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC 2065]Eastlake，D.和C.Kaufman，“域名系统安全扩展”，RFC 2065，1997年1月。
[RFC 1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC 1847]Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[TLS draft] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0", Work in Progress.
[TLS草案]Dierks，T.和C.Allen，“TLS协议版本1.0”，正在进行中。
[RFC 1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[RFC 1421]Linn，J.，“互联网电子邮件的隐私增强：第一部分：信息加密和认证程序”，RFC 1421，1993年2月。
[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
[RFC 1422]Kent，S.，“互联网电子邮件的隐私增强：第二部分：基于证书的密钥管理”，RFC 1422，1993年2月。
[RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
[RFC 1423]Balenson，D.，“互联网电子邮件的隐私增强：第三部分：算法、模式和标识符”，RFC 1423，1993年2月。
[RFC 1424] Kaliski, B. "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, February 1993.
[RFC 1424]Kaliski，B.“互联网电子邮件的隐私增强：第四部分：关键认证和相关服务”，RFC 1424，1993年2月。
[RFC 1848] Crocker, S., Freed, N., Galvin, J. and S. Murphy, "MIME Object Security Services", RFC 1848, October 1995.
[RFC 1848]Crocker，S.，Freed，N.，Galvin，J.和S.Murphy，“MIME对象安全服务”，RFC 18481995年10月。
Ran Atkinson rja@inet.org Fred Baker fred@cisco.com Steve Bellovin bellovin@acm.org Bob Blakley blakley@vnet.ibm.com Matt Blaze mab@research.att.com Brian Carpenter brian@hursley.ibm.com Jim Ellis jte@cert.org James Galvin galvin@commerce.net Tim Howes howes@netscape.com Erik Huizer Erik.Huizer@sec.nl Charlie Kaufman charlie_kaufman@iris.com Steve Kent kent@bbn.com Paul Krumviede paul@mci.net Marcus Leech mleech@nortel.ca Perry Metzger perry@piermont.com Keith Moore moore@cs.utk.edu Robert Moskowitz rgm@htt-consult.com John Myers jgm@CMU.EDU Thomas Narten narten@raleigh.ibm.com Radia Perlman radia.perlman@sun.com John Richardson jwr@ibeam.jf.intel.com Allyn Romanow allyn@mci.net Jeff Schiller jis@mit.edu Ted T'So tytso@mit.edu
阿特金森rja@inet.org弗雷德·贝克fred@cisco.com史蒂夫·贝洛文bellovin@acm.org鲍勃布莱克利blakley@vnet.ibm.com马特·布雷泽mab@research.att.com布莱恩·卡彭特brian@hursley.ibm.com吉姆·埃利斯jte@cert.org詹姆斯·高尔文galvin@commerce.net蒂姆·豪斯howes@netscape.com埃里克·惠泽尔·埃里克。Huizer@sec.nl查理·考夫曼·查理_kaufman@iris.com史蒂夫肯特kent@bbn.com保罗·克鲁姆维德paul@mci.net马库斯水蛭mleech@nortel.ca佩里·梅茨格perry@piermont.com基思摩尔moore@cs.utk.edu罗伯特·莫斯科维茨rgm@htt-咨询网站：约翰·迈尔斯jgm@CMU.EDU托马斯·纳滕narten@raleigh.ibm.com帕尔曼半径。perlman@sun.com约翰·理查森jwr@ibeam.jf.intel.com艾琳·罗曼诺allyn@mci.net杰夫席勒jis@mit.edu特德·特索tytso@mit.edu
Steven M. Bellovin AT&T Labs Research 180 Park Avenue Florham Park, NJ 07932 USA
Steven M.Bellovin AT&T实验室研究美国新泽西州弗洛勒姆公园公园大道180号，邮编07932
Phone: (973) 360-8656 EMail: bellovin@acm.org
电话：（973）360-8656电子邮件：bellovin@acm.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。