Internet Engineering Task Force (IETF) S. Bellovin
Request for Comments: 7353 Columbia University
Category: Informational R. Bush
ISSN: 2070-1721 Internet Initiative Japan
D. Ward
Cisco Systems
August 2014
Internet Engineering Task Force (IETF) S. Bellovin
Request for Comments: 7353 Columbia University
Category: Informational R. Bush
ISSN: 2070-1721 Internet Initiative Japan
D. Ward
Cisco Systems
August 2014
Security Requirements for BGP Path Validation
BGP路径验证的安全要求
Abstract
摘要
This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin Autonomous System (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement.
本文件描述了BGP安全协议设计的要求，以提供加密保证，即原始自治系统（AS）有权宣布前缀，并提供公告AS路径的保证。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7353.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7353.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Recommended Reading . . . . . . . . . . . . . . . . . . . . . 2
3. General Requirements . . . . . . . . . . . . . . . . . . . . 3
4. BGP UPDATE Security Requirements . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Recommended Reading . . . . . . . . . . . . . . . . . . . . . 2
3. General Requirements . . . . . . . . . . . . . . . . . . . . 3
4. BGP UPDATE Security Requirements . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Origin validation based on Resource Public Key Infrastructure (RPKI) [RFC6811] provides a measure of resilience to accidental mis-origination of prefixes; however, it provides neither cryptographic assurance (announcements are not signed) nor assurance of the AS Path of the announcement.
基于资源公钥基础设施（RPKI）的来源验证[RFC6811]提供了前缀意外误发的恢复能力度量；但是，它既不提供加密保证（公告未签名），也不提供作为公告路径的保证。
This document describes requirements to be placed on a BGP security protocol, herein termed "BGPsec", intended to rectify these gaps.
本文件描述了BGP安全协议（本文称为“BGPsec”）的要求，旨在纠正这些漏洞。
The threat model assumed here is documented in [RFC4593] and [RFC7132].
此处假设的威胁模型记录在[RFC4593]和[RFC7132]中。
As noted in the threat model [RFC7132], this work is limited to threats to the BGP protocol. Issues of business relationship conformance, while quite important to operators, are not security issues per se and are outside the scope of this document. It is hoped that these issues will be better understood in the future.
如威胁模型[RFC7132]所述，这项工作仅限于对BGP协议的威胁。业务关系一致性问题虽然对运营商非常重要，但其本身不是安全问题，不在本文档的范围之内。希望今后能更好地了解这些问题。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case, without normative meaning.
关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”仅当出现在所有大写字母中时，才应按照RFC 2119[RFC2119]中所述进行解释。它们也可能出现在小写或混合的情况下，没有规范意义。
This document assumes knowledge of the RPKI [RFC6480] and the RPKI Repository Structure [RFC6481].
本文档假设了解RPKI[RFC6480]和RPKI存储库结构[RFC6481]。
This document assumes ongoing incremental deployment of Route Origin Authorizations (ROAs) [RFC6482], the RPKI to the Router Protocol [RFC6810], and RPKI-based Prefix Validation [RFC6811].
本文档假设路由来源授权（ROA）[RFC6482]、路由器协议的RPKI[RFC6810]和基于RPKI的前缀验证[RFC6811]正在进行增量部署。
And, of course, a knowledge of BGP [RFC4271] is required.
当然，还需要了解BGP[RFC4271]。
The following are general requirements for a BGPsec protocol:
以下是BGPsec协议的一般要求：
3.1 A BGPsec design MUST allow the receiver of a BGP announcement to determine, to a strong level of certainty, that the originating AS in the received PATH attribute possessed the authority to announce the prefix.
3.1 BGPsec设计必须允许BGP公告的接收者在很大程度上确定接收路径属性中的始发AS拥有公告前缀的权限。
3.2 A BGPsec design MUST allow the receiver of a BGP announcement to determine, to a strong level of certainty, that the received PATH attribute accurately represents the sequence of External BGP (eBGP) exchanges that propagated the prefix from the origin AS to the receiver, particularly if an AS has added or deleted any AS number other than its own in the PATH attribute. This includes modification to the number of AS prepends.
3.2 BGPsec设计必须允许BGP公告的接收者在很大程度上确定接收路径属性准确地表示将前缀从原点传播到接收者的外部BGP（eBGP）交换序列，特别是当AS在路径属性中添加或删除了除其自身以外的任何AS编号时。这包括修改AS前置词的数量。
3.3 BGP attributes other than the AS_PATH are used only locally, or have meaning only between immediate neighbors, may be modified by intermediate systems and figure less prominently in the decision process. Consequently, it is not appropriate to try to protect such attributes in a BGPsec design.
3.3 除AS_路径以外的BGP属性仅在本地使用，或仅在近邻之间具有意义，可由中间系统修改，并且在决策过程中不太重要。因此，在BGPsec设计中尝试保护此类属性是不合适的。
3.4 A BGPsec design MUST be amenable to incremental deployment. This implies that incompatible protocol capabilities MUST be negotiated.
3.4 BGPsec设计必须适合增量部署。这意味着必须协商不兼容的协议功能。
3.5 A BGPsec design MUST provide analysis of the operational considerations for deployment and particularly of incremental deployment, e.g., contiguous islands, non-contiguous islands, universal deployment, etc.
3.5 BGPsec设计必须提供对部署操作考虑因素的分析，尤其是增量部署，例如，连续岛、非连续岛、通用部署等。
3.6 As proofs of possession and authentication may require cryptographic payloads and/or storage and computation, likely increasing processing and memory requirements on routers, a BGPsec design MAY require use of new hardware. That is, compatibility with current hardware abilities is not a requirement that this document imposes on a solution.
3.6 由于占有和认证证明可能需要加密有效载荷和/或存储和计算，可能会增加路由器的处理和内存需求，BGPsec设计可能需要使用新硬件。也就是说，与当前硬件能力的兼容性不是本文档对解决方案的要求。
3.7 A BGPsec design need not prevent attacks on data-plane traffic. It need not provide assurance that the data plane even follows the control plane.
3.7 BGPsec设计不需要防止对数据平面流量的攻击。它不需要保证数据平面甚至跟随控制平面。
3.8 A BGPsec design MUST resist attacks by an enemy who has access to the inter-router link layer, per Section 3.1.1.2 of [RFC4593]. In particular, such a design MUST provide mechanisms for authentication of all data, including protecting against message insertion, deletion, modification, or replay. Mechanisms that suffice include TCP sessions authenticated with the TCP Authentication Option (TCP-AO) [RFC5925], IPsec [RFC4301], or Transport Layer Security (TLS) [RFC5246].
3.8 根据[RFC4593]第3.1.1.2节的规定，BGPsec设计必须抵抗能够访问路由器间链路层的敌人的攻击。特别是，这种设计必须提供所有数据的身份验证机制，包括防止消息插入、删除、修改或重播。足够的机制包括使用TCP身份验证选项（TCP-AO）[RFC5925]、IPsec[RFC4301]或传输层安全性（TLS）[RFC5246]进行身份验证的TCP会话。
3.9 It is assumed that a BGPsec design will require information about holdings of address space and Autonomous System Numbers (ASNs), and assertions about binding of address space to ASNs. A BGPsec design MAY make use of a security infrastructure (e.g., a PKI) to distribute such authenticated data.
3.9 假定BGPsec设计将需要有关地址空间和自治系统编号（ASN）持有情况的信息，以及关于地址空间与ASN绑定的断言。BGPsec设计可利用安全基础设施（例如PKI）来分发此类认证数据。
3.10 It is entirely OPTIONAL to secure AS SETs and prefix aggregation. The long-range solution to this is the deprecation of AS_SETs; see [RFC6472].
3.10 安全AS集合和前缀聚合是完全可选的。解决这一问题的长期方案是反对使用AS_集合；见[RFC6472]。
3.11 If a BGPsec design uses signed prefixes, given the difficulty of splitting a signed message while preserving the signature, it need not handle multiple prefixes in a single UPDATE PDU.
3.11 如果BGPsec设计使用带签名的前缀，考虑到在保留签名的同时拆分带签名的消息的困难，它不需要在一个更新PDU中处理多个前缀。
3.12 A BGPsec design MUST enable each BGPsec speaker to configure use of the security mechanism on a per-peer basis.
3.12 BGPsec设计必须使每个BGPsec扬声器能够在每个对等基础上配置安全机制的使用。
3.13 A BGPsec design MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward compatible manner.
3.13 BGPsec设计必须在通过混合安全环境传输的消息格式、传输和路由信息处理方面提供向后兼容性。完全安全环境中的消息格式可能以不向后兼容的方式处理。
3.14 While the formal validity of a routing announcement should be determined by the BGPsec protocol, local routing policy MUST be the final arbiter of the best path and other routing decisions.
3.14 虽然路由公告的形式有效性应由BGPsec协议确定，但本地路由策略必须是最佳路径和其他路由决策的最终仲裁者。
3.15 A BGPsec design MUST support 'transparent' route servers, meaning that the AS of the route server is not counted in downstream BGP AS-path-length tie-breaking decisions.
3.15 BGPsec设计必须支持“透明”路由服务器，这意味着路由服务器的AS在下游BGP中不被视为路径长度中断决策。
3.16 A BGPsec design MUST support AS aliasing. This technique is not well defined or universally implemented but is being documented in [AS-MIGRATION]. A BGPsec design SHOULD accommodate AS 'migration' techniques such as common proprietary and non-standard methods that allow a router to have two AS identities, without lengthening the effective AS Path.
3.16 BGPsec设计必须支持AS别名。这项技术没有得到很好的定义或普遍实施，但在[AS-MIGRATION]中有记录。BGPsec设计应适应AS“迁移”技术，如通用专有和非标准方法，允许路由器具有两个AS标识，而不延长有效AS路径。
3.17 If a BGPsec design makes use of a security infrastructure, that infrastructure SHOULD enable each network operator to select the entities it will trust when authenticating data in the security infrastructure. See, for example, [LTA-USE-CASES].
3.17 如果BGPsec设计使用安全基础设施，则该基础设施应使每个网络运营商能够在对安全基础设施中的数据进行身份验证时选择其信任的实体。例如，参见[LTA-USE-CASES]。
3.18 A BGPsec design MUST NOT require operators to reveal more than is currently revealed in the operational inter-domain routing environment, other than the inclusion of necessary security credentials to allow others to ascertain for themselves the necessary degree of assurance regarding the validity of Network Layer Reachability Information (NLRI) received via BGPsec. This includes peering, customer/provider relationships, an ISP's internal infrastructure, etc. It is understood that some data are revealed to the savvy seeker by BGP, traceroute, etc., today.
3.18 BGPsec设计不得要求运营商披露比当前运营域间路由环境中披露的更多的信息，除了包含必要的安全凭证，以允许其他人自行确定有关网络层可达性信息（NLRI）有效性的必要保证程度通过BGPsec接收。这包括对等、客户/提供商关系、ISP的内部基础设施等。据了解，今天BGP、traceroute等向精明的搜索者透露了一些数据。
3.19 A BGPsec design MUST signal (e.g., via logging or SNMP) security exceptions that are significant to the operator. The specific data to be signaled are an implementation matter.
3.19 BGPsec设计必须发出（例如，通过日志记录或SNMP）对操作员重要的安全异常信号。要发出信号的特定数据是一个实现问题。
3.20 Any routing information database MUST be re-authenticated periodically or in an event-driven manner, especially in response to events such as, for example, PKI updates.
3.20 任何路由信息数据库都必须定期或以事件驱动的方式重新验证，尤其是在响应PKI更新等事件时。
3.21 Any inter-AS use of cryptographic hashes or signatures MUST provide mechanisms for algorithm agility. For a discussion, see [ALG-AGILITY].
3.21 加密哈希或签名的任何内部AS使用都必须提供算法灵活性机制。有关讨论，请参阅[ALG-AGILITY]。
3.22 A BGPsec design SHOULD NOT presume to know the intent of the originator of a NLRI, nor that of any AS on the AS Path, other than that they intend to pass it to the next AS in the path.
3.22 BGPsec设计不应假定知道NLRI发起人的意图，也不应知道AS路径上任何AS的意图，除非他们打算将其传递给路径中的下一个AS。
3.23 A BGPsec listener SHOULD NOT trust non-BGPsec markings, such as communities, across trust boundaries.
3.23 BGPsec侦听器不应跨信任边界信任非BGPsec标记，例如社区。
The following requirements MUST be met in the processing of BGP UPDATE messages:
处理BGP更新消息时必须满足以下要求：
4.1 A BGPsec design MUST enable each recipient of an UPDATE to formally validate that the origin AS in the message is authorized to originate a route to the prefix(es) in the message.
4.1 BGPsec设计必须使更新的每个收件人能够正式验证消息中的源AS是否有权发起到消息中前缀的路由。
4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally determine that the NLRI has traversed the AS Path indicated in the UPDATE. Note that this is more stringent than showing that the path is merely not impossible.
4.2 BGPsec设计必须使更新的接收者能够正式确定NLRI已通过更新中指示的AS路径。请注意，这比显示路径并非不可能更严格。
4.3 Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design SHOULD provide a mechanism to control the window of exposure to replay attacks.
4.3 不需要完全阻止BGP更新消息的重播，但BGPsec设计应提供一种机制来控制重播攻击的暴露窗口。
4.4 A BGPsec design SHOULD provide some level of assurance that the origin of a prefix is still 'alive', i.e., that a monkey in the middle has not withheld a WITHDRAW message or the effects thereof.
4.4 BGPSEC设计应该提供一定程度的保证，前缀的起源仍然是“活着的”，即中间的猴子没有保留撤回消息或其影响。
4.5 The AS Path of an UPDATE message SHOULD be able to be authenticated as the message is processed.
4.5 更新消息的AS路径应该能够在处理消息时进行身份验证。
4.6 Normal sanity checks of received announcements MUST be done, e.g., verification that the first element of the AS_PATH list corresponds to the locally configured AS of the peer from which the UPDATE was received.
4.6 必须对接收到的通知进行正常的健全性检查，例如，验证AS_路径列表的第一个元素是否对应于从中接收更新的对等方的本地配置的AS。
4.7 The output of a router applying BGPsec validation to a received UPDATE MUST be unequivocal and conform to a fully specified state in the design.
4.7 对接收到的更新应用BGPsec验证的路由器的输出必须是明确的，并且符合设计中完全指定的状态。
If an external "security infrastructure" is used, as mentioned in Section 3, paragraphs 9 and 17 above, the authenticity and integrity of the data of such an infrastructure MUST be assured. In addition, the integrity of those data MUST be assured when they are used by BGPsec, e.g., in transport.
如上文第3节第9段和第17段所述，如果使用外部“安全基础设施”，则必须确保此类基础设施数据的真实性和完整性。此外，当BGPsec使用这些数据时，例如在传输中，必须确保这些数据的完整性。
The requirement of backward compatibility to BGP4 may open an avenue to downgrade attacks.
对BGP4的向后兼容性要求可能为降级攻击打开了一条道路。
The data plane might not follow the path signaled by the control plane.
数据平面可能不遵循控制平面发出的信号路径。
Security for subscriber traffic is outside the scope of this document and of BGP security in general. IETF standards for payload data security should be employed. While adoption of BGP security measures may ameliorate some classes of attacks on traffic, these measures are not a substitute for use of subscriber-based security.
订户流量的安全性不在本文档和BGP安全性的范围内。应采用IETF有效载荷数据安全标准。虽然采用BGP安全措施可能会改善某些类别的流量攻击，但这些措施不能替代基于订户的安全措施。
The authors wish to thank the authors of [BGP-SECURITY] from whom we liberally stole, Roque Gagliano, Russ Housley, Geoff Huston, Steve Kent, Sandy Murphy, Eric Osterweil, John Scudder, Kotikalapudi Sriram, Sam Weiler, and a number of others.
作者希望感谢[BGP-SECURITY]的作者，我们从他们那里大肆盗窃了罗克·加利亚诺、罗斯·霍斯利、杰夫·休斯顿、史蒂夫·肯特、桑迪·墨菲、埃里克·奥斯特维尔、约翰·斯卡德尔、科蒂卡拉普迪·斯利拉姆、山姆·韦勒和其他一些人。
[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月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 4593，2006年10月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, February 2014.
[RFC7132]Kent，S.和A.Chi，“BGP路径安全的威胁模型”，RFC 7132，2014年2月。
[ALG-AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm Agility", Work in Progress, June 2014.
[ALG-AGILITY]Housley，R.，“加密算法敏捷性指南”，进展中的工作，2014年6月。
[AS-MIGRATION] George, W. and S. Amante, "Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute", Work in Progress, January 2014.
[AS-MIGRATION]George，W.和S.Amante，“自治系统（AS）迁移特征及其对BGP AS_路径属性的影响”，正在进行的工作，2014年1月。
[BGP-SECURITY] Christian, B. and T. Tauber, "BGP Security Requirements", Work in Progress, November 2008.
[BGP-SECURITY]Christian，B.和T.Tauber，“BGP安全要求”，正在进行的工作，2008年11月。
[LTA-USE-CASES] Bush, R., "RPKI Local Trust Anchor Use Cases", Work in Progress, June 2014.
[LTA-用例]Bush，R.，“RPKI本地信任锚用例”，正在进行的工作，2014年6月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, December 2011.
[RFC6472]Kumari，W.和K.Sriram，“在BGP中不使用AS_集和AS_CONFED_集的建议”，BCP 172，RFC 6472，2011年12月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，2012年2月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481]Huston，G.，Loomans，R.，和G.Michaelson，“资源证书存储库结构的配置文件”，RFC 64812012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482]Lepinski，M.，Kent，S.，和D.Kong，“路线原产地授权（ROA）的配置文件”，RFC 64822012年2月。
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, January 2013.
[RFC6810]Bush，R.和R.Austein，“资源公钥基础设施（RPKI）到路由器协议”，RFC 6810，2013年1月。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013.
[RFC6811]Mohapatra，P.，Scudder，J.，Ward，D.，Bush，R.，和R.Austein，“BGP前缀来源验证”，RFC 6811，2013年1月。
Authors' Addresses
作者地址
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue, MC 0401 New York, New York 10027 USA
Steven M.Bellovin哥伦比亚大学，美国纽约州纽约市阿姆斯特丹大道1214号，邮编：0401，邮编：10027
Phone: +1 212 939 7149
EMail: bellovin@acm.org
Phone: +1 212 939 7149
EMail: bellovin@acm.org
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 USA
兰迪·布什互联网倡议日本5147水晶泉班布里奇岛，华盛顿98110美国
EMail: randy@psg.com
EMail: randy@psg.com
David Ward Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
David Ward Cisco Systems 170 W.塔斯曼大道圣何塞，加利福尼亚州95134
EMail: dward@cisco.com
EMail: dward@cisco.com