Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 8207 Internet Initiative Japan
BCP: 211 September 2017
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 8207 Internet Initiative Japan
BCP: 211 September 2017
Category: Best Current Practice
ISSN: 2070-1721
BGPsec Operational Considerations
BGPsec操作注意事项
Abstract
摘要
Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. Operational practices are expected to evolve as BGPsec is formalized and initially deployed.
BGPsec体系结构和协议的部署有许多操作方面的考虑。本文件试图收集和呈现最关键和最普遍的信息。随着BGPsec的正式化和初步部署，预计运营实践将不断发展。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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). Further information on BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 7841第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/rfc8207.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8207.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 . . . . . . . . . . . . . . . . . . 3
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3
4. AS/Router Certificates . . . . . . . . . . . . . . . . . . . 3
5. Within a Network . . . . . . . . . . . . . . . . . . . . . . 4
6. Considerations for Edge Sites . . . . . . . . . . . . . . . . 4
7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 5
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3
4. AS/Router Certificates . . . . . . . . . . . . . . . . . . . 3
5. Within a Network . . . . . . . . . . . . . . . . . . . . . . 4
6. Considerations for Edge Sites . . . . . . . . . . . . . . . . 4
7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 5
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
Origin validation based on the Resource Public Key Infrastructure (RPKI) [RFC6811] is in its early phases. As BGPsec [RFC8205] may require larger memory and/or more modern CPUs, it expected to be deployed incrementally over a longer time span. BGPsec is a new protocol with many operational considerations that this document attempts to describe. As with most operational practices, they will likely change over time.
基于资源公钥基础设施（RPKI）[RFC6811]的源验证处于早期阶段。由于BGPsec[RFC8205]可能需要更大的内存和/或更现代化的CPU，因此预计它将在更长的时间跨度内增量部署。BGPsec是一种新的协议，本文档试图描述它的许多操作注意事项。与大多数操作实践一样，它们可能会随着时间的推移而改变。
BGPsec relies on widespread propagation of the RPKI [RFC6480]. How the RPKI is distributed and maintained globally and within an operator's infrastructure may be different for BGPsec than for origin validation.
BGPsec依赖于RPKI[RFC6480]的广泛传播。对于BGPsec而言，RPKI在全球和运营商基础设施内的分布和维护方式可能与原产地验证不同。
BGPsec needs to be spoken only by an Autonomous System's (AS's) eBGP-speaking border routers. It is designed so that it can be used to protect announcements that are originated by resource-constrained edge routers. This has special operational considerations, see Section 6.
BGPsec只需要由自治系统（AS）的讲eBGP的边界路由器讲。它的设计可以用来保护由资源受限的边缘路由器发起的公告。这有特殊的操作考虑，见第6节。
Different prefixes may have different timing and replay protection considerations.
不同的前缀可能具有不同的定时和重播保护注意事项。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
It is assumed that the reader understands BGP [RFC4271], BGPsec [RFC8205], the RPKI [RFC6480], the RPKI Repository Structure [RFC6481], and Route Origin Authorizations (ROAs) [RFC6482].
假设读者理解BGP[RFC4271]、BGPsec[RFC8205]、RPKI[RFC6480]、RPKI存储库结构[RFC6481]和路由来源授权（ROA）[RFC6482]。
The considerations for RPKI objects (Certificates, Certificate Revocation Lists (CRLs), manifests [RFC6481], and Ghostbusters Records [RFC6493]), Trust Anchor Locators (TALs) [RFC7730], cache behaviors of synchronization, and validation from the section on RPKI Distribution and Maintenance of [RFC7115] apply. Specific considerations relating to ROA objects do not apply to this document.
RPKI对象（证书、证书撤销列表（CRL）、清单[RFC6481]和Ghostbusters记录[RFC6493]）、信任锚点定位器（TAL）[RFC7730]、缓存同步行为以及[RFC7115]的RPKI分发和维护部分中的验证注意事项适用。与ROA对象相关的特定注意事项不适用于本文件。
As described in [KEY], BGPsec-speaking routers are capable of generating their own public/private key-pairs and having their certificates signed and published in the RPKI by the RPKI Certification Authority (CA) system, and/or are given public/private key-pairs by the operator.
如[KEY]所述，讲BGPsec的路由器能够生成自己的公钥/私钥对，并由RPKI证书颁发机构（CA）系统在RPKI中签署和发布其证书，和/或由运营商提供公钥/私钥对。
A site/operator may use a single certificate/key in all their routers, one certificate/key per router, or any granularity in between.
站点/运营商可以在其所有路由器中使用一个证书/密钥，每个路由器使用一个证书/密钥，或者两者之间的任何粒度。
A large operator, concerned that a compromise of one router's key would make other routers vulnerable, may deploy a more complex certificate/key distribution burden to reduce this exposure.
大型运营商担心一个路由器的密钥泄露会使其他路由器易受攻击，可能会部署更复杂的证书/密钥分发负担来减少这种暴露。
At the other end of the spectrum, an edge site with one or two routers may choose to use a single certificate/key.
在频谱的另一端，具有一个或两个路由器的边缘站点可以选择使用单个证书/密钥。
In anticipation of possible key compromise, a prudent operator SHOULD pre-provision each router's 'next' key in the RPKI so that there is no propagation delay for provisioning the new key.
出于对可能的密钥泄露的预期，谨慎的运营商应在RPKI中预先配置每个路由器的“下一个”密钥，以便在配置新密钥时不会出现传播延迟。
BGPsec is spoken by edge routers in a network, specifically those that border other networks/ASes.
BGPsec由网络中的边缘路由器（特别是那些与其他网络/ASE相邻的路由器）讲话。
In an AS where edge routers speak BGPsec and, therefore, inject BGPsec paths into the iBGP (internal BGP), Route Reflectors (RRs) MUST have BGPsec enabled if and only if there are eBGP (external BGP) speakers in their client cone, i.e., an RR client or the transitive closure of a client's customers.
在边缘路由器使用BGPsec并因此将BGPsec路径注入iBGP（内部BGP）的AS中，当且仅当其客户端锥体中存在eBGP（外部BGP）扬声器（即RR客户端或客户端客户的过渡关闭）时，路由反射器（RRs）必须启用BGPsec。
A BGPsec-capable router MAY use the data it receives to influence local policy within its network, see Section 7. In deployment, this policy should fit into the AS's existing policy, preferences, etc. This allows a network to incrementally deploy BGPsec-enabled border routers.
支持BGPsec的路由器可使用其接收的数据来影响其网络内的本地策略，见第7节。在部署中，此策略应适合AS的现有策略、首选项等。这允许网络以增量方式部署启用BGPsec的边界路由器。
eBGP speakers that face more critical peers or upstreams or downstreams would be candidates for early deployment. Both securing one's own announcements and validating received announcements should be considered in partial deployment.
面对更重要的同行或上游或下游的eBGP发言人将是早期部署的候选人。在部分部署中，应同时考虑保护自己的公告和验证收到的公告。
An operator should be aware that BGPsec, as any other policy change, can cause traffic shifts in their network. And, as with normal policy shift practice, a prudent operator has the tools and methods to predict, measure, modify, etc.
运营商应意识到，BGPsec与任何其他政策变更一样，可能会导致其网络中的流量变化。而且，与正常的政策转变实践一样，谨慎的经营者拥有预测、衡量、修改等工具和方法。
On the other hand, an operator wanting to monitor router loading, shifts in traffic, etc., might deploy incrementally while watching those and similar effects.
另一方面，希望监控路由器负载、流量变化等的运营商可能会在观察这些影响和类似影响的同时进行增量部署。
BGPsec does not sign over communities, so they are not formally trustable. Additionally, outsourcing verification is not a prudent security practice. Therefore, an eBGP listener SHOULD NOT strongly trust unsigned security signaling, such as communities, received across a trust boundary.
BGPsec不签署社区，因此它们在形式上不可信任。此外，外包验证不是一种谨慎的安全实践。因此，eBGP侦听器不应强烈信任跨信任边界接收的未签名安全信令，例如社区。
An edge site that does not provide transit and trusts its upstream(s) may only originate a signed prefix announcement and not validate received announcements.
不提供传输且信任其上游的边缘站点只能发起签名前缀公告，而不能验证接收到的公告。
An operator might need to use hardware with limited resources. In such cases, BGPsec protocol capability negotiation allows for a resource-constrained edge router to hold only its own signing key(s) and sign its announcements, but not receive signed announcements.
操作员可能需要使用资源有限的硬件。在这种情况下，BGPsec协议能力协商允许资源受限的边缘路由器仅持有其自己的签名密钥并对其公告进行签名，但不接收已签名的公告。
Therefore, the router would not have to deal with the majority of the RPKI, potentially saving the need for additional hardware.
因此，路由器将不必处理大部分RPKI，从而有可能节省额外硬件的需要。
As the vast majority of ASes are stubs, and they announce the majority of prefixes, this allows for simpler and less expensive incremental deployment. It may also mean that edge sites concerned with routing security will be attracted to upstreams that support BGPsec.
由于绝大多数ASE都是存根，并且它们宣布了大多数前缀，这使得增量部署更简单、成本更低。这也可能意味着关注路由安全的边缘站点将被吸引到支持BGPsec的上游。
As BGPsec-signed paths cannot traverse non-BGPsec topology, partial BGPsec deployment forms islands of assured paths. As islands grow to touch each other, they become larger islands.
由于BGPsec签名路径无法穿越非BGPsec拓扑，部分BGPsec部署会形成保证路径孤岛。随着岛屿逐渐相互接触，它们会变成更大的岛屿。
Unlike origin validation based on the RPKI, BGPsec marks a received announcement as Valid or Not Valid, there is no explicit NotFound state. In some sense, an unsigned BGP4 path is the equivalent of NotFound. How this is used in routing is up to the operator's local policy, similar to origin validation as in [RFC6811].
与基于RPKI的源验证不同，BGPsec将收到的公告标记为有效或无效，没有明确的NotFound状态。在某种意义上，无符号BGP4路径相当于NotFound。这在路由中的使用方式取决于运营商的本地策略，类似于[RFC6811]中的来源验证。
As BGPsec will be rolled out over years and does not allow for intermediate non-signing edge routers, coverage will be spotty for a long time. This presents a dilemma; should a router evaluating an inbound BGPsec_PATH as Not Valid be very strict and discard it? On the other hand, it might be the only path to that prefix, and a very low local-preference would cause it to be used and propagated only if there was no alternative. Either choice is reasonable, but we recommend dropping because of the next point.
由于BGPsec将在数年内推出，并且不允许使用中间非签名边缘路由器，因此覆盖范围将在很长一段时间内不稳定。这是一个两难的局面；路由器评估入站BGPsec_路径无效是否应该非常严格并丢弃它？另一方面，它可能是指向该前缀的唯一路径，并且非常低的本地首选项将导致只有在没有其他选择的情况下才使用和传播它。这两种选择都是合理的，但我们建议放弃，因为下一点。
Operators should be aware that accepting Not Valid announcements, no matter the local preference, will often be the equivalent of treating them as fully Valid. Local preference affects only routes to the same set of destinations. Consider having a Valid announcement from neighbor V for prefix 10.0.0.0/16 and a Not Valid announcement for 10.0.666.0/24 from neighbor I. If local policy on the router is not configured to discard the Not Valid announcement from I, then the longest match forwarding will send packets to neighbor I no matter the value of local preference.
运营商应意识到，无论当地偏好如何，接受无效公告通常等同于将其视为完全有效。本地首选项仅影响到到同一组目的地的路由。考虑从邻居V有一个有效的通知，用于前缀100.0.0/16，以及从邻居I.的有效宣告为0.0.660.0/24。如果路由器上的本地策略没有被配置为丢弃从I中的无效通知，那么最长的匹配转发将发送分组到邻居i，不管本地偏好的值。
Validation of signed paths is usually deployed at the eBGP edge.
签名路径的验证通常部署在eBGP边缘。
Local policy on the eBGP edge MAY convey the validation state of a BGP-signed path through normal local policy mechanisms, e.g., setting a BGP community for internal use, or modifying a metric value such as local-preference or Multi-Exit Discriminator (MED). Some may choose
eBGP边缘上的本地策略可以通过正常的本地策略机制来传递BGP签名路径的验证状态，例如，设置BGP社区供内部使用，或者修改度量值，例如本地偏好或多出口鉴别器（MED）。有些人可能会选择
to use the large Local-Pref hammer. Others may choose to let AS path rule and set their internal metric, which comes after AS path in the BGP decision process.
使用大型本地预处理锤。其他人可以选择让AS路径规则并设置其内部度量，在BGP决策过程中，该度量位于AS路径之后。
As the mildly stochastic timing of RPKI propagation may cause version skew across routers, an AS Path that does not validate at router R0 might validate at R1. Therefore, signed paths that are Not Valid and yet propagated (because they are chosen as best path) MUST NOT have signatures stripped and MUST be signed if sent to external BGPsec speakers.
由于RPKI传播的轻微随机定时可能导致路由器之间的版本倾斜，因此在路由器R0处未验证的As路径可能在R1处验证。因此，无效且已传播的已签名路径（因为它们被选为最佳路径）不得去除签名，并且如果发送到外部BGPsec扬声器，则必须对其进行签名。
This implies that updates which a speaker judges to be Not Valid MAY be propagated to iBGP peers. Therefore, unless local policy ensures otherwise, a signed path learned via iBGP may be Not Valid. If needed, the validation state should be signaled by normal local policy mechanisms such as communities or metrics.
这意味着说话人判断为无效的更新可能会传播到iBGP对等方。因此，除非本地策略另有保证，否则通过iBGP学习的签名路径可能无效。如果需要，验证状态应该由正常的本地策略机制（如社区或度量）发出信号。
On the other hand, local policy on the eBGP edge might preclude iBGP or eBGP announcement of signed AS Paths that are Not Valid.
另一方面，eBGP边缘上的本地策略可能会阻止iBGP或eBGP宣布无效的签名为路径。
A BGPsec speaker receiving a path SHOULD perform origin validation per [RFC6811] and [RFC7115].
接收路径的BGPsec扬声器应按照[RFC6811]和[RFC7115]执行原点验证。
A route server is usually 'transparent', i.e., does not insert an AS into the path so as not to increase the AS hop count, and thereby affect downstream path choices. But, with BGPsec, a client router R needs to be able to validate paths that are forward signed to R. But the sending router cannot generate signatures to all the possible clients. Therefore, a BGPsec-aware route server needs to validate the incoming BGPsec_PATH and to forward updates that can be validated by clients that must, therefore, know the route server's AS. This implies that the route server creates signatures per client including its own AS in the BGPsec_PATH, forward signing to each client AS, see [RFC8205]. The route server uses a pCount of 0 to not increase the effective AS hop count, thereby retaining the intent of 'transparency'.
路由服务器通常是“透明的”，即不会将AS插入路径中，从而不会增加AS跃点计数，从而影响下游路径选择。但是，使用BGPsec，客户端路由器R需要能够验证前向签名到R的路径。但发送路由器无法生成所有可能客户端的签名。因此，支持BGPsec的路由服务器需要验证传入的BGPsec_路径，并转发可由客户端验证的更新，因此客户端必须知道路由服务器的AS。这意味着路由服务器在BGPsec_路径中为每个客户端创建签名，包括自己的AS，并将签名转发给每个客户端AS，请参见[RFC8205]。路由服务器使用pCount 0来不增加有效AS跃点计数，从而保留“透明性”的意图。
If it is known that a BGPsec neighbor is a transparent route server, or otherwise may validly use a pCount of 0 (e.g., see [RFC8206]), the router SHOULD be configured to accept and process a received pCount of 0. Routers MUST disallow a pCount of 0 by default.
如果已知BGPsec邻居是透明路由服务器，或以其他方式可以有效使用0的pCount（例如，请参阅[RFC8206]），则路由器应配置为接受并处理接收到的0的pCount。默认情况下，路由器必须禁止pCount为0。
To prevent exposure of the internals of the BGP confederations [RFC5065], a BGPsec speaker exporting to a non-member removes all intra-confederation Secure_Path Segments. Therefore, signing within the confederation will not cause external confusion even if non-unique private ASes are used.
为了防止暴露BGP联盟[RFC5065]的内部，输出到非成员的BGPsec扬声器将删除所有联盟内的安全路径段。因此，即使使用非唯一的专用ASE，在联盟内签名也不会造成外部混乱。
For protection from attacks replaying BGP data on the order of a day or longer old, rekeying routers with new keys (previously) provisioned in the RPKI is sufficient. For one approach, see [ROLLOVER].
为了防止攻击重放一天或更长时间的BGP数据，使用RPKI中提供的新密钥（以前）重新设置路由器密钥就足够了。有关一种方法，请参见[滚动]。
A router that once negotiated (and/or sent) BGPsec should not be expected to always do so.
曾经协商（和/或发送）BGPsec的路由器不应总是这样做。
Like the DNS, the Global RPKI presents only a loosely consistent view, depending on timing, updating, fetching, etc. Thus, one cache or router may have different data about a particular prefix or router than another cache or router. There is no 'fix' for this, it is the nature of distributed data with distributed caches.
与DNS一样，全局RPKI仅呈现松散一致的视图，这取决于定时、更新、获取等。因此，一个缓存或路由器可能与另一个缓存或路由器具有不同的关于特定前缀或路由器的数据。对此没有“修复”，这是具有分布式缓存的分布式数据的本质。
Operators who manage certificates SHOULD have RPKI Ghostbuster Records (see [RFC6493]), signed indirectly by end entity certificates, for those certificates on which others' routing depends for certificate and/or ROA validation.
管理证书的操作员应具有RPKI Ghostbuster记录（请参见[RFC6493]），由终端实体证书间接签名，用于其他人的路由依赖于这些证书进行证书和/或ROA验证。
Operators should be aware of impending algorithm transitions, which will be rare and slow-paced, see [RFC6916]. They should work with their vendors to ensure support for new algorithms.
操作员应注意即将发生的算法转换，这将是罕见且缓慢的，请参见[RFC6916]。他们应该与供应商合作，确保对新算法的支持。
As a router must evaluate certificates and ROAs that are time dependent, routers' clocks MUST be correct to a tolerance of approximately an hour. The common approach is for operators to deploy servers that provide time service, such as [RFC5905], to client routers.
由于路由器必须评估与时间相关的证书和ROA，因此路由器的时钟必须正确到大约一小时的容差。常见的方法是运营商将提供时间服务的服务器（如[RFC5905]）部署到客户端路由器。
If a router has reason to believe its clock is seriously incorrect, e.g., it has a time earlier than 2011, it SHOULD NOT attempt to validate incoming updates. It SHOULD defer validation until it believes it is within reasonable time tolerance.
如果路由器有理由认为其时钟严重错误，例如，其时间早于2011年，则不应尝试验证传入的更新。它应该推迟验证，直到它认为它在合理的时间容差内。
This document describes operational considerations for the deployment of BGPsec. The security considerations for BGPsec are described in [RFC8205].
本文件描述了部署BGPsec的操作注意事项。[RFC8205]中描述了BGPsec的安全注意事项。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RFC6493]布什，R.，“资源公钥基础设施（RPKI）捉鬼记录”，RFC 6493，DOI 10.17487/RFC6493，2012年2月<https://www.rfc-editor.org/info/rfc6493>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811]Mohapatra，P.，Scudder，J.，Ward，D.，Bush，R.，和R.Austein，“BGP前缀来源验证”，RFC 6811，DOI 10.17487/RFC6811，2013年1月<https://www.rfc-editor.org/info/rfc6811>.
[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, <https://www.rfc-editor.org/info/rfc7115>.
[RFC7115]Bush，R.，“基于资源公钥基础设施（RPKI）的原产地验证操作”，BCP 185，RFC 7115，DOI 10.17487/RFC7115，2014年1月<https://www.rfc-editor.org/info/rfc7115>.
[RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, <https://www.rfc-editor.org/info/rfc7730>.
[RFC7730]Huston，G.，Weiler，S.，Michaelson，G.，和S.Kent，“资源公钥基础设施（RPKI）信任锚定位器”，RFC 7730，DOI 10.17487/RFC7730，2016年1月<https://www.rfc-editor.org/info/rfc7730>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <http://www.rfc-editor.org/info/rfc8205>.
[RFC8205]Lepinski，M.，Ed.和K.Sriram，Ed.，“BGPsec协议规范”，RFC 8205，DOI 10.17487/RFC8205，2017年9月<http://www.rfc-editor.org/info/rfc8205>.
[KEY] Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec", Work in Progress, draft-ietf-sidr-rtr-keying-13, April 2017.
[KEY]Bush，R.，Turner，S.，和K.Patel，“BGPsec的路由器键控”，正在进行的工作，草稿-ietf-sidr-rtr-Keying-132017年4月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<https://www.rfc-editor.org/info/rfc4271>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>.
[RFC5065]Traina，P.，McPherson，D.，和J.Scudder，“BGP自治系统联合会”，RFC 5065，DOI 10.17487/RFC5065，2007年8月<https://www.rfc-editor.org/info/rfc5065>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<https://www.rfc-editor.org/info/rfc5905>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，DOI 10.17487/RFC6480，2012年2月<https://www.rfc-editor.org/info/rfc6480>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
[RFC6481]Huston，G.，Loomans，R.，和G.Michaelson，“资源证书存储库结构的配置文件”，RFC 6481，DOI 10.17487/RFC6481，2012年2月<https://www.rfc-editor.org/info/rfc6481>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482]Lepinski，M.，Kent，S.，和D.Kong，“路线原产地授权（ROA）的概要”，RFC 6482，DOI 10.17487/RFC6482，2012年2月<https://www.rfc-editor.org/info/rfc6482>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>.
[RFC6916]Gagliano，R.，Kent，S.和S.Turner，“资源公钥基础设施（RPKI）的算法敏捷程序”，BCP 182，RFC 6916，DOI 10.17487/RFC6916，2013年4月<https://www.rfc-editor.org/info/rfc6916>.
[RFC8206] George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, September 2017, <http://www.rfc-editor.org/info/rfc8206>.
[RFC8206]George，W.和S.Murphy，“BGPsec对自主系统（AS）迁移的考虑”，RFC 8206，DOI 10.17487/RFC8206，2017年9月<http://www.rfc-editor.org/info/rfc8206>.
[ROLLOVER] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", Work in Progess, draft-ietf-sidrops-bgpsec-rollover-02, August 2017.
[滚动]Weis，B.，Gagliano，R.，和K.Patel，“BGPsec路由器证书滚动”，工作进展，草稿-ietf-sidrops-BGPsec-ROLLOVER-022017年8月。
Acknowledgements
致谢
The author wishes to thank Thomas King, Arnold Nipper, Alvaro Retana, and the BGPsec design group.
作者希望感谢托马斯·金、阿诺德·尼珀、阿尔瓦罗·雷塔纳和BGPsec设计小组。
Author's Address
作者地址
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America
兰迪·布什互联网倡议日本5147水晶泉班布里奇岛，华盛顿98110美利坚合众国
Email: randy@psg.com
Email: randy@psg.com