Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 8635 IIJ Lab & Arrcus
Category: Standards Track S. Turner
ISSN: 2070-1721 sn3rd
K. Patel
Arrcus, Inc.
August 2019
Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 8635 IIJ Lab & Arrcus
Category: Standards Track S. Turner
ISSN: 2070-1721 sn3rd
K. Patel
Arrcus, Inc.
August 2019
Router Keying for BGPsec
BGPsec的路由器密钥
Abstract
摘要
BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.
讲BGPsec的路由器配备了私钥，以便签署BGPsec公告。相应的公钥在全局资源公钥基础设施（RPKI）中发布，从而能够验证BGPsec消息。本文档描述了生成公私密钥对的两种方法：路由器驱动和操作员驱动。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8635.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8635.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Management/Router Communication . . . . . . . . . . . . . . . 3
4. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4
5. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Router-Driven Keys . . . . . . . . . . . . . . . . . . . 5
6.2. Operator-Driven Keys . . . . . . . . . . . . . . . . . . 6
6.2.1. Using PKCS#8 to Transfer Private Keys . . . . . . . . 6
7. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7
8. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7
9. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8
10. Key Management . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Key Rollover . . . . . . . . . . . . . . . . . . . . . . 10
10.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . 11
10.4. Router Replacement . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Management/Router Channel Security . . . . . . . . . 17
Appendix B. An Introduction to BGPsec Key Management . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Management/Router Communication . . . . . . . . . . . . . . . 3
4. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4
5. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Router-Driven Keys . . . . . . . . . . . . . . . . . . . 5
6.2. Operator-Driven Keys . . . . . . . . . . . . . . . . . . 6
6.2.1. Using PKCS#8 to Transfer Private Keys . . . . . . . . 6
7. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7
8. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7
9. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8
10. Key Management . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Key Rollover . . . . . . . . . . . . . . . . . . . . . . 10
10.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . 11
10.4. Router Replacement . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Management/Router Channel Security . . . . . . . . . 17
Appendix B. An Introduction to BGPsec Key Management . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
BGPsec-speaking routers are provisioned with private keys, which allow them to digitally sign BGPsec announcements. To verify the signature, the public key, in the form of a certificate [RFC8209], is published in the Resource Public Key Infrastructure (RPKI). This document describes provisioning of BGPsec-speaking routers with the appropriate public-private key pairs. There are two methods: router-driven and operator-driven.
讲BGPsec的路由器配备了私钥，允许它们对BGPsec公告进行数字签名。为了验证签名，以证书[RFC8209]的形式在资源公钥基础设施（RPKI）中发布公钥。本文档描述了使用适当的公私密钥对提供讲BGPsec的路由器。有两种方法：路由器驱动和操作员驱动。
These two methods differ in where the keys are generated: on the router in the router-driven method, and elsewhere in the operator-driven method.
这两种方法在生成密钥的位置上有所不同：在路由器上使用路由器驱动方法，在其他地方使用操作员驱动方法。
The two methods also differ in who generates the private/public key pair: the operator generates the pair and sends it to the router in the operator-driven method, and the router generates its own pair in the router-driven method.
这两种方法在谁生成私钥/公钥对方面也有所不同：运营商生成私钥/公钥对并以运营商驱动的方法将其发送给路由器，而路由器以路由器驱动的方法生成自己的私钥/公钥对。
The router-driven method mirrors the model used by traditional PKI subscribers; the private key never leaves trusted storage (e.g., Hardware Security Module (HSM)). This is by design and supports classic PKI Certification Policies for (often human) subscribers that require the private key only ever be controlled by the subscriber to ensure that no one can impersonate the subscriber. For non-humans, this method does not always work. The operator-driven method is motivated by the extreme importance placed on ensuring the continued operation of the network. In some deployments, the same private key needs to be installed in the soon-to-be online router that was used by the soon-to-be offline router, since this "hot-swapping" behavior can result in minimal downtime, especially compared with the normal RPKI procedures to propagate a new key, which can take a day or longer to converge.
路由器驱动的方法反映了传统PKI用户使用的模型；私钥永远不会离开受信任的存储（例如，硬件安全模块（HSM））。这是通过设计实现的，并且支持经典的PKI认证策略（通常为人工）订阅者，这些订阅者要求私钥仅由订阅者控制，以确保没有人可以模拟订阅者。对于非人类，这种方法并不总是有效的。运营商驱动方法的动机是确保网络持续运行的极端重要性。在某些部署中，需要在即将脱机的路由器使用的即将联机的路由器中安装相同的私钥，因为这种“热交换”行为会导致最小的停机时间，特别是与传播新密钥的正常RPKI过程相比，这可能需要一天或更长的时间才能收敛。
For example, when an operator wants to support hot-swappable routers, the same private key needs to be installed in the soon-to-be online router that was used by the soon-to-be offline router. This motivated the operator-driven method.
例如，当运营商希望支持热插拔路由器时，需要在即将联机的路由器中安装与即将脱机的路由器相同的私钥。这激发了操作员驱动的方法。
Sections 3 through 8 describe the various steps involved for an operator to use the two methods to provision new and existing routers. The methods described involve the operator configuring the two endpoints (i.e., the management station and the router) and acting as the intermediary. Section 9 describes another method that requires more-capable routers.
第3节至第8节描述了运营商使用这两种方法提供新路由器和现有路由器所涉及的各个步骤。所描述的方法涉及操作员配置两个端点（即，管理站和路由器）并充当中介。第9节描述了另一种需要更多功能路由器的方法。
Useful References: [RFC8205] describes the details of BGPsec, [RFC8209] specifies the format for the PKCS#10 certification request, and [RFC8608] specifies the algorithms used to generate the PKCS#10 signature.
有用参考资料：[RFC8205]介绍了BGPsec的详细信息，[RFC8209]指定了PKCS#10认证请求的格式，[RFC8608]指定了用于生成PKCS#10签名的算法。
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]所述进行解释。
Operators are free to use either the router-driven or the operator-driven method as supported by the platform. Prudent security practice recommends router-generated keying, if the delay in replacing a router (or router engine) is acceptable to the operator. Regardless of the method chosen, operators first establish a protected channel between the management system and the router; this
运营商可以自由使用平台支持的路由器驱动或运营商驱动方法。谨慎的安全实践建议，如果操作员可以接受更换路由器（或路由器引擎）的延迟，则路由器生成密钥。无论选择何种方法，运营商首先在管理系统和路由器之间建立受保护的通道；这
protected channel prevents eavesdropping, tampering, and message forgery. It also provides mutual authentication. How this protected channel is established is router-specific and is beyond scope of this document. Though other configuration mechanisms might be used, e.g., the Network Configuration Protocol (NETCONF) (see [RFC6470]), the protected channel used between the management platform and the router is assumed to be an SSH-protected CLI. See Appendix A for security considerations for this protected channel.
受保护的通道可防止窃听、篡改和消息伪造。它还提供相互认证。如何建立此受保护通道是特定于路由器的，超出了本文档的范围。尽管可能会使用其他配置机制，例如网络配置协议（NETCONF）（请参阅[RFC6470]），但管理平台和路由器之间使用的受保护通道被假定为SSH保护的CLI。有关此受保护通道的安全注意事项，请参见附录A。
The previous paragraph assumes the management-system-to-router communications are over a network. When the management system has a direct physical connection to the router, e.g., via the craft port, there is no assumption that there is a protected channel between the two.
上一段假设管理系统到路由器的通信是通过网络进行的。当管理系统与路由器有直接的物理连接时，例如，通过craft端口，不假设两者之间存在受保护的通道。
To be clear, for both of these methods, an initial leap of faith is required because the router has no keying material that it can use to protect communications with anyone or anything. Because of this initial leap of faith, a direct physical connection is safer than a network connection because there is less chance of a monkey in the middle. Once keying material is established on the router, the communications channel must prevent eavesdropping, tampering, and message forgery. This initial leap of faith will no longer be required once routers are delivered to operators with operator-trusted keying material.
需要明确的是，对于这两种方法，都需要最初的信任飞跃，因为路由器没有可以用来保护与任何人或任何东西的通信的密钥材料。因为这种信念的最初飞跃，直接的物理连接比网络连接更安全，因为猴子在中间的可能性更小。一旦在路由器上建立了密钥材料，通信通道必须防止窃听、篡改和消息伪造。一旦路由器交付给具有运营商信任密钥材料的运营商，这种最初的信念飞跃将不再需要。
A number of options exist for the operator's management station to exchange PKI-related information with routers and with the RPKI including:
运营商管理站可通过多种方式与路由器和RPKI交换PKI相关信息，包括：
o Using application/pkcs10 media type [RFC5967] to extract certificate requests and application/pkcs7-mime [RFC8551] to return the issued certificate,
o 使用application/pkcs10媒体类型[RFC5967]提取证书请求，并使用application/pkcs7 mime[RFC8551]返回颁发的证书，
o Using FTP or HTTP per [RFC2585], and
o 根据[RFC2585]使用FTP或HTTP，以及
o Using the Enrollment over Secure Transport (EST) protocol per [RFC7030].
o 按照[RFC7030]使用安全传输注册（EST）协议。
Despite the fact that certificates are integrity-protected and do not necessarily need additional protection, transports that also provide integrity protection are RECOMMENDED.
尽管证书受完整性保护，并且不一定需要额外的保护，但建议使用也提供完整性保护的传输。
To start, the operator uses the protected channel to install the appropriate RPKI Trust Anchor's Certificate (TA Certificate) in the router. This will later enable the router to validate the router certificate returned in the PKCS#7 certs-only message [RFC8551].
首先，操作员使用受保护通道在路由器中安装适当的RPKI信任锚证书（TA证书）。这将使路由器稍后能够验证PKCS#7 certs only消息[RFC8551]中返回的路由器证书。
The operator configures the Autonomous System (AS) number to be used in the generated router certificate. This may be the sole AS configured on the router or an operator choice if the router is configured with multiple ASes. A router with multiple ASes can generate multiple router certificates by following the process described in this document for each desired certificate. This configured AS number is also used during verification of keys, if generated by the operator (see Section 6.2), as well as during certificate verification steps (see Sections 7, 8, and 9).
操作员配置要在生成的路由器证书中使用的自治系统（AS）编号。如果路由器配置了多个ASE，则这可能是路由器上配置的唯一ASE或操作员选择。具有多个ASE的路由器可以按照本文档中描述的每个所需证书的过程生成多个路由器证书。如果由操作员生成（参见第6.2节），则在验证密钥期间以及证书验证步骤期间（参见第7、8和9节），也会使用此配置为数字的密钥。
The operator configures or extracts from the router the BGP Identifier [RFC6286] to be used in the generated router certificate. In the case where the operator has chosen not to use unique per-router certificates, a BGP Identifier of 0 MAY be used.
操作员从路由器配置或提取BGP标识符[RFC6286]，以便在生成的路由器证书中使用。在运营商选择不使用每路由器唯一证书的情况下，可以使用BGP标识符0。
The operator configures the router's access control mechanism to ensure that only authorized users are able to later access the router's configuration.
运营商配置路由器的访问控制机制，以确保只有授权用户以后才能访问路由器的配置。
The private key, and hence the PKCS#10 certification request, which is sometimes referred to as a Certificate Signing Request (CSR), may be generated by the router or by the operator.
私钥以及PKCS#10认证请求（有时称为证书签名请求（CSR））可能由路由器或运营商生成。
Retaining the CSR allows for verifying that the returned public key in the certificate corresponds to the private key used to generate the signature on the CSR.
保留CSR允许验证证书中返回的公钥是否与用于在CSR上生成签名的私钥相对应。
NOTE: The PKCS#10 certification request does not include the AS number or the BGP Identifier for the router certificate. Therefore, the operator transmits the AS it has chosen on the router as well as the BGP Identifier when it sends the CSR to the CA.
注意：PKCS#10认证请求不包括AS编号或路由器证书的BGP标识符。因此，运营商在向CA发送CSR时，按照其在路由器上选择的方式发送CSR以及BGP标识符。
In the router-driven method, once the protected channel is established and the initial setup (Section 5) performed, the operator issues a command or commands for the router to generate the public-private key pair, to generate the PKCS#10 certification request, and
在路由器驱动的方法中，一旦建立了受保护的信道并执行了初始设置（第5节），操作员就向路由器发出一个或多个命令，以生成公钥-私钥对，生成PKCS#10认证请求，以及
to sign the PKCS#10 certification request with the private key. Once the router has generated the PKCS#10 certification request, it returns it to the operator over the protected channel.
使用私钥签署PKCS#10认证请求。一旦路由器生成PKCS#10认证请求，它会通过受保护的通道将其返回给运营商。
The operator includes the chosen AS number and the BGP Identifier when it sends the CSR to the CA.
运营商在向CA发送CSR时，包括所选AS编号和BGP标识符。
Even if the operator cannot extract the private key from the router, this signature still provides a link between a private key and a router. That is, the operator can verify the proof of possession (POP), as required by [RFC6484].
即使运营商无法从路由器提取私钥，该签名仍然提供私钥和路由器之间的链接。也就是说，操作员可以按照[RFC6484]的要求验证占有证明（POP）。
NOTE: The CA needs to know that the router-driven CSR is authorized. The easiest way to accomplish this is for the operator to mediate the communication with the CA. Other workflows are possible, e.g., where the router sends the CSR to the CA but the operator logs in to the CA independently and is presented with a list of pending requests to approve. See Section 9 for an additional workflow.
注意：CA需要知道路由器驱动的CSR已被授权。实现这一点的最简单方法是由运营商调解与CA的通信。也可以使用其他工作流，例如，路由器向CA发送CSR，但运营商独立登录到CA，并显示待批准请求的列表。有关其他工作流，请参见第9节。
If a router was to communicate directly with a CA to have the CA certify the PKCS#10 certification request, there would be no way for the CA to authenticate the router. As the operator knows the authenticity of the router, the operator mediates the communication with the CA.
如果路由器直接与CA通信，让CA认证PKCS#10认证请求，CA将无法认证路由器。由于运营商知道路由器的真实性，因此运营商调解与CA的通信。
In the operator-driven method, the operator generates the public-private key pair on a management station and installs the private key into the router over the protected channel. Beware that experience has shown that copy-and-paste from a management station to a router can be unreliable for long texts.
在操作员驱动的方法中，操作员在管理站上生成公钥-私钥对，并通过受保护的通道将私钥安装到路由器中。请注意，经验表明，从管理站到路由器的复制和粘贴对于长文本来说是不可靠的。
The operator then creates and signs the PKCS#10 certification request with the private key; the operator includes the chosen AS number and the BGP Identifier when it sends the CSR to the CA.
然后，操作员使用私钥创建并签署PKCS#10认证请求；运营商在向CA发送CSR时，包括所选AS编号和BGP标识符。
A private key can be encapsulated in a PKCS#8 Asymmetric Key Package [RFC5958] and SHOULD be further encapsulated in Cryptographic Message Syntax (CMS) SignedData [RFC5652] and signed with the operator's End Entity (EE) private key.
私钥可以封装在PKCS#8非对称密钥包[RFC5958]中，并应进一步封装在加密消息语法（CMS）SignedData[RFC5652]中，并使用操作员的终端实体（EE）私钥进行签名。
The router SHOULD verify the signature of the encapsulated PKCS#8 to ensure the returned private key did in fact come from the operator, but this requires that the operator also provision via the CLI or include in the SignedData the RPKI CA certificate and relevant
路由器应验证封装PKCS#8的签名，以确保返回的私钥确实来自运营商，但这要求运营商也通过CLI提供或在签名数据中包含RPKI CA证书和相关证书
operators' EE certificate(s). The router SHOULD inform the operator whether or not the signature validates to a trust anchor; this notification mechanism is out of scope.
操作员EE证书。路由器应通知操作员签名是否对信任锚进行验证；此通知机制超出范围。
The operator uses RPKI management tools to communicate with the Global RPKI system to have the appropriate CA validate the PKCS#10 certification request, sign the key in the PKCS#10 (i.e., certify it), generate a PKCS#7 certs-only message, and publish the certificate in the Global RPKI. External network connectivity may be needed if the certificate is to be published in the Global RPKI.
运营商使用RPKI管理工具与全球RPKI系统通信，让适当的CA验证PKCS#10认证请求，在PKCS#10中签名密钥（即认证），生成PKCS#7 certs only消息，并在全球RPKI中发布证书。如果要在全局RPKI中发布证书，则可能需要外部网络连接。
After the CA certifies the key, it does two things:
CA认证密钥后，将执行两项操作：
1. Publishes the certificate in the Global RPKI. The CA must have connectivity to the relevant publication point, which, in turn, must have external network connectivity as it is part of the Global RPKI.
1. 在全局RPKI中发布证书。CA必须连接到相关发布点，而发布点又必须具有外部网络连接，因为它是全局RPKI的一部分。
2. Returns the certificate to the operator's management station, packaged in a PKCS#7 certs-only message, using the corresponding method by which it received the certificate request. It SHOULD include the certificate chain below the TA Certificate so that the router can validate the router certificate.
2. 使用接收证书请求的相应方法，将证书返回给操作员的管理站，并封装在PKCS#7 certs only消息中。它应该包括TA证书下面的证书链，以便路由器可以验证路由器证书。
In the operator-driven method, the operator SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key the operator holds corresponds to the returned public key in the PKCS#7 certs-only message. If the operator saved the PKCS#10, it can check this correspondence by comparing the public key in the CSR to the public key in the returned certificate. If the operator has not saved the PKCS#10, it can check this correspondence by regenerating the public key from the private key and then verifying that the regenerated public key matches the public key returned in the certificate.
在操作员驱动的方法中，操作员应从PKCS#7 certs only消息中提取证书，并验证操作员持有的公钥是否对应于PKCS#7 certs only消息中返回的公钥。如果操作员保存了PKCS#10，则可以通过比较CSR中的公钥和返回证书中的公钥来检查此对应关系。如果操作员尚未保存PKCS#10，则可以通过从私钥重新生成公钥，然后验证重新生成的公钥是否与证书中返回的公钥匹配来检查此对应关系。
In the operator-driven method, the operator has already installed the private key in the router (see Section 6.2).
在操作员驱动的方法中，操作员已经在路由器中安装了私钥（参见第6.2节）。
The operator provisions the PKCS#7 certs-only message into the router over the protected channel.
运营商通过受保护的通道将PKCS#7 certs only消息提供给路由器。
The router SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key corresponds to the stored private key. If the router stored the PKCS#10, it can check this
路由器应从PKCS#7 certs only消息中提取证书，并验证公钥是否与存储的私钥相对应。如果路由器存储了PKCS#10，它可以检查这一点
correspondence by comparing the public key in the CSR to the public key in the returned certificate. If the router did not store the PKCS#10, it can check this correspondence by generating a signature on any data and then verifying the signature using the returned certificate. The router SHOULD inform the operator whether it successfully received the certificate and whether or not the keys correspond; the mechanism is out of scope.
通过比较CSR中的公钥与返回证书中的公钥进行通信。如果路由器没有存储PKCS#10，它可以通过在任何数据上生成签名，然后使用返回的证书验证签名来检查此通信。路由器应通知操作员是否成功接收证书，以及密钥是否对应；该机制超出了范围。
The router SHOULD also verify that the returned certificate validates back to the installed TA Certificate, i.e., the entire chain from the installed TA Certificate through subordinate CAs to the BGPsec certificate validate. To perform this verification, the CA certificate chain needs to be returned along with the router's certificate in the PKCS#7 certs-only message. The router SHOULD inform the operator whether or not the signature validates to a trust anchor; this notification mechanism is out of scope.
路由器还应验证返回的证书是否验证回已安装的TA证书，即从已安装的TA证书通过下级CA到BGPsec证书验证的整个链。要执行此验证，需要在PKCS#7 certs only消息中返回CA证书链以及路由器的证书。路由器应通知操作员签名是否对信任锚进行验证；此通知机制超出范围。
NOTE: The signature on the PKCS#8 and Certificate need not be made by the same entity. Signing the PKCS#8 permits more-advanced configurations where the entity that generates the keys is not the direct CA.
注：PKCS#8和证书上的签名无需由同一实体进行。签署PKCS#8允许更高级的配置，其中生成密钥的实体不是直接CA。
More PKI-capable routers can take advantage of increased functionality and lighten the operator's burden. Typically, these routers include either preinstalled manufacturer-driven certificates (e.g., IEEE 802.1 AR [IEEE802-1AR]) or preinstalled manufacturer-driven Pre-Shared Keys (PSKs) as well as PKI-enrollment functionality and transport protocol, e.g., CMC's "Secure Transport" [RFC7030] or the original CMC transport protocols [RFC5273]. When the operator first establishes a protected channel between the management system and the router, this preinstalled key material is used to authenticate the router.
更多支持PKI的路由器可以利用增加的功能，减轻运营商的负担。通常，这些路由器包括预安装的制造商驱动的证书（例如IEEE 802.1 AR[IEEE802-1AR]）或预安装的制造商驱动的预共享密钥（PSK）以及PKI注册功能和传输协议，例如CMC的“安全传输”[RFC7030]或原始CMC传输协议[RFC5273]。当操作员首次在管理系统和路由器之间建立受保护的通道时，此预安装的密钥材料用于验证路由器。
The operator's burden shifts here to include:
操作员的负担在此转移，包括：
1. Securely communicating the router's authentication material to the CA prior to the operator initiating the router's CSR. CAs use authentication material to determine whether the router is eligible to receive a certificate. At a minimum, authentication material includes the router's AS number and BGP Identifier as well as the router's key material, but it can also include additional information. Authentication material can be communicated to the CA (i.e., CSRs signed by this key material are issued certificates with this AS and BGP Identifier) or to the router (i.e., the operator uses the vendor-supplied management interface to include the AS number and BGP Identifier
1. 在操作员启动路由器的CSR之前，安全地将路由器的认证材料传送给CA。CA使用身份验证材料来确定路由器是否有资格接收证书。认证材料至少包括路由器的AS编号和BGP标识符以及路由器的密钥材料，但也可以包括附加信息。认证材料可以传送到CA（即，由该密钥材料签署的CSR是使用该AS和BGP标识符颁发的证书）或路由器（即，运营商使用供应商提供的管理界面包括AS编号和BGP标识符）
in the router-driven CSR). The CA stores this authentication material in an account entry for the router so that it can later be compared against the CSR prior to the CA issuing a certificate to the router.
在路由器驱动的CSR中）。CA将此身份验证材料存储在路由器的帐户条目中，以便在CA向路由器颁发证书之前将其与CSR进行比较。
2. Enabling the router to communicate with the CA. While the router-to-CA communications are operator-initiated, the operator's management interface need not be involved in the communications path. Enabling the router-to-CA connectivity may require connections to external networks (i.e., through firewalls, NATs, etc.).
2. 使路由器能够与CA通信。当路由器到CA的通信由操作员发起时，通信路径中不需要涉及操作员的管理接口。启用路由器到CA的连接可能需要连接到外部网络（即，通过防火墙、NAT等）。
3. Ensuring the cryptographic chain of custody from the manufacturer. For the preinstalled key material, the operator needs guarantees that either no one has accessed the private key or an authenticated log of those who have accessed it MUST be provided to the operator.
3. 确保来自制造商的加密监管链。对于预安装的密钥材料，操作员需要确保没有人访问私钥，或者必须向操作员提供访问私钥的人的经过身份验证的日志。
Once configured, the operator can begin the process of enrolling the router. Because the router is communicating directly with the CA, there is no need for the operator to retrieve the PKCS#10 certification request from the router as in Section 6 or return the PKCS#7 certs-only message to the router as in Section 7. Note that the checks performed by the router in Section 8 (namely, extracting the certificate from the PKCS#7 certs-only message, verifying that the public key corresponds to the private key, and verifying that the returned certificate validated back to an installed trust anchor) SHOULD be performed. Likewise, the router SHOULD notify the operator if any of these fail, but this notification mechanism is out of scope.
配置后，操作员可以开始注册路由器的过程。由于路由器直接与CA通信，操作员无需如第6节所述从路由器检索PKCS#10认证请求，也无需如第7节所述向路由器返回PKCS#7 certs only消息。请注意，应该执行路由器在第8节中执行的检查（即，从PKCS#7 certs only消息中提取证书，验证公钥是否对应于私钥，以及验证返回的证书是否验证回已安装的信任锚点）。同样，如果其中任何一个失败，路由器应该通知操作员，但此通知机制超出范围。
When a router is so configured, the communication with the CA SHOULD be automatically re-established by the router at future times to renew the certificate automatically when necessary (see Section 10). This further reduces the tasks required of the operator.
当路由器如此配置时，路由器应在将来自动重新建立与CA的通信，以便在必要时自动更新证书（参见第10节）。这进一步减少了操作员所需的任务。
Key management not only includes key generation, key provisioning, certificate issuance, and certificate distribution, it also includes assurance of key validity, key rollover, and key preservation during router replacement. All of these responsibilities persist for as long as the operator wishes to operate the BGPsec-speaking router.
密钥管理不仅包括密钥生成、密钥供应、证书颁发和证书分发，还包括在路由器更换期间保证密钥有效性、密钥翻转和密钥保留。只要运营商希望操作BGPsec语音路由器，所有这些责任都将持续。
It is critical that a BGPsec-speaking router is signing with a valid private key at all times. To this end, the operator needs to ensure the router always has an unexpired certificate. That is, the key used to sign BGPsec announcements always has an associated certificate whose expiry time is after the current time.
讲BGPsec的路由器必须始终使用有效的私钥进行签名，这一点至关重要。为此，运营商需要确保路由器始终具有未过期的证书。也就是说，用于签署BGPsec公告的密钥始终具有一个相关证书，其到期时间在当前时间之后。
Ensuring this is not terribly difficult but requires that either:
确保这不是非常困难，但需要：
1. The router has a mechanism to notify the operator that the certificate has an impending expiration, and/or
1. 路由器具有通知操作员证书即将过期的机制，和/或
2. The operator notes the expiry time of the certificate and uses a calendaring program to remind them of the expiry time, and/or
2. 操作员记录证书的到期时间，并使用日历程序提醒他们到期时间，和/或
3. The RPKI CA warns the operator of pending expiration, and/or
3. RPKI CA警告操作员等待到期，和/或
4. The operator uses some other kind of automated process to search for and track the expiry times of router certificates.
4. 运营商使用某种其他类型的自动化过程来搜索和跟踪路由器证书的到期时间。
It is advisable that expiration warnings happen well in advance of the actual expiry time.
建议在实际到期时间之前提前发出到期警告。
Regardless of the technique used to track router certificate expiry times, additional operators in the same organization should be notified as the expiry time approaches, thereby ensuring that the forgetfulness of one operator does not affect the entire organization.
无论使用何种技术跟踪路由器证书到期时间，当到期时间临近时，应通知同一组织中的其他运营商，从而确保一个运营商的遗忘不会影响整个组织。
Depending on inter-operator relationships, it may be helpful to notify a peer operator that one or more of their certificates are about to expire.
根据操作员之间的关系，通知对等操作员其一个或多个证书即将过期可能会有所帮助。
Routers that support multiple private keys also greatly increase the chance that routers can continuously speak BGPsec because the new private key and certificate can be obtained and distributed prior to expiration of the operational key. Obviously, the router needs to know when to start using the new key. Once the new key is being used, having the already-distributed certificate ensures continuous operation.
支持多个私钥的路由器也极大地增加了路由器持续使用BGPsec的机会，因为新的私钥和证书可以在操作密钥到期之前获得和分发。显然，路由器需要知道何时开始使用新密钥。使用新密钥后，拥有已分发的证书可确保连续操作。
More information on how to proceed with a key rollover is described in [RFC8634].
[RFC8634]中介绍了有关如何进行钥匙翻转的更多信息。
In certain circumstances, a router's BGPsec certificate may need to be revoked. When this occurs, the operator needs to use the RPKI CA system to revoke the certificate by placing the router's BGPsec certificate on the Certificate Revocation List (CRL) as well as re-keying the router's certificate.
在某些情况下，路由器的BGPsec证书可能需要撤销。发生这种情况时，操作员需要使用RPKI CA系统，通过将路由器的BGPsec证书放在证书吊销列表（CRL）上以及重新键入路由器的证书来吊销证书。
The process of revoking an active router key consists of requesting the revocation from the CA, the CA actually revoking the router's certificate, the re-keying/renewing of the router's certificate (possibly) distributing a new key and certificate to the router, and distributing the status. During the time this process takes, the operator must decide how they wish to maintain continuity of operation (with or without the compromised private key) or whether they wish to bring the router offline to address the compromise.
撤销活动路由器密钥的过程包括从CA请求撤销、CA实际撤销路由器的证书、路由器证书（可能）的重设密钥/续订、向路由器分发新密钥和证书以及分发状态。在这一过程所需的时间内，运营商必须决定他们希望如何保持操作的连续性（使用或不使用泄露的私钥），或者他们是否希望使路由器离线以解决泄露问题。
Keeping the router operational and BGPsec-speaking is the ideal goal; but, if operational practices do not allow this, then reconfiguring the router to disable BGPsec is likely preferred to bringing the router offline.
保持路由器运行和BGPsec语音是理想的目标；但是，如果操作实践不允许这样做，那么将路由器重新配置为禁用BGPsec可能比使路由器离线更可取。
Routers that support more than one private key, where one is operational and other(s) are soon-to-be-operational, facilitate revocation events because the operator can configure the router to make a soon-to-be-operational key operational, request revocation of the compromised key, and then make a next generation soon-to-be-operational key. Hopefully, all this can be done without needing to take the router offline or reboot it. For routers that support only one operational key, the operators should create or install the new private key and then request revocation of the certificate corresponding to the compromised private key.
支持多个私钥的路由器（其中一个可操作，另一个可操作）有助于撤销事件的发生，因为运营商可以配置路由器使一个可操作密钥可操作，请求撤销受损密钥，然后使下一代可操作密钥可操作。希望所有这些都可以在不需要使路由器离线或重新启动的情况下完成。对于只支持一个操作密钥的路由器，运营商应创建或安装新的私钥，然后请求撤销与受损私钥对应的证书。
At the time of writing, routers often generate private keys for uses such as Secure Shell (SSH), and the private keys may not be seen or exported from the router. While this is good security, it creates difficulties when a routing engine or whole router must be replaced in the field and all software that accesses the router must be updated with the new keys. Also, any network-based initial contact with a new routing engine requires trust in the public key presented on first contact.
在撰写本文时，路由器通常会生成私钥以供使用，如Secure Shell（SSH），私钥可能无法在路由器中看到或导出。虽然这是很好的安全性，但当必须在现场更换路由引擎或整个路由器，并且必须使用新密钥更新访问路由器的所有软件时，这会造成困难。此外，与新路由引擎的任何基于网络的初始接触都需要信任第一次接触时提供的公钥。
To allow operators to quickly replace routers without requiring update and distribution of the corresponding public keys in the RPKI, routers SHOULD allow the private BGPsec key to be inserted via a protected channel, e.g., SSH, NETCONF (see [RFC6470]), and SNMP.
为了允许运营商在不需要更新和分发RPKI中相应公钥的情况下快速更换路由器，路由器应允许通过受保护的通道插入专用BGPsec密钥，例如SSH、NETCONF（请参见[RFC6470]）和SNMP。
This lets the operator escrow the old private key via the mechanism used for operator-driven keys (see Section 6.2), such that it can be reinserted into a replacement router. The router MAY allow the private key to be exported via the protected channel after key generation, but this SHOULD be paired with functionality that sets the newly generated key into a permanent non-exportable state to ensure that it is not exported at a future time by unauthorized operations.
这使得运营商可以通过用于运营商驱动密钥的机制（见第6.2节）托管旧私钥，以便将其重新插入替换路由器。路由器可允许在密钥生成后通过受保护通道导出私钥，但这应与将新生成的密钥设置为永久不可导出状态的功能相结合，以确保将来不会通过未经授权的操作导出私钥。
The router's manual will describe which of the key-generation options discussed in the earlier sections of this document a router supports or if it supports both of them. The manual will also describe other important security-related information (e.g., how to SSH to the router). After becoming familiar with the capabilities of the router, an operator is encouraged to ensure that the router is patched with the latest software updates available from the manufacturer.
路由器手册将描述路由器支持本文档前面章节中讨论的密钥生成选项，或者路由器是否支持这两个选项。本手册还将描述其他重要的安全相关信息（例如，如何通过SSH连接到路由器）。在熟悉路由器的功能后，鼓励操作员确保使用制造商提供的最新软件更新对路由器进行修补。
This document defines no protocols. So, in some sense, it introduces no new security considerations. However, it relies on many other protocols, and the security considerations in the referenced documents should be consulted; notably, the documents listed in Section 1 should be consulted first. PKI-relying protocols, of which BGPsec is one, have many issues to consider -- so many, in fact, entire books have been written to address them -- so listing all PKI-related security considerations is neither useful nor helpful. Regardless, some bootstrapping-related issues that are worth repeating are listed here:
本文件未定义任何协议。因此，在某种意义上，它没有引入新的安全考虑。但是，它依赖于许多其他协议，应参考参考文件中的安全考虑因素；值得注意的是，应首先查阅第1节中列出的文件。PKI依赖协议，其中BGPsec是一个，有许多问题需要考虑——事实上，许多书都是为了解决这些问题而编写的，因此列出所有PKI相关的安全考虑既不有用也没有帮助。无论如何，下面列出了一些值得重复的与引导相关的问题：
o Public-private key pair generation: Mistakes here are, for all practical purposes, catastrophic because PKIs rely on the pairing of a difficult-to-generate public-private key pair with a signer; all key pairs MUST be generated from a good source of non-deterministic random input [RFC4086].
o 公钥-私钥对生成：这里的错误对于所有实际目的来说都是灾难性的，因为PKI依赖于难以生成的公钥-私钥对与签名者的配对；所有密钥对必须从非确定性随机输入的良好来源生成[RFC4086]。
o Private key protection at rest: Mistakes here are, for all, practical purposes, catastrophic because disclosure of the private key allows another entity to masquerade as (i.e., impersonate) the signer; all private keys MUST be protected when at rest in a secure fashion. Obviously, how each router protects private keys is implementation specific. Likewise, the local storage format for the private key is just that: a local matter.
o 静态私钥保护：出于实际目的，这里的错误是灾难性的，因为私钥的泄露允许另一个实体冒充（即，冒充）签名者；所有私钥在静止时必须以安全的方式进行保护。显然，每个路由器如何保护私钥是特定于实现的。类似地，私钥的本地存储格式也是：本地事务。
o Private key protection in transit: Mistakes here are, for all practical purposes, catastrophic because disclosure of the private key allows another entity to masquerade as (i.e., impersonate) the
o 传输中的私钥保护：出于所有实际目的，这里的错误都是灾难性的，因为私钥的泄露允许另一个实体伪装成（即，模拟）用户
signer; therefore, transport security is strongly RECOMMENDED. The level of security provided by the transport layer's security mechanism SHOULD be at least as good as the strength of the BGPsec key; there's no point in spending time and energy to generate an excellent public-private key pair and then transmit the private key in the clear or with a known-to-be-broken algorithm, as it just undermines trust that the private key has been kept private. Additionally, operators SHOULD ensure the transport security mechanism is up to date, in order to address all known implementation bugs.
签字人；因此，强烈建议运输安全。传输层安全机制提供的安全级别应至少与BGPsec密钥的强度相同；没有必要花费时间和精力来生成一个优秀的公私密钥对，然后以明文或已知被破坏的算法传输私钥，因为这只会破坏对私钥保密的信任。此外，运营商应确保传输安全机制是最新的，以解决所有已知的实施缺陷。
Though the CA's certificate is installed on the router and used to verify that the returned certificate is in fact signed by the CA, the revocation status of the CA's certificate is rarely checked as the router may not have global connectivity or CRL-aware software. The operator MUST ensure that the installed CA certificate is valid.
虽然CA的证书安装在路由器上，并用于验证返回的证书是否确实由CA签名，但很少检查CA证书的吊销状态，因为路由器可能没有全局连接或CRL感知软件。操作员必须确保安装的CA证书有效。
This document has no IANA actions.
本文档没有IANA操作。
[IEEE802-1AR] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", IEEE Std 802.1AR, <https://standards.ieee.org/standard/802_1AR-2018.html>.
[IEEE802-1AR]IEEE，“局域网和城域网的IEEE标准-安全设备标识”，IEEE标准802.1AR<https://standards.ieee.org/standard/802_1AR-2018.html>.
[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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<https://www.rfc-editor.org/info/rfc4086>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，DOI 10.17487/RFC4253，2006年1月<https://www.rfc-editor.org/info/rfc4253>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<https://www.rfc-editor.org/info/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/info/rfc5958>.
[RFC5958]Turner，S.，“非对称密钥包”，RFC 5958，DOI 10.17487/RFC5958，2010年8月<https://www.rfc-editor.org/info/rfc5958>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC6286]Chen，E.和J.Yuan，“BGP-4的自治系统范围唯一BGP标识符”，RFC 6286，DOI 10.17487/RFC6286，2011年6月<https://www.rfc-editor.org/info/rfc6286>.
[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>.
[RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8608, DOI 10.17487/RFC8608, June 2019, <https://www.rfc-editor.org/info/rfc8608>.
[RFC8608]Turner，S.和O.Borchert，“BGPsec算法、密钥格式和签名格式”，RFC 8608，DOI 10.17487/RFC8608，2019年6月<https://www.rfc-editor.org/info/rfc8608>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
[RFC8209]Reynolds，M.，Turner，S.和S.Kent，“BGPsec路由器证书、证书撤销列表和证书请求的配置文件”，RFC 8209，DOI 10.17487/RFC8209，2017年9月<https://www.rfc-editor.org/info/rfc8209>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8551]Schaad，J.，Ramsdell，B.，和S.Turner，“安全/多用途互联网邮件扩展（S/MIME）版本4.0消息规范”，RFC 8551，DOI 10.17487/RFC8551，2019年4月<https://www.rfc-editor.org/info/rfc8551>.
[RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", BCP 224, RFC 8634, DOI 10.17487/RFC8634, August 2019, <https://www.rfc-editor.org/info/rfc8634>.
[RFC8634]Weis，B.，Gagliano，R.，和K.Patel，“BGPsec路由器证书滚动”，BCP 224，RFC 8634，DOI 10.17487/RFC86342019年8月<https://www.rfc-editor.org/info/rfc8634>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/info/rfc2585>.
[RFC2585]Housley，R.和P.Hoffman，“互联网X.509公钥基础设施操作协议：FTP和HTTP”，RFC 2585，DOI 10.17487/RFC2585，1999年5月<https://www.rfc-editor.org/info/rfc2585>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, <https://www.rfc-editor.org/info/rfc3766>.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，DOI 10.17487/RFC3766，2004年4月<https://www.rfc-editor.org/info/rfc3766>.
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, DOI 10.17487/RFC5273, June 2008, <https://www.rfc-editor.org/info/rfc5273>.
[RFC5273]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）：传输协议”，RFC 5273，DOI 10.17487/RFC5273，2008年6月<https://www.rfc-editor.org/info/rfc5273>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/info/rfc5480>.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 5480，DOI 10.17487/RFC5480，2009年3月<https://www.rfc-editor.org/info/rfc5480>.
[RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", RFC 5647, DOI 10.17487/RFC5647, August 2009, <https://www.rfc-editor.org/info/rfc5647>.
[RFC5647]Igoe，K.和J.Solinas，“安全壳传输层协议的AES伽罗瓦计数器模式”，RFC 5647，DOI 10.17487/RFC5647，2009年8月<https://www.rfc-editor.org/info/rfc5647>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, <https://www.rfc-editor.org/info/rfc5656>.
[RFC5656]Stebila，D.和J.Green，“安全壳传输层中的椭圆曲线算法集成”，RFC 5656，DOI 10.17487/RFC5656，2009年12月<https://www.rfc-editor.org/info/rfc5656>.
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, DOI 10.17487/RFC5967, August 2010, <https://www.rfc-editor.org/info/rfc5967>.
[RFC5967]Turner，S.，“应用程序/pkcs10媒体类型”，RFC 5967，DOI 10.17487/RFC5967，2010年8月<https://www.rfc-editor.org/info/rfc5967>.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6187]Igoe，K.和D.Stebila，“用于安全外壳身份验证的X.509v3证书”，RFC 6187，DOI 10.17487/RFC6187，2011年3月<https://www.rfc-editor.org/info/rfc6187>.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) Base Notifications", RFC 6470, DOI 10.17487/RFC6470, February 2012, <https://www.rfc-editor.org/info/rfc6470>.
[RFC6470]Bierman，A.，“网络配置协议（NETCONF）基本通知”，RFC 6470，DOI 10.17487/RFC6470，2012年2月<https://www.rfc-editor.org/info/rfc6470>.
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, <https://www.rfc-editor.org/info/rfc6484>.
[RFC6484]Kent，S.，Kong，D.，Seo，K.，和R.Watro，“资源公钥基础设施（RPKI）的证书政策（CP）”，BCP 173，RFC 6484，DOI 10.17487/RFC64842012年2月<https://www.rfc-editor.org/info/rfc6484>.
[RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol", RFC 6668, DOI 10.17487/RFC6668, July 2012, <https://www.rfc-editor.org/info/rfc6668>.
[RFC6668]Bider，D.和M.Baushke，“安全外壳（SSH）传输层协议的SHA-2数据完整性验证”，RFC 6668，DOI 10.17487/RFC6668，2012年7月<https://www.rfc-editor.org/info/rfc6668>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[RFC7030]Pritikin，M.，Ed.，Yee，P.，Ed.，和D.Harkins，Ed.，“安全传输的注册”，RFC 7030，DOI 10.17487/RFC7030，2013年10月<https://www.rfc-editor.org/info/rfc7030>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205]Lepinski，M.，Ed.和K.Sriram，Ed.，“BGPsec协议规范”，RFC 8205，DOI 10.17487/RFC8205，2017年9月<https://www.rfc-editor.org/info/rfc8205>.
[SP800-57] National Institute of Standards and Technology (NIST), "Recommendation for Key Management - Part 1: General", NIST Special Publication 800-57 Revision 4, DOI 10.6028/NIST.SP.800-57pt1r4, January 2016, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>.
[SP800-57]国家标准与技术研究所（NIST），“关键管理建议-第1部分：概述”，NIST特别出版物800-57第4版，DOI 10.6028/NIST.SP.800-57pt1r4，2016年1月<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>。
Appendix A. Management/Router Channel Security
附录A.管理/路由器通道安全
Encryption, integrity, authentication, and key-exchange algorithms used by the protected channel should be of equal or greater strength than the BGPsec keys they protect, which for the algorithm specified in [RFC8608] is 128 bits; see [RFC5480] and [SP800-57] for information about this strength claim as well as [RFC3766] for "how to determine the length of an asymmetric key as a function of a symmetric key strength requirement". In other words, for the encryption algorithm, do not use export grade crypto (40-56 bits of security), and do not use Triple-DES (112 bits of security). Suggested minimum algorithms would be AES-128, specifically the following:
受保护通道使用的加密、完整性、身份验证和密钥交换算法的强度应等于或大于其保护的BGPsec密钥，对于[RFC8608]中指定的算法，BGPsec密钥的强度为128位；参见[RFC5480]和[SP800-57]了解有关此强度声明的信息，以及[RFC3766]了解“如何根据对称密钥强度要求确定非对称密钥的长度”。换句话说，对于加密算法，不要使用导出级加密（40-56位安全性），也不要使用三重DES（112位安全性）。建议的最小算法为AES-128，具体如下：
o aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for encryption,
o aes128 cbc[RFC4253]和AEAD_AES_128_GCM[RFC5647]用于加密，
o hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] for integrity,
o hmac-sha2-256[RFC6668]或AESAD_AES_128_GCM[RFC5647]的完整性，
o ecdsa-sha2-nistp256 [RFC5656] for authentication, and
o ecdsa-sha2-nistp256[RFC5656]用于身份验证，以及
o ecdh-sha2-nistp256 [RFC5656] for key exchange.
o ecdh-sha2-nistp256[RFC5656]用于密钥交换。
Some routers support the use of public key certificates and SSH. The certificates used for the SSH session are different than the certificates used for BGPsec. The certificates used with SSH should also enable a level of security at least as good as the security offered by the BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for authentication.
一些路由器支持使用公钥证书和SSH。SSH会话使用的证书与BGPsec使用的证书不同。与SSH一起使用的证书还应实现至少与BGPsec密钥提供的安全性相同的安全性级别；x509v3-ecdsa-sha2-nistp256[RFC6187]可用于身份验证。
The protected channel must provide confidentiality, authentication, and integrity and replay protection.
受保护通道必须提供机密性、身份验证、完整性和重播保护。
This appendix is informative. It attempts to explain some of the PKI jargon.
本附录为资料性附录。它试图解释一些PKI术语。
BGPsec speakers send signed BGPsec updates that are verified by other BGPsec speakers. In PKI parlance, the senders are referred to as "signers", and the receivers are referred to as "relying parties". The signers with which we are concerned here are routers signing BGPsec updates. Signers use private keys to sign, and relying parties use the corresponding public keys, in the form of X.509 public key certificates, to verify signatures. The third party involved is the entity that issues the X.509 public key certificate, the Certification Authority (CA). Key management is all about making these key pairs and the certificates, as well as ensuring that the relying parties trust that the certified public keys in fact correspond to the signers' private keys.
BGPsec发言人发送经其他BGPsec发言人验证的签名BGPsec更新。按照PKI的说法，发送方称为“签名方”，接收方称为“依赖方”。我们在这里关注的签名者是签署BGPsec更新的路由器。签名者使用私钥进行签名，依赖方使用X.509公钥证书形式的相应公钥来验证签名。涉及的第三方是颁发X.509公钥证书的实体，即证书颁发机构（CA）。密钥管理就是制作这些密钥对和证书，以及确保依赖方相信经认证的公钥实际上对应于签名者的私钥。
The specifics of key management greatly depend on the routers as well as management interfaces provided by the routers' vendor. Because of these differences, it is hard to write a definitive "how to", but this guide is intended to arm operators with enough information to ask the right questions. The other aspect that makes this guide informative is that the steps for the do-it-yourself (DIY) approach involve arcane commands while the GUI-based vendor-assisted management console approach will likely hide all of those commands behind some button clicks. Regardless, the operator will end up with a BGPsec-enabled router. Initially, we focus on the DIY approach and then follow up with some information about the GUI-based approach.
密钥管理的细节在很大程度上取决于路由器以及路由器供应商提供的管理接口。由于这些差异，很难编写明确的“如何操作”，但本指南旨在为操作员提供足够的信息，以提出正确的问题。使本指南内容丰富的另一个方面是，DIY方法的步骤涉及神秘的命令，而基于GUI的供应商辅助管理控制台方法可能会将所有这些命令隐藏在一些按钮点击之后。无论如何，运营商最终将拥有一个支持BGPsec的路由器。首先，我们关注DIY方法，然后介绍一些关于基于GUI的方法的信息。
The first step in the DIY approach is to generate a private key. However, in fact, what you do is create a key pair: one part (the private key) is kept very private, and the other part (the public key) is given out to verify whatever is signed. The two methods for how to create the key pair are the subject of this document, but it boils down to either doing it on-router (router-driven) or off-router (operator-driven).
DIY方法的第一步是生成私钥。然而，实际上，您要做的是创建一个密钥对：一部分（私钥）保持非常私密，另一部分（公钥）用于验证签名的内容。如何创建密钥对的两种方法是本文档的主题，但归根结底是在路由器上（路由器驱动）或非路由器上（操作员驱动）。
If you are generating keys on the router (router-driven), then you will need to access the router. Again, how you access the router is router-specific, but generally the DIY approach involves using the CLI and accessing the router either directly via the router's craft port or over the network on an administrative interface. If accessing the router over the network, be sure to do it securely (i.e., use SSHv2). Once logged into the router, issue a command or a series of commands that will generate the key pair for the algorithms referenced in the main body of this document; consult your router's documentation for the specific commands. The key-generation process
如果在路由器上生成密钥（路由器驱动），则需要访问路由器。同样，访问路由器的方式是特定于路由器的，但通常DIY方法涉及使用CLI并直接通过路由器的craft端口或通过管理界面上的网络访问路由器。如果通过网络访问路由器，请确保安全访问（即使用SSHv2）。登录路由器后，发出一条或一系列命令，生成本文件正文中所述算法的密钥对；有关特定命令，请参阅路由器的文档。密钥生成过程
will yield one or more files containing the private key and the public key; the file format varies depending on, among other things, the arcane command the operator issued; however, the files are generally DER- or PEM-encoded.
将产生一个或多个包含私钥和公钥的文件；文件格式根据操作员发出的神秘命令而变化；然而，这些文件通常是DER或PEM编码的。
The second step is to generate the certification request, which is often referred to as a Certificate Signing Request (CSR) or PKCS#10 certification request, and to send it to the CA to be signed. To generate the CSR, the operator issues some more arcane commands while logged into the router; using the private key just generated to sign the certification request with the algorithms referenced in the main body of this document; the CSR is signed to prove to the CA that the router has possession of the private key (i.e., the signature is the proof-of-possession). The output of the command is the CSR file; the file format varies depending on the arcane command you issued, but generally the files are DER- or PEM-encoded.
第二步是生成证书请求，通常称为证书签名请求（CSR）或PKCS#10证书请求，并将其发送给CA进行签名。为了生成CSR，操作员在登录路由器时发出一些更神秘的命令；使用刚刚生成的私钥，使用本文档正文中引用的算法对认证请求进行签名；签署CSR以向CA证明路由器拥有私钥（即，签名是拥有的证明）。命令的输出是CSR文件；文件格式因您发出的奥术命令而异，但通常情况下，文件是DER或PEM编码的。
The third step is to retrieve the signed CSR from the router and send it to the CA. But before sending it, you need to also send the CA the subject name (i.e., "ROUTER-" followed by the AS number) and serial number (i.e., the 32-bit BGP Identifier) for the router. The CA needs this information to issue the certificate. How you get the CSR to the CA is beyond the scope of this document. While you are still connected to the router, install the trust anchor for the root of the PKI. At this point, you no longer need access to the router for BGPsec-related initiation purposes.
第三步是从路由器检索已签名的CSR并将其发送给CA。但在发送之前，您还需要向CA发送路由器的主题名称（即“路由器-”后跟AS编号）和序列号（即32位BGP标识符）。CA需要此信息才能颁发证书。如何将CSR提交给CA超出了本文档的范围。当您仍然连接到路由器时，为PKI的根安装信任锚。此时，您不再需要出于BGPsec相关启动目的访问路由器。
The fourth step is for the CA to issue the certificate based on the CSR you sent. The certificate will include the subject name, serial number, public key, and other fields; it will also be signed by the CA. After the CA issues the certificate, the CA returns the certificate and posts the certificate to the RPKI repository. Check that the certificate corresponds to the public key contained in the certificate by verifying the signature on the CSR sent to the CA; this is just a check to make sure that the CA issued a certificate that includes a public key that is the pair of the private key (i.e., the math will work when verifying a signature generated by the private key with the returned certificate).
第四步是CA根据您发送的CSR颁发证书。证书将包括受试者姓名、序列号、公钥和其他字段；CA还将对其进行签名。CA颁发证书后，CA将返回证书并将证书发布到RPKI存储库。通过验证发送给CA的CSR上的签名，检查证书是否与证书中包含的公钥相对应；这只是一个检查，以确保CA颁发了一个证书，其中包含一个公钥，该公钥是私钥对（即，当使用返回的证书验证私钥生成的签名时，数学将起作用）。
If generating the keys off-router (operator-driven), then the same steps are used as with on-router key generation (possibly with the same arcane commands as those used in the on-router approach). However, no access to the router is needed, and the first three steps are done on an administrative workstation:
如果在路由器外生成密钥（操作员驱动），则使用与路由器上密钥生成相同的步骤（可能使用与路由器上方法相同的神秘命令）。但是，不需要访问路由器，前三个步骤在管理工作站上完成：
Step 1: Generate key pair. Step 2: Create CSR and sign CSR with private key. Step 3: Send CSR file with the subject name and serial number to CA.
步骤1：生成密钥对。步骤2：创建CSR并使用私钥签署CSR。步骤3：将带有主题名称和序列号的CSR文件发送到CA。
After the CA has returned the certificate and you have checked the certificate, you need to put the private key and trust anchor in the router. Assuming the DIY approach, you will be using the CLI and accessing the router either directly via the router's craft port or over the network on an admin interface; if accessing the router over the network, make doubly sure it is done securely (i.e., use SSHv2) because the private key is being moved over the network. At this point, access to the router is no longer needed for BGPsec-related initiation purposes.
CA返回证书并检查证书后，需要将私钥和信任锚放到路由器中。假设采用DIY方法，您将使用CLI，直接通过路由器的craft端口或通过管理界面上的网络访问路由器；如果通过网络访问路由器，请加倍确保安全地访问（即使用SSHv2），因为私钥正在通过网络移动。此时，与BGPsec相关的启动不再需要访问路由器。
NOTE: Regardless of the approach taken, the first three steps could trivially be collapsed by a vendor-provided script to yield the private key and the signed CSR.
注意：无论采取何种方法，前三个步骤都可能被供应商提供的脚本折叠，以生成私钥和签名的CSR。
Given a GUI-based vendor-assisted management console, all of these steps will likely be hidden behind pointing and clicking the way through BGPsec-enabling the router.
给定一个基于GUI的供应商辅助管理控制台，所有这些步骤都可能隐藏在指向和单击通过BGPsec启用路由器的路径之后。
The scenarios described above require the operator to access each router, which does not scale well to large networks. An alternative would be to create an image, perform the necessary steps to get the private key and trust anchor on the image, and then install the image via a management protocol.
上面描述的场景要求运营商访问每个路由器，这无法很好地扩展到大型网络。另一种方法是创建映像，执行必要的步骤以获取映像上的私钥和信任锚，然后通过管理协议安装映像。
One final word of advice: certificates include a notAfter field that unsurprisingly indicates when relying parties should no longer trust the certificate. To avoid having routers with expired certificates, follow the recommendations in the Certification Policy (CP) [RFC6484] and make sure to renew the certificate at least one week prior to the notAfter date. Set a calendar reminder in order not to forget!
最后一点建议：证书包含一个notAfter字段，它毫不奇怪地指示依赖方何时不再信任证书。为避免路由器的证书过期，请遵循认证策略（CP）[RFC6484]中的建议，并确保至少在证书过期前一周续订证书。设置日历提醒，以免忘记！
Authors' Addresses
作者地址
Randy Bush IIJ & Arrcus 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America
Randy Bush IIJ&Arrcus 5147 Crystal Springs班布里奇岛，华盛顿98110美利坚合众国
Email: randy@psg.com
Email: randy@psg.com
Sean Turner sn3rd
肖恩·特纳
Email: sean@sn3rd.com
Email: sean@sn3rd.com
Keyur Patel Arrcus, Inc.
凯乌尔·帕特尔·阿卡斯公司。
Email: keyur@arrcus.com
Email: keyur@arrcus.com