Internet Engineering Task Force (IETF) M. Lepinski, Ed.
Request for Comments: 8205 NCF
Category: Standards Track K. Sriram, Ed.
ISSN: 2070-1721 NIST
September 2017
Internet Engineering Task Force (IETF) M. Lepinski, Ed.
Request for Comments: 8205 NCF
Category: Standards Track K. Sriram, Ed.
ISSN: 2070-1721 NIST
September 2017
BGPsec Protocol Specification
BGPsec协议规范
Abstract
摘要
This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.
本文档描述了BGPsec，它是边界网关协议（BGP）的扩展，为自治系统（ASE）路径提供安全性，BGP更新消息通过该路径传递。BGPsec通过可选的非传递性BGP路径属性实现，该属性携带每个AS生成的数字签名，以传播更新消息。数字签名提供了更新消息中列出的ASE路径上的每个AS已明确授权公布路由的信心。
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/rfc8205.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8205.
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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . 3
2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 4
2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . 5
3. The BGPsec_PATH Attribute . . . . . . . . . . . . . . . . . . 6
3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 10
4. BGPsec UPDATE Messages . . . . . . . . . . . . . . . . . . . 11
4.1. General Guidance . . . . . . . . . . . . . . . . . . . . 11
4.2. Constructing the BGPsec_PATH Attribute . . . . . . . . . 14
4.3. Processing Instructions for Confederation Members . . . . 18
4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . 19
5. Processing a Received BGPsec UPDATE Message . . . . . . . . . 21
5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 23
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . 27
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . 27
6.2. Considerations for the SKI Size . . . . . . . . . . . . . 28
6.3. Extensibility Considerations . . . . . . . . . . . . . . 28
7. Operations and Management Considerations . . . . . . . . . . 29
7.1. Capability Negotiation Failure . . . . . . . . . . . . . 29
7.2. Preventing Misuse of pCount=0 . . . . . . . . . . . . . . 29
7.3. Early Termination of Signature Verification . . . . . . . 30
7.4. Non-deterministic Signature Algorithms . . . . . . . . . 30
7.5. Private AS Numbers . . . . . . . . . . . . . . . . . . . 30
7.6. Robustness Considerations for Accessing RPKI Data . . . . 32
7.7. Graceful Restart . . . . . . . . . . . . . . . . . . . . 32
7.8. Robustness of Secret Random Number in ECDSA . . . . . . . 32
7.9. Incremental/Partial Deployment Considerations . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 33
8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 34
8.3. Mitigation of Denial-of-Service Attacks . . . . . . . . . 36
8.4. Additional Security Considerations . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . 3
2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 4
2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . 5
3. The BGPsec_PATH Attribute . . . . . . . . . . . . . . . . . . 6
3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 10
4. BGPsec UPDATE Messages . . . . . . . . . . . . . . . . . . . 11
4.1. General Guidance . . . . . . . . . . . . . . . . . . . . 11
4.2. Constructing the BGPsec_PATH Attribute . . . . . . . . . 14
4.3. Processing Instructions for Confederation Members . . . . 18
4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . 19
5. Processing a Received BGPsec UPDATE Message . . . . . . . . . 21
5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 23
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . 27
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . 27
6.2. Considerations for the SKI Size . . . . . . . . . . . . . 28
6.3. Extensibility Considerations . . . . . . . . . . . . . . 28
7. Operations and Management Considerations . . . . . . . . . . 29
7.1. Capability Negotiation Failure . . . . . . . . . . . . . 29
7.2. Preventing Misuse of pCount=0 . . . . . . . . . . . . . . 29
7.3. Early Termination of Signature Verification . . . . . . . 30
7.4. Non-deterministic Signature Algorithms . . . . . . . . . 30
7.5. Private AS Numbers . . . . . . . . . . . . . . . . . . . 30
7.6. Robustness Considerations for Accessing RPKI Data . . . . 32
7.7. Graceful Restart . . . . . . . . . . . . . . . . . . . . 32
7.8. Robustness of Secret Random Number in ECDSA . . . . . . . 32
7.9. Incremental/Partial Deployment Considerations . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 33
8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 34
8.3. Mitigation of Denial-of-Service Attacks . . . . . . . . . 36
8.4. Additional Security Considerations . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
This document describes BGPsec, a mechanism for providing path security for Border Gateway Protocol (BGP) [RFC4271] route advertisements. That is, a BGP speaker who receives a valid BGPsec UPDATE message has cryptographic assurance that the advertised route has the following property: every Autonomous System (AS) on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route to the subsequent AS in the path.
本文档描述了BGPsec，一种为边界网关协议（BGP）[RFC4271]路由公告提供路径安全性的机制。也就是说，接收到有效BGPsec更新消息的BGP说话人具有加密保证，即播发的路由具有以下属性：更新消息中列出的ASE路径上的每个自治系统（AS）已明确授权将路由播发到路径中的后续AS。
This document specifies an optional (non-transitive) BGP path attribute, BGPsec_PATH. It also describes how a BGPsec-compliant BGP speaker (referred to hereafter as a BGPsec speaker) can generate, propagate, and validate BGP UPDATE messages containing this attribute to obtain the above assurances.
本文档指定可选（非传递）BGP路径属性BGPsec_path。它还描述了符合BGPsec的BGP扬声器（以下称为BGPsec扬声器）如何生成、传播和验证包含此属性的BGP更新消息，以获得上述保证。
BGPsec is intended to be used to supplement BGP origin validation [RFC6483] [RFC6811], and when used in conjunction with origin validation, it is possible to prevent a wide variety of route hijacking attacks against BGP.
BGPsec旨在补充BGP来源验证[RFC6483][RFC6811]，当与来源验证一起使用时，可以防止针对BGP的各种路由劫持攻击。
BGPsec relies on the Resource Public Key Infrastructure (RPKI) certificates that attest to the allocation of AS number and IP address resources. (For more information on the RPKI, see RFC 6480 [RFC6480] and the documents referenced therein.) Any BGPsec speaker who wishes to send, to external (eBGP) peers, BGP UPDATE messages containing the BGPsec_PATH needs to possess a private key associated with an RPKI router certificate [RFC8209] that corresponds to the BGPsec speaker's AS number. Note, however, that a BGPsec speaker does not need such a certificate in order to validate received UPDATE messages containing the BGPsec_PATH attribute (see Section 5.2).
BGPsec依赖于资源公钥基础设施（RPKI）证书，该证书证明AS编号和IP地址资源的分配。（有关RPKI的更多信息，请参阅RFC 6480[RFC6480]和其中引用的文档。）任何希望向外部（eBGP）对等方发送包含BGPsec_路径的BGP更新消息的BGPsec演讲者都需要拥有与RPKI路由器证书[RFC8209]相关联的私钥，该证书对应于BGPsec演讲者的AS编号。但是，请注意，BGPsec演讲者不需要此类证书来验证接收到的包含BGPsec_路径属性的更新消息（参见第5.2节）。
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]所述进行解释。
This document defines a BGP capability [RFC5492] that allows a BGP speaker to advertise to a neighbor the ability to send or to receive BGPsec UPDATE messages (i.e., UPDATE messages containing the BGPsec_PATH attribute).
本文档定义了BGP功能[RFC5492]，允许BGP扬声器向邻居通告发送或接收BGPsec更新消息的能力（即，包含BGPsec_路径属性的更新消息）。
This capability has capability code 7.
此功能的功能代码为7。
The capability length for this capability MUST be set to 3.
此功能的功能长度必须设置为3。
The 3 octets of the capability format are specified in Figure 1.
能力格式的3个八位字节如图1所示。
0 1 2 3 4 5 6 7
+---------------------------------------+
| Version | Dir | Unassigned |
+---------------------------------------+
| |
+------ AFI -----+
| |
+---------------------------------------+
0 1 2 3 4 5 6 7
+---------------------------------------+
| Version | Dir | Unassigned |
+---------------------------------------+
| |
+------ AFI -----+
| |
+---------------------------------------+
Figure 1: BGPsec Capability Format
图1:BGPsec能力格式
The first 4 bits of the first octet indicate the version of BGPsec for which the BGP speaker is advertising support. This document defines only BGPsec version 0 (all 4 bits set to 0). Other versions of BGPsec may be defined in future documents. A BGPsec speaker MAY advertise support for multiple versions of BGPsec by including multiple versions of the BGPsec capability in its BGP OPEN message.
第一个八位字节的前4位表示BGP扬声器支持的BGPsec版本。本文档仅定义BGPsec版本0（所有4位均设置为0）。BGPsec的其他版本可能在未来的文件中定义。BGPsec演讲者可以通过在其BGP OPEN消息中包含多个版本的BGPsec功能来宣传对多个版本的BGPsec的支持。
The fifth bit of the first octet is a Direction bit, which indicates whether the BGP speaker is advertising the capability to send BGPsec UPDATE messages or receive BGPsec UPDATE messages. The BGP speaker sets this bit to 0 to indicate the capability to receive BGPsec UPDATE messages. The BGP speaker sets this bit to 1 to indicate the capability to send BGPsec UPDATE messages.
第一个八位字节的第五位是方向位，指示BGP扬声器是在宣传发送BGPsec更新消息还是接收BGPsec更新消息的能力。BGP扬声器将该位设置为0，以指示接收BGPsec更新消息的能力。BGP扬声器将该位设置为1，以指示发送BGPsec更新消息的能力。
The remaining 3 bits of the first octet are unassigned and for future use. These bits are set to 0 by the sender of the capability and ignored by the receiver of the capability.
第一个八位字节的其余3位未分配，供将来使用。这些位由功能的发送方设置为0，由功能的接收方忽略。
The second and third octets contain the 16-bit Address Family Identifier (AFI), which indicates the address family for which the BGPsec speaker is advertising support for BGPsec. This document only specifies BGPsec for use with two address families, IPv4 and IPv6, with AFI values 1 and 2, respectively [IANA-AF]. BGPsec for use with other address families may be specified in future documents.
第二个和第三个八位字节包含16位地址族标识符（AFI），它表示BGPsec扬声器宣传支持BGPsec的地址族。本文档仅指定BGPsec用于IPv4和IPv6两个地址系列，AFI值分别为1和2[IANA-AF]。与其他地址系列一起使用的BGPsec可能会在将来的文档中指定。
In order to indicate that a BGP speaker is willing to send BGPsec UPDATE messages (for a particular address family), a BGP speaker sends the BGPsec capability (see Section 2.1) with the Direction bit (the fifth bit of the first octet) set to 1. In order to indicate that the speaker is willing to receive BGP UPDATE messages containing the BGPsec_PATH attribute (for a particular address family), a BGP speaker sends the BGPsec capability with the Direction bit set to 0. In order to advertise the capability to both send and receive BGPsec UPDATE messages, the BGP speaker sends two copies of the BGPsec capability (one with the Direction bit set to 0 and one with the Direction bit set to 1).
为了表明BGP扬声器愿意发送BGPsec更新消息（针对特定地址系列），BGP扬声器发送BGPsec功能（见第2.1节），方向位（第一个八位组的第五位）设置为1。为了表明说话人愿意接收包含BGPsec_路径属性的BGP更新消息（对于特定地址族），BGP说话人发送方向位设置为0的BGPsec能力。为了公布发送和接收BGPsec更新消息的功能，BGP扬声器发送两份BGPsec功能副本（一份方向位设置为0，另一份方向位设置为1）。
Similarly, if a BGP speaker wishes to use BGPsec with two different address families (i.e., IPv4 and IPv6) over the same BGP session, then the speaker includes two instances of this capability (one for each address family) in the BGP OPEN message. A BGP speaker MUST NOT announce BGPsec capability if it does not support the BGP multiprotocol extension [RFC4760]. Additionally, a BGP speaker MUST NOT advertise the capability of BGPsec support for a particular AFI unless it has also advertised the multiprotocol extension capability for the same AFI [RFC4760].
类似地，如果BGP演讲者希望在同一BGP会话中使用具有两个不同地址族（即IPv4和IPv6）的BGPsec，则演讲者在BGP OPEN消息中包括此功能的两个实例（每个地址族一个）。如果BGP扬声器不支持BGP多协议扩展[RFC4760]，则不得宣布BGPsec功能。此外，BGP演讲者不得宣传特定AFI的BGPsec支持能力，除非其还宣传同一AFI的多协议扩展能力[RFC4760]。
In a BGPsec peering session, a peer is permitted to send UPDATE messages containing the BGPsec_PATH attribute if and only if:
在BGPsec对等会话中，当且仅当满足以下条件时，才允许对等方发送包含BGPsec_路径属性的更新消息：
o The given peer sent the BGPsec capability for a particular version of BGPsec and a particular address family with the Direction bit set to 1, and
o 给定对等方发送特定版本的BGPsec和特定地址系列的BGPsec功能，方向位设置为1，并且
o The other (receiving) peer sent the BGPsec capability for the same version of BGPsec and the same address family with the Direction bit set to 0.
o 另一个（接收）对等方发送相同版本的BGPsec和相同地址系列的BGPsec功能，方向位设置为0。
In such a session, it can be said that the use of the particular version of BGPsec has been negotiated for a particular address family. Traditional BGP UPDATE messages (i.e., unsigned, containing the AS_PATH attribute) MAY be sent within a session regardless of whether or not the use of BGPsec is successfully negotiated. However, if BGPsec is not successfully negotiated, then BGP UPDATE messages containing the BGPsec_PATH attribute MUST NOT be sent.
在这样的会话中，可以说特定版本的BGPsec的使用已经针对特定的地址族进行了协商。无论是否成功协商使用BGPsec，传统的BGP更新消息（即未签名、包含AS_PATH属性）都可以在会话中发送。但是，如果未成功协商BGPsec，则不得发送包含BGPsec_路径属性的BGP更新消息。
This document defines the behavior of implementations in the case where BGPsec version 0 is the only version that has been successfully negotiated. Any future document that specifies additional versions of BGPsec will need to specify behavior in the case that support for multiple versions is negotiated.
本文档定义了BGPsec版本0是唯一成功协商的版本时的实现行为。任何指定BGPsec其他版本的未来文档都需要指定在协商支持多个版本的情况下的行为。
BGPsec cannot provide meaningful security guarantees without support for 4-byte AS numbers. Therefore, any BGP speaker that announces the BGPsec capability, MUST also announce the capability for 4-byte AS support [RFC6793]. If a BGP speaker sends the BGPsec capability but not the 4-byte AS support capability, then BGPsec has not been successfully negotiated, and UPDATE messages containing the BGPsec_PATH attribute MUST NOT be sent within such a session.
如果不支持4字节AS数字，BGPsec无法提供有意义的安全保证。因此，任何宣布BGPsec功能的BGP扬声器也必须宣布支持4字节的功能[RFC6793]。如果BGP扬声器发送的是BGPsec功能，而不是4字节AS支持功能，则BGPsec尚未成功协商，且包含BGPsec_PATH属性的更新消息不得在此类会话中发送。
The BGPsec_PATH attribute is an optional non-transitive BGP path attribute.
BGPsec_路径属性是可选的非传递性BGP路径属性。
This document registers an attribute type code for this attribute: BGPsec_PATH (see Section 9).
本文档为该属性注册了一个属性类型代码：BGPsec_PATH（见第9节）。
The BGPsec_PATH attribute carries the secured information regarding the path of ASes through which an UPDATE message passes. This includes the digital signatures used to protect the path information. The UPDATE messages that contain the BGPsec_PATH attribute are referred to as "BGPsec UPDATE messages". The BGPsec_PATH attribute replaces the AS_PATH attribute in a BGPsec UPDATE message. That is, UPDATE messages that contain the BGPsec_PATH attribute MUST NOT contain the AS_PATH attribute, and vice versa.
BGPsec_PATH属性包含有关更新消息通过的ASE路径的安全信息。这包括用于保护路径信息的数字签名。包含BGPsec_PATH属性的更新消息称为“BGPsec更新消息”。BGPsec_路径属性替换BGPsec更新消息中的AS_路径属性。也就是说，包含BGPsec_PATH属性的更新消息不能包含AS_PATH属性，反之亦然。
The BGPsec_PATH attribute is made up of several parts. The high-level diagram in Figure 2 provides an overview of the structure of the BGPsec_PATH attribute. ("SKI" as used in Figure 2 means "Subject Key Identifier".)
BGPsec_路径属性由几个部分组成。图2中的高级关系图概述了BGPsec_PATH属性的结构。（“图2中使用的SKI”表示“主题密钥标识符”。）
+---------------------------------------------------------+
| +-----------------+ |
| | Secure_Path | |
| +-----------------+ |
| | pCount X | |
| | Flags X | |
| | AS X | |
| | pCount Y | |
| | Flags Y | |
| | AS Y | |
| | ... | |
| +-----------------+ |
| |
| +---------------------+ +---------------------+ |
| | Signature_Block 1 | | Signature_Block 2 | |
| +---------------------+ +---------------------+ |
| | Algorithm Suite 1 | | Algorithm Suite 2 | |
| | SKI X1 | | SKI X2 | |
| | Signature X1 | | Signature X2 | |
| | SKI Y1 | | SKI Y2 | |
| | Signature Y1 | | Signature Y2 | |
| | ... | | .... | |
| +---------------------+ +---------------------+ |
| |
+---------------------------------------------------------+
+---------------------------------------------------------+
| +-----------------+ |
| | Secure_Path | |
| +-----------------+ |
| | pCount X | |
| | Flags X | |
| | AS X | |
| | pCount Y | |
| | Flags Y | |
| | AS Y | |
| | ... | |
| +-----------------+ |
| |
| +---------------------+ +---------------------+ |
| | Signature_Block 1 | | Signature_Block 2 | |
| +---------------------+ +---------------------+ |
| | Algorithm Suite 1 | | Algorithm Suite 2 | |
| | SKI X1 | | SKI X2 | |
| | Signature X1 | | Signature X2 | |
| | SKI Y1 | | SKI Y2 | |
| | Signature Y1 | | Signature Y2 | |
| | ... | | .... | |
| +---------------------+ +---------------------+ |
| |
+---------------------------------------------------------+
Figure 2: High-Level Diagram of the BGPsec_PATH Attribute
图2:BGPsec_路径属性的高级图
Figure 3 provides the specification of the format for the BGPsec_PATH attribute.
图3提供了BGPsec_路径属性的格式规范。
+-------------------------------------------------------+
| Secure_Path (variable) |
+-------------------------------------------------------+
| Sequence of one or two Signature_Blocks (variable) |
+-------------------------------------------------------+
+-------------------------------------------------------+
| Secure_Path (variable) |
+-------------------------------------------------------+
| Sequence of one or two Signature_Blocks (variable) |
+-------------------------------------------------------+
Figure 3: BGPsec_PATH Attribute Format
图3:BGPsec_路径属性格式
The Secure_Path contains AS path information for the BGPsec UPDATE message. This is logically equivalent to the information that is contained in a non-BGPsec AS_PATH attribute. The information in the Secure_Path is used by BGPsec speakers in the same way that information from the AS_PATH is used by non-BGPsec speakers. The format of the Secure_Path is described below in Section 3.1.
安全路径包含BGPsec更新消息的路径信息。这在逻辑上等同于非BGPsec AS_路径属性中包含的信息。BGPsec扬声器使用安全_路径中的信息的方式与非BGPsec扬声器使用AS_路径中的信息的方式相同。第3.1节描述了安全路径的格式。
The BGPsec_PATH attribute will contain one or two Signature_Blocks, each of which corresponds to a different algorithm suite. Each of
BGPsec_PATH属性将包含一个或两个签名_块，每个签名_块对应于不同的算法套件。每个
the Signature_Blocks will contain a Signature Segment for each AS number (i.e., Secure_Path Segment) in the Secure_Path. In the most common case, the BGPsec_PATH attribute will contain only a single Signature_Block. However, in order to enable a transition from an old algorithm suite to a new algorithm suite (without a flag day), it will be necessary to include two Signature_Blocks (one for the old algorithm suite and one for the new algorithm suite) during the transition period. (See Section 6.1 for more discussion of algorithm transitions.) The format of the Signature_Blocks is described below in Section 3.2.
签名块将包含安全路径中每个AS编号（即安全路径段）的签名段。在最常见的情况下，BGPsec_PATH属性将只包含一个签名_块。但是，为了实现从旧算法套件到新算法套件的转换（无国旗日），必须在转换期间包括两个签名_块（一个用于旧算法套件，一个用于新算法套件）。（有关算法转换的更多讨论，请参见第6.1节。）签名块的格式在下文第3.2节中描述。
A detailed description of the Secure_Path information in the BGPsec_PATH attribute is provided here. The specification for the Secure_Path field is provided in Figures 4 and 5.
此处提供了BGPsec_路径属性中安全_路径信息的详细说明。图4和图5提供了安全路径字段的规范。
+-----------------------------------------------+
| Secure_Path Length (2 octets) |
+-----------------------------------------------+
| One or more Secure_Path Segments (variable) |
+-----------------------------------------------+
+-----------------------------------------------+
| Secure_Path Length (2 octets) |
+-----------------------------------------------+
| One or more Secure_Path Segments (variable) |
+-----------------------------------------------+
Figure 4: Secure_Path Format
图4：安全路径格式
The Secure_Path Length contains the length (in octets) of the entire Secure_Path (including the 2 octets used to express this length field). As explained below, each Secure_Path Segment is 6 octets long. Note that this means the Secure_Path Length is two greater than six times the number of Secure_Path Segments (i.e., the number of AS numbers in the path).
Secure_Path Length包含整个Secure_路径的长度（以八位字节为单位）（包括用于表示此长度字段的两个八位字节）。如下所述，每个安全路径段的长度为6个八位字节。注意，这意味着Secure_路径长度是Secure_路径段数（即路径中AS数）的两倍大于六倍。
The Secure_Path contains one Secure_Path Segment (see Figure 5) for each AS in the path to the originating AS of the prefix specified in the UPDATE message. (Note: Repeated ASes are "compressed out" using the pCount field, as discussed below.)
Secure_Path包含一个Secure_Path段（见图5），用于更新消息中指定前缀的起始AS路径中的每个AS。（注：重复的ASE使用pCount字段“压缩”，如下所述。）
+------------------------------------------------------+
| pCount (1 octet) |
+------------------------------------------------------+
| Confed_Segment flag (1 bit) | Unassigned (7 bits) | (Flags)
+------------------------------------------------------+
| AS Number (4 octets) |
+------------------------------------------------------+
+------------------------------------------------------+
| pCount (1 octet) |
+------------------------------------------------------+
| Confed_Segment flag (1 bit) | Unassigned (7 bits) | (Flags)
+------------------------------------------------------+
| AS Number (4 octets) |
+------------------------------------------------------+
Figure 5: Secure_Path Segment Format
图5：安全路径段格式
The AS Number (in Figure 5) is the AS number of the BGP speaker that added this Secure_Path Segment to the BGPsec_PATH attribute. (See Section 4 for more information on populating this field.)
AS编号（图5中）是将此安全路径段添加到BGPsec_路径属性的BGP扬声器的AS编号。（有关填充此字段的更多信息，请参见第4节。）
The pCount field contains the number of repetitions of the associated AS number that the signature covers. This field enables a BGPsec speaker to mimic the semantics of prepending multiple copies of their AS to the AS_PATH without requiring the speaker to generate multiple signatures. Note that Section 9.1.2.2 ("Breaking Ties (Phase 2)") in [RFC4271] mentions the "number of AS numbers" in the AS_PATH attribute that is used in the route selection process. This metric (number of AS numbers) is the same as the AS path length obtained in BGPsec by summing the pCount values in the BGPsec_PATH attribute. The pCount field is also useful in managing route servers (see Section 4.2), AS confederations (see Section 4.3), and AS Number migrations (see [RFC8206] for details).
pCount字段包含签名覆盖的关联AS编号的重复次数。此字段使BGPsec演讲者能够模拟将其AS的多个副本预先发送到AS_路径的语义，而无需演讲者生成多个签名。请注意，[RFC4271]中的第9.1.2.2节（“断开连接（第2阶段）”）提到了路由选择过程中使用的AS_路径属性中的“AS编号”。此度量（AS编号的数量）与通过对BGPsec_path属性中的pCount值求和而在BGPsec中获得的AS路径长度相同。pCount字段在管理路由服务器（请参见第4.2节）、联盟（请参见第4.3节）和号码迁移（请参见[RFC8206]了解详细信息）时也很有用。
The leftmost (i.e., the most significant) bit of the Flags field in Figure 5 is the Confed_Segment flag. The Confed_Segment flag is set to 1 to indicate that the BGPsec speaker that constructed this Secure_Path Segment is sending the UPDATE message to a peer AS within the same AS confederation [RFC5065]. (That is, a sequence of consecutive Confed_Segment flags are set in a BGPsec UPDATE message whenever, in a non-BGPsec UPDATE message, an AS_PATH segment of type AS_CONFED_SEQUENCE occurs.) In all other cases, the Confed_Segment flag is set to 0.
图5中Flags字段的最左边（即最重要）位是Confed_段标志。Confed_段标志设置为1，表示构建此安全_路径段的BGPsec扬声器正在向与联合会相同的对等方发送更新消息[RFC5065]。（即，只要在非BGPsec更新消息中出现AS_Confed_序列类型的AS_路径段，BGPsec更新消息中就会设置一系列连续的Confed_段标志。）在所有其他情况下，Confed_段标志设置为0。
The remaining 7 bits of the Flags field are unassigned. They MUST be set to 0 by the sender and ignored by the receiver. Note, however, that the signature is computed over all 8 bits of the Flags field.
标志字段的其余7位未分配。发送方必须将它们设置为0，接收方必须忽略它们。但是，请注意，签名是在Flags字段的所有8位上计算的。
As stated earlier in Section 2.2, BGPsec peering requires that the peering ASes MUST each support 4-byte AS numbers. Currently assigned 2-byte AS numbers are converted into 4-byte AS numbers by setting the two high-order octets of the 4-octet field to 0 [RFC6793].
如前面第2.2节所述，BGPsec对等要求对等ASE必须支持4字节的As数字。通过将4-八位字节字段的两个高阶八位字节设置为0[RFC6793]，将当前分配的2字节AS编号转换为4字节AS编号。
A detailed description of the Signature_Blocks in the BGPsec_PATH attribute is provided here using Figures 6 and 7.
这里使用图6和图7提供了BGPsec_路径属性中签名_块的详细描述。
+---------------------------------------------+
| Signature_Block Length (2 octets) |
+---------------------------------------------+
| Algorithm Suite Identifier (1 octet) |
+---------------------------------------------+
| Sequence of Signature Segments (variable) |
+---------------------------------------------+
+---------------------------------------------+
| Signature_Block Length (2 octets) |
+---------------------------------------------+
| Algorithm Suite Identifier (1 octet) |
+---------------------------------------------+
| Sequence of Signature Segments (variable) |
+---------------------------------------------+
Figure 6: Signature_Block Format
图6：签名块格式
The Signature_Block Length in Figure 6 is the total number of octets in the Signature_Block (including the 2 octets used to express this length field).
图6中的Signature_块长度是Signature_块中的八位字节总数（包括用于表示此长度字段的两个八位字节）。
The Algorithm Suite Identifier is a 1-octet identifier specifying the digest algorithm and digital signature algorithm used to produce the digital signature in each Signature Segment. An IANA registry of algorithm suite identifiers for use in BGPsec is specified in the BGPsec algorithms document [RFC8208].
算法套件标识符是一个1-octet标识符，指定用于在每个签名段中生成数字签名的摘要算法和数字签名算法。BGPsec算法文档[RFC8208]中指定了用于BGPsec的算法套件标识符的IANA注册表。
A Signature_Block in Figure 6 has exactly one Signature Segment (see Figure 7) for each Secure_Path Segment in the Secure_Path portion of the BGPsec_PATH attribute (that is, one Signature Segment for each distinct AS on the path for the prefix in the UPDATE message).
图6中的签名块对于BGPsec_Path属性的Secure_Path部分中的每个Secure_Path段（即，对于更新消息中前缀路径上的每个distinct AS，一个签名段）正好有一个签名段（参见图7）。
+---------------------------------------------+
| Subject Key Identifier (SKI) (20 octets) |
+---------------------------------------------+
| Signature Length (2 octets) |
+---------------------------------------------+
| Signature (variable) |
+---------------------------------------------+
+---------------------------------------------+
| Subject Key Identifier (SKI) (20 octets) |
+---------------------------------------------+
| Signature Length (2 octets) |
+---------------------------------------------+
| Signature (variable) |
+---------------------------------------------+
Figure 7: Signature Segment Format
图7：签名段格式
The Subject Key Identifier (SKI) field in Figure 7 contains the value in the Subject Key Identifier extension of the RPKI router certificate [RFC6487] that is used to verify the signature (see Section 5 for details on the validity of BGPsec UPDATE messages). The SKI field has a fixed size of 20 octets. See Section 6.2 for considerations for the SKI size.
图7中的Subject Key Identifier（SKI）字段包含用于验证签名的RPKI路由器证书[RFC6487]的Subject Key Identifier扩展中的值（有关BGPsec更新消息的有效性的详细信息，请参阅第5节）。滑雪场有固定大小的20个八位组。有关滑雪板尺寸的注意事项，请参见第6.2节。
The Signature Length field contains the size (in octets) of the value in the Signature field of the Signature Segment.
签名长度字段包含签名段的签名字段中值的大小（以八位字节为单位）。
The Signature field in Figure 7 contains a digital signature that protects the prefix and the BGPsec_PATH attribute (see Sections 4 and 5 for details on signature generation and validation, respectively).
图7中的签名字段包含一个保护前缀和BGPsec_PATH属性的数字签名（有关签名生成和验证的详细信息，请分别参见第4节和第5节）。
Section 4.1 provides general guidance on the creation of BGPsec UPDATE messages -- that is, UPDATE messages containing the BGPsec_PATH attribute.
第4.1节提供了创建BGPsec更新消息的一般指导，即包含BGPsec_路径属性的更新消息。
Section 4.2 specifies how a BGPsec speaker generates the BGPsec_PATH attribute to include in a BGPsec UPDATE message.
第4.2节规定了BGPsec扬声器如何生成要包含在BGPsec更新消息中的BGPsec_路径属性。
Section 4.3 contains special processing instructions for members of an AS confederation [RFC5065]. A BGPsec speaker that is not a member of such a confederation MUST NOT set the Confed_Segment flag in its Secure_Path Segment (i.e., leave the Confed_Segment flag at the default value of 0) in all BGPsec UPDATE messages it sends.
第4.3节包含AS联盟成员的特殊处理说明[RFC5065]。非联盟成员的BGPsec扬声器不得在其发送的所有BGPsec更新消息中在其安全路径段中设置Confed_段标志（即，将Confed_段标志保留为默认值0）。
Section 4.4 contains instructions for reconstructing the AS_PATH attribute in cases where a BGPsec speaker receives an UPDATE message with a BGPsec_PATH attribute and wishes to propagate the UPDATE message to a peer who does not support BGPsec.
第4.4节包含在BGPsec说话人收到带有BGPsec_路径属性的更新消息并希望将更新消息传播给不支持BGPsec的对等方的情况下重建AS_路径属性的说明。
The information protected by the signature on a BGPsec UPDATE message includes the AS number of the peer to whom the UPDATE message is being sent. Therefore, if a BGPsec speaker wishes to send a BGPsec UPDATE message to multiple BGP peers, it MUST generate a separate BGPsec UPDATE message for each unique peer AS to whom the UPDATE message is sent.
BGPsec更新消息上的签名保护的信息包括更新消息发送到的对等方的AS编号。因此，如果BGPsec演讲者希望向多个BGP对等方发送BGPsec更新消息，则必须为向其发送更新消息的每个唯一对等方生成单独的BGPsec更新消息。
A BGPsec UPDATE message MUST advertise a route to only a single prefix. This is because a BGPsec speaker receiving an UPDATE message with multiple prefixes would be unable to construct a valid BGPsec UPDATE message (i.e., valid path signatures) containing a subset of the prefixes in the received update. If a BGPsec speaker wishes to advertise routes to multiple prefixes, then it MUST generate a separate BGPsec UPDATE message for each prefix. Additionally, a BGPsec UPDATE message MUST use the MP_REACH_NLRI attribute [RFC4760] to encode the prefix.
BGPsec更新消息必须仅向单个前缀播发路由。这是因为收到带有多个前缀的更新消息的BGPsec说话人将无法构造包含所接收更新中前缀子集的有效BGPsec更新消息（即有效路径签名）。如果BGPsec演讲者希望向多个前缀播发路由，则必须为每个前缀生成单独的BGPsec更新消息。此外，BGPsec更新消息必须使用MP_REACH_NLRI属性[RFC4760]对前缀进行编码。
The BGPsec_PATH attribute and the AS_PATH attribute are mutually exclusive. That is, any UPDATE message containing the BGPsec_PATH attribute MUST NOT contain the AS_PATH attribute. The information that would be contained in the AS_PATH attribute is instead conveyed in the Secure_Path portion of the BGPsec_PATH attribute.
BGPsec_路径属性和AS_路径属性是互斥的。也就是说，任何包含BGPsec_路径属性的更新消息都不能包含AS_路径属性。将包含在AS_PATH属性中的信息将在BGPsec_PATH属性的Secure_PATH部分中传递。
In order to create or add a new signature to a BGPsec UPDATE message with a given algorithm suite, the BGPsec speaker MUST possess a private key suitable for generating signatures for this algorithm suite. Additionally, this private key must correspond to the public key in a valid RPKI end entity certificate whose AS number resource extension includes the BGPsec speaker's AS number [RFC8209]. Note also that new signatures are only added to a BGPsec UPDATE message when a BGPsec speaker is generating an UPDATE message to send to an external peer (i.e., when the AS number of the peer is not equal to the BGPsec speaker's own AS number).
为了使用给定的算法套件为BGPsec更新消息创建或添加新签名，BGPsec演讲者必须拥有适用于生成该算法套件签名的私钥。此外，该私钥必须与有效RPKI终端实体证书中的公钥相对应，该证书的AS编号资源扩展包括BGPsec演讲者的AS编号[RFC8209]。还要注意，只有当BGPsec演讲者生成更新消息以发送给外部对等方时（即，对等方的AS编号不等于BGPsec演讲者自己的AS编号），新签名才会添加到BGPsec更新消息中。
The RPKI enables the legitimate holder of IP address prefix(es) to issue a signed object, called a Route Origin Authorization (ROA), that authorizes a given AS to originate routes to a given set of prefixes (see RFC 6482 [RFC6482]). It is expected that most Relying Parties (RPs) will utilize BGPsec in tandem with origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]). Therefore, it is RECOMMENDED that a BGPsec speaker only originate a BGPsec UPDATE message advertising a route for a given prefix if there exists a valid ROA authorizing the BGPsec speaker's AS to originate routes to this prefix.
RPKI使IP地址前缀的合法持有者能够发出一个被称为路由起源授权（ROA）的签名对象，该对象授权一个给定的AS向一组给定的前缀发起路由（参见RFC 6482[RFC6482]）。预计大多数依赖方（RP）将在原产地验证的同时使用BGPsec（见RFC 6483[RFC6483]和RFC 6811[RFC6811]）。因此，如果存在有效的ROA授权BGPsec演讲者的AS发起到该前缀的路由，则建议BGPsec演讲者仅发起一条BGPsec更新消息，该消息宣传给定前缀的路由。
If a BGPsec router has received only a non-BGPsec UPDATE message containing the AS_PATH attribute (instead of the BGPsec_PATH attribute) from a peer for a given prefix, then it MUST NOT attach a BGPsec_PATH attribute when it propagates the UPDATE message. (Note that a BGPsec router may also receive a non-BGPsec UPDATE message from an internal peer without the AS_PATH attribute, i.e., with just the Network Layer Reachability Information (NLRI) in it. In that case, the prefix is originating from that AS, and if it is selected for advertisement, the BGPsec speaker SHOULD attach a BGPsec_PATH attribute and send a signed route (for that prefix) to its external BGPsec-speaking peers.)
如果BGPsec路由器仅从对等方接收到包含给定前缀的AS_路径属性（而不是BGPsec_路径属性）的非BGPsec更新消息，则它在传播更新消息时不得附加BGPsec_路径属性。（注意，BGPsec路由器也可以从内部对等方接收非BGPsec更新消息，而不具有AS_路径属性，即仅具有网络层可达性信息（NLRI）在这种情况下，前缀源自该AS，如果选择该前缀进行播发，则BGPsec说话人应附加BGPsec_路径属性，并向其外部讲BGPsec的对等方发送签名路由（针对该前缀）
Conversely, if a BGPsec router has received a BGPsec UPDATE message (with the BGPsec_PATH attribute) from a peer for a given prefix and it chooses to propagate that peer's route for the prefix, then it SHOULD propagate the route as a BGPsec UPDATE message containing the BGPsec_PATH attribute.
相反，如果BGPsec路由器已从对等方接收到针对给定前缀的BGPsec更新消息（具有BGPsec_路径属性），并选择传播该对等方针对该前缀的路由，则它应将该路由传播为包含BGPsec_路径属性的BGPsec更新消息。
Note that removing BGPsec signatures (i.e., propagating a route advertisement without the BGPsec_PATH attribute) has significant security ramifications. (See Section 8 for a discussion of the security ramifications of removing BGPsec signatures.) Therefore, when a route advertisement is received via a BGPsec UPDATE message, propagating the route advertisement without the BGPsec_PATH attribute is NOT RECOMMENDED, unless the message is sent to a peer that did not advertise the capability to receive BGPsec UPDATE messages (see Section 4.4).
请注意，删除BGPsec签名（即，在不使用BGPsec_路径属性的情况下传播路由公告）会产生重大的安全后果。（有关删除BGPsec签名的安全后果的讨论，请参见第8节。）因此，当通过BGPsec更新消息接收到路由公告时，不建议传播不带BGPsec_路径属性的路由公告，除非将消息发送给没有公布接收BGPsec更新消息能力的对等方（见第4.4节）。
Furthermore, note that when a BGPsec speaker propagates a route advertisement with the BGPsec_PATH attribute, it is not attesting to the validation state of the UPDATE message it received. (See Section 8 for more discussion of the security semantics of BGPsec signatures.)
此外，请注意，当BGPsec演讲者传播具有BGPsec_PATH属性的路由广告时，它不证明其接收的更新消息的验证状态。（有关BGPsec签名的安全语义的更多讨论，请参见第8节。）
If the BGPsec speaker is producing an UPDATE message that would, in the absence of BGPsec, contain an AS_SET (e.g., the BGPsec speaker is performing proxy aggregation), then the BGPsec speaker MUST NOT include the BGPsec_PATH attribute. In such a case, the BGPsec speaker MUST remove any existing BGPsec_PATH in the received advertisement(s) for this prefix and produce a traditional (non-BGPsec) UPDATE message. It should be noted that BCP 172 [RFC6472] recommends against the use of AS_SET and AS_CONFED_SET in the AS_PATH of BGP UPDATE messages.
如果BGPsec演讲者正在生成更新消息，在没有BGPsec的情况下，该消息将包含AS_集（例如，BGPsec演讲者正在执行代理聚合），则BGPsec演讲者不得包含BGPsec_路径属性。在这种情况下，BGPsec扬声器必须删除接收到的广告中该前缀的任何现有BGPsec_路径，并生成传统（非BGPsec）更新消息。应该注意的是，BCP 172[RFC6472]建议不要在BGP更新消息的AS_路径中使用AS_集和AS_CONFED_集。
The case where the BGPsec speaker sends a BGPsec UPDATE message to an iBGP (internal BGP) peer is quite simple. When originating a new route advertisement and sending it to a BGPsec-capable iBGP peer, the BGPsec speaker omits the BGPsec_PATH attribute. When originating a new route advertisement and sending it to a non-BGPsec iBGP peer, the BGPsec speaker includes an empty AS_PATH attribute in the UPDATE message. (An empty AS_PATH attribute is one whose length field contains the value 0 [RFC4271].) When a BGPsec speaker chooses to forward a BGPsec UPDATE message to an iBGP peer, the BGPsec_PATH attribute SHOULD NOT be removed, unless the peer doesn't support BGPsec. In the case when an iBGP peer doesn't support BGPsec, then a BGP UPDATE message with AS_PATH is reconstructed from the BGPsec UPDATE message and then forwarded (see Section 4.4). In particular, when forwarding to a BGPsec-capable iBGP (or eBGP) peer, the BGPsec_PATH attribute SHOULD NOT be removed even in the case where the BGPsec UPDATE message has not been successfully validated. (See Section 5 for more information on validation and Section 8 for the security ramifications of removing BGPsec signatures.)
BGPsec扬声器向iBGP（内部BGP）对等方发送BGPsec更新消息的情况非常简单。当发起新的路由公告并将其发送给支持BGPsec的iBGP对等方时，BGPsec扬声器会忽略BGPsec_路径属性。当发起新路由公告并将其发送给非BGPsec iBGP对等方时，BGPsec扬声器在更新消息中包含一个空AS_路径属性。（空的AS_路径属性是长度字段包含值0的属性[RFC4271]）当BGPsec说话者选择将BGPsec更新消息转发给iBGP对等方时，不应删除BGPsec_路径属性，除非对等方不支持BGPsec。如果iBGP对等方不支持BGPsec，则从BGPsec更新消息中重建具有AS_路径的BGP更新消息，然后转发（参见第4.4节）。特别是，当转发到支持BGPsec的iBGP（或eBGP）对等方时，即使未成功验证BGPsec更新消息，也不应删除BGPsec_路径属性。（有关验证的更多信息，请参见第5节；删除BGPsec签名的安全后果，请参见第8节。）
All BGPsec UPDATE messages MUST conform to BGP's maximum message size. If the resulting message exceeds the maximum message size, then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be followed.
所有BGPsec更新消息必须符合BGP的最大消息大小。如果生成的消息超过最大消息大小，则必须遵循RFC 4271[RFC4271]第9.2节中的指南。
When a BGPsec speaker receives a BGPsec UPDATE message containing a BGPsec_PATH attribute (with one or more signatures) from an (internal or external) peer, it may choose to propagate the route advertisement by sending it to its other (internal or external) peers. When sending the route advertisement to an internal BGPsec-speaking peer, the BGPsec_PATH attribute SHALL NOT be modified. When sending the route advertisement to an external BGPsec-speaking peer, the following procedures are used to form or update the BGPsec_PATH attribute.
当BGPsec演讲者从（内部或外部）对等方接收到包含BGPsec_路径属性（具有一个或多个签名）的BGPsec更新消息时，它可以选择通过将其发送到其他（内部或外部）对等方来传播路由公告。向内部BGPsec语音对等方发送路由公告时，不应修改BGPsec_路径属性。将路由播发发送到讲BGPsec的外部对等方时，使用以下过程形成或更新BGPsec_路径属性。
To generate the BGPsec_PATH attribute on the outgoing UPDATE message, the BGPsec speaker first generates a new Secure_Path Segment. Note that if the BGPsec speaker is not the origin AS and there is an existing BGPsec_PATH attribute, then the BGPsec speaker prepends its new Secure_Path Segment (places in first position) onto the existing Secure_Path.
要在传出更新消息上生成BGPsec_路径属性，BGPsec扬声器首先生成一个新的安全_路径段。请注意，如果BGPsec扬声器不是源AS，并且存在现有BGPsec_路径属性，则BGPsec扬声器会将其新的安全_路径段（放置在第一个位置）预先添加到现有的安全_路径上。
The AS number in this Secure_Path Segment MUST match the AS number in the Subject field of the RPKI router certificate that will be used to verify the digital signature constructed by this BGPsec speaker (see Section 3.1.1 in [RFC8209] and RFC 6487 [RFC6487]).
此安全路径段中的AS编号必须与RPKI路由器证书主题字段中的AS编号匹配，该证书将用于验证此BGPsec扬声器构造的数字签名（请参见[RFC8209]和RFC 6487[RFC6487]中的第3.1.1节）。
The pCount field of the Secure_Path Segment is typically set to the value 1. However, a BGPsec speaker may set the pCount field to a value greater than 1. Setting the pCount field to a value greater than 1 has the same semantics as repeating an AS number multiple times in the AS_PATH of a non-BGPsec UPDATE message (e.g., for traffic engineering purposes).
安全路径段的pCount字段通常设置为值1。然而，BGPsec扬声器可将pCount字段设置为大于1的值。将pCount字段设置为大于1的值具有与在非BGPsec更新消息的as_路径中多次重复as编号相同的语义（例如，出于流量工程目的）。
To prevent unnecessary processing load in the validation of BGPsec signatures, a BGPsec speaker SHOULD NOT produce multiple consecutive Secure_Path Segments with the same AS number. This means that to achieve the semantics of prepending the same AS number k times, a BGPsec speaker SHOULD produce a single Secure_Path Segment -- with a pCount of k -- and a single corresponding Signature Segment.
为防止在验证BGPsec签名时产生不必要的处理负载，BGPsec扬声器不应产生多个连续的与数字相同的安全路径段。这意味着，为了实现与数字k倍相同的前置语义，BGPsec说话人应该生成一个安全路径段（pCount为k）和一个对应的签名段。
A route server that participates in the BGP control plane but does not act as a transit AS in the data plane may choose to set pCount to 0. This option enables the route server to participate in BGPsec and obtain the associated security guarantees without increasing the length of the AS path. (Note that BGPsec speakers
参与BGP控制平面但不作为数据平面中的传输的路由服务器可以选择将pCount设置为0。此选项使路由服务器能够参与BGPsec并获得相关的安全保证，而无需增加AS路径的长度。（请注意，BGPsec发言人
compute the length of the AS path by summing the pCount values in the BGPsec_PATH attribute; see Section 5.) However, when a route server sets the pCount value to 0, it still inserts its AS number into the Secure_Path Segment, as this information is needed to validate the signature added by the route server. See [RFC8206] for a discussion of setting pCount to 0 to facilitate AS Number migration. Also, see Section 4.3 for the use of pCount=0 in the context of an AS confederation. See Section 7.2 for operational guidance for configuring a BGPsec router for setting pCount=0 and/or accepting pCount=0 from a peer.
通过将BGPsec_路径属性中的pCount值相加，计算AS路径的长度；但是，当路由服务器将pCount值设置为0时，它仍然会将其AS编号插入到安全路径段中，因为需要此信息来验证路由服务器添加的签名。有关将pCount设置为0以便于AS编号迁移的讨论，请参阅[RFC8206]。此外，参见第4.3节，了解在AS联盟中使用pCount=0的情况。有关配置BGPsec路由器以设置pCount=0和/或从对等方接受pCount=0的操作指南，请参阅第7.2节。
Next, the BGPsec speaker generates one or two Signature_Blocks. Typically, a BGPsec speaker will use only a single algorithm suite and thus create only a single Signature_Block in the BGPsec_PATH attribute. However, to ensure backwards compatibility during a period of transition from a 'current' algorithm suite to a 'new' algorithm suite, it will be necessary to originate UPDATE messages that contain a Signature_Block for both the 'current' and the 'new' algorithm suites (see Section 6.1).
接下来，BGPsec扬声器生成一个或两个签名块。通常，BGPsec扬声器将仅使用单个算法套件，因此在BGPsec_路径属性中仅创建单个签名_块。然而，为了确保在从“当前”算法套件过渡到“新”算法套件期间的向后兼容性，有必要发起包含“当前”和“新”算法套件的签名块的更新消息（见第6.1节）。
If the received BGPsec UPDATE message contains two Signature_Blocks and the BGPsec speaker supports both of the corresponding algorithm suites, then the new UPDATE message generated by the BGPsec speaker MUST include both of the Signature_Blocks. If the received BGPsec UPDATE message contains two Signature_Blocks and the BGPsec speaker only supports one of the two corresponding algorithm suites, then the BGPsec speaker MUST remove the Signature_Block corresponding to the algorithm suite that it does not understand. If the BGPsec speaker does not support the algorithm suites in any of the Signature_Blocks contained in the received UPDATE message, then the BGPsec speaker MUST NOT propagate the route advertisement with the BGPsec_PATH attribute. (That is, if it chooses to propagate this route advertisement at all, it MUST do so as an unsigned BGP UPDATE message. See Section 4.4 for more information on converting to an unsigned BGP UPDATE message.)
如果收到的BGPsec更新消息包含两个签名_块，且BGPsec扬声器支持两个相应的算法套件，则BGPsec扬声器生成的新更新消息必须包含两个签名_块。如果收到的BGPsec更新消息包含两个签名块，且BGPsec扬声器仅支持两个相应算法套件中的一个，则BGPsec扬声器必须删除其不理解的算法套件对应的签名块。如果BGPsec演讲者不支持接收到的更新消息中包含的任何签名_块中的算法套件，则BGPsec演讲者不得使用BGPsec_路径属性传播路由播发。（也就是说，如果它选择传播此路由播发，则必须以未签名BGP更新消息的形式传播。有关转换为未签名BGP更新消息的更多信息，请参阅第4.4节。）
Note that in the case where the BGPsec_PATH has two Signature_Blocks (corresponding to different algorithm suites), the validation algorithm (see Section 5.2) deems a BGPsec UPDATE message to be 'Valid' if there is at least one supported algorithm suite (and corresponding Signature_Block) that is deemed 'Valid'. This means that a 'Valid' BGPsec UPDATE message may contain a Signature_Block that is not deemed 'Valid' (e.g., contains signatures that BGPsec does not successfully verify). Nonetheless, such Signature_Blocks MUST NOT be removed. (See Section 8 for a discussion of the security ramifications of this design choice.)
请注意，在BGPsec_路径有两个签名_块（对应于不同的算法套件）的情况下，如果至少有一个受支持的算法套件（和相应的签名_块）被视为“有效”，则验证算法（见第5.2节）将BGPsec更新消息视为“有效”。这意味着“有效”BGPsec更新消息可能包含被视为“无效”的签名块（例如，包含BGPsec未成功验证的签名）。尽管如此，不得移除此类签名块。（有关此设计选择的安全影响的讨论，请参见第8节。）
For each Signature_Block corresponding to an algorithm suite that the BGPsec speaker does support, the BGPsec speaker MUST add a new Signature Segment to the Signature_Block. This Signature Segment is prepended to the list of Signature Segments (placed in the first position) so that the list of Signature Segments appears in the same order as the corresponding Secure_Path Segments. The BGPsec speaker populates the fields of this new Signature Segment as follows.
对于与BGPsec演讲者支持的算法套件相对应的每个签名_块，BGPsec演讲者必须向签名_块添加新的签名段。此签名段在签名段列表（放置在第一个位置）之前，因此签名段列表的显示顺序与相应的安全路径段相同。BGPsec演讲者按如下方式填充此新签名段的字段。
The Subject Key Identifier field in the new segment is populated with the identifier contained in the Subject Key Identifier extension of the RPKI router certificate corresponding to the BGPsec speaker [RFC8209]. This Subject Key Identifier will be used by recipients of the route advertisement to identify the proper certificate to use in verifying the signature.
新段中的主题密钥标识符字段填充有对应于BGPsec演讲者的RPKI路由器证书的主题密钥标识符扩展中包含的标识符[RFC8209]。路由公告的接收者将使用此主题密钥标识符来标识用于验证签名的适当证书。
The Signature field in the new segment contains a digital signature that binds the prefix and BGPsec_PATH attribute to the RPKI router certificate corresponding to the BGPsec speaker. The digital signature is computed as follows:
新段中的签名字段包含一个数字签名，该数字签名将前缀和BGPsec_路径属性绑定到对应于BGPsec说话人的RPKI路由器证书。数字签名的计算如下：
o For clarity, let us number the Secure_Path and corresponding Signature Segments from 1 to N, as follows. Let Secure_Path Segment 1 and Signature Segment 1 be the segments produced by the origin AS. Let Secure_Path Segment 2 and Signature Segment 2 be the segments added by the next AS after the origin. Continue this method of numbering, and ultimately let Secure_Path Segment N and Signature Segment N be those that are being added by the current AS. The current AS (Nth AS) is signing and forwarding the UPDATE message to the next AS (i.e., the (N+1)th AS) in the chain of ASes that form the AS path.
o 为了清楚起见，让我们将Secure_路径和相应的签名段从1到N编号，如下所示。设安全路径段1和签名段1为原点AS生成的段。设安全路径段2和签名段2为下一个AS在原点后添加的段。继续这种编号方法，最终让安全路径段N和签名段N成为当前AS添加的部分。当前AS（第N个AS）对更新消息进行签名并将其转发到形成AS路径的AS链中的下一个AS（即，第N+1个AS）。
o In order to construct the digital signature for Signature Segment N (the Signature Segment being produced by the current AS), first construct the sequence of octets to be hashed as shown in Figure 8. This sequence of octets includes all the data that the Nth AS attests to by adding its digital signature in the UPDATE message that is being forwarded to a BGPsec speaker in the (N+1)th AS. (For the design rationale for choosing the specific structure in Figure 8, please see [Borchert].)
o 为了构造签名段N（当前AS生成的签名段）的数字签名，首先构造要散列的八位字节序列，如图8所示。该八位字节序列包括第N AS通过在更新消息中添加其数字签名来证明的所有数据，该更新消息正被转发给第（N+1）AS中的BGPsec扬声器。（关于选择图8中特定结构的设计原理，请参见[Borchert]。）
+------------------------------------+
| Target AS Number |
+------------------------------------+----\
| Signature Segment : N-1 | \
+------------------------------------+ |
| Secure_Path Segment : N | |
+------------------------------------+ \
... > Data from
+------------------------------------+ / N Segments
| Signature Segment : 1 | |
+------------------------------------+ |
| Secure_Path Segment : 2 | |
+------------------------------------+ /
| Secure_Path Segment : 1 | /
+------------------------------------+---/
| Algorithm Suite Identifier |
+------------------------------------+
| AFI |
+------------------------------------+
| SAFI |
+------------------------------------+
| NLRI |
+------------------------------------+
+------------------------------------+
| Target AS Number |
+------------------------------------+----\
| Signature Segment : N-1 | \
+------------------------------------+ |
| Secure_Path Segment : N | |
+------------------------------------+ \
... > Data from
+------------------------------------+ / N Segments
| Signature Segment : 1 | |
+------------------------------------+ |
| Secure_Path Segment : 2 | |
+------------------------------------+ /
| Secure_Path Segment : 1 | /
+------------------------------------+---/
| Algorithm Suite Identifier |
+------------------------------------+
| AFI |
+------------------------------------+
| SAFI |
+------------------------------------+
| NLRI |
+------------------------------------+
Figure 8: Sequence of Octets to Be Hashed
图8：要散列的八位字节序列
The elements in this sequence (Figure 8) MUST be ordered exactly as shown. The 'Target AS Number' is the AS to whom the BGPsec speaker intends to send the UPDATE message. (Note that the 'Target AS Number' is the AS number announced by the peer in the OPEN message of the BGP session within which the UPDATE message is sent.) The Secure_Path and Signature Segments (1 through N-1) are obtained from the BGPsec_PATH attribute. Finally, the Address Family Identifier (AFI), Subsequent Address Family Identifier (SAFI), and NLRI fields are obtained from the MP_REACH_NLRI attribute [RFC4760]. Additionally, in the Prefix field within the NLRI field (see Section 5 in RFC 4760 [RFC4760]), all of the trailing bits MUST be set to 0 when constructing this sequence.
此序列中的元素（图8）必须按所示顺序排列。“目标AS编号”是BGPsec发言人打算向其发送更新消息的AS。（请注意，“目标AS编号”是对等方在发送更新消息的BGP会话的开放消息中宣布的AS编号。）安全路径和签名段（1到N-1）从BGPsec_路径属性中获取。最后，从MP_REACH_NLRI属性[RFC4760]获取地址族标识符（AFI）、后续地址族标识符（SAFI）和NLRI字段。此外，在NLRI字段内的前缀字段中（参见RFC 4760[RFC4760]中的第5节），在构造该序列时，所有尾随位必须设置为0。
o Apply to this octet sequence (in Figure 8) the digest algorithm (for the algorithm suite of this Signature_Block) to obtain a digest value.
o 将摘要算法（用于此签名块的算法套件）应用于此八位组序列（图8中），以获得摘要值。
o Apply to this digest value the signature algorithm (for the algorithm suite of this Signature_Block) to obtain the digital signature. Then populate the Signature field (in Figure 7) with this digital signature.
o 将签名算法（用于此签名块的算法套件）应用于此摘要值以获得数字签名。然后用这个数字签名填充签名字段（图7）。
The Signature Length field (in Figure 7) is populated with the length (in octets) of the value in the Signature field.
签名长度字段（图7中）由签名字段中值的长度（以八位字节为单位）填充。
Members of AS confederations [RFC5065] MUST additionally follow the instructions in this section for processing BGPsec UPDATE messages.
AS联合会[RFC5065]的成员还必须遵循本节中的说明来处理BGPsec更新消息。
When a BGPsec speaker in an AS confederation receives a BGPsec UPDATE message from a peer that is external to the confederation and chooses to propagate the UPDATE message within the confederation, it first adds a signature signed to its own Member-AS (i.e., the 'Target AS Number' is the BGPsec speaker's Member-AS Number). In this internally modified UPDATE message, the newly added Secure_Path Segment contains the public AS number (i.e., Confederation Identifier), the segment's pCount value is set to 0, and Confed_Segment flag is set to 1. Setting pCount=0 in this case helps ensure that the AS path length is not unnecessarily incremented. The newly added signature is generated using a private key corresponding to the public AS number of the confederation. The BGPsec speaker propagates the modified UPDATE message to its peers within the confederation.
当AS联盟中的BGPsec演讲者从联盟外部的对等方接收到BGPsec更新消息并选择在联盟内传播更新消息时，它首先添加签名给其自己的成员AS（即，“目标AS编号”是BGPsec演讲者的成员AS编号）。在这个内部修改的更新消息中，新添加的安全路径段包含公共AS编号（即联邦标识符），该段的pCount值设置为0，Confed_段标志设置为1。在这种情况下，设置pCount=0有助于确保AS路径长度不会不必要地增加。新添加的签名是使用一个私钥生成的，该私钥对应于作为联盟编号的公共密钥。BGPsec演讲者将修改后的更新消息传播给联盟内的对等方。
Any BGPsec_PATH modifications mentioned below in the context of propagation of the UPDATE message within the confederation are in addition to the modification described above (i.e., with pCount=0).
在联盟内传播更新消息的上下文中，下面提到的任何BGPsec_路径修改是对上述修改的补充（即，pCount=0）。
When a BGPsec speaker sends a BGPsec UPDATE message to a peer that belongs within its own Member-AS, the confederation member SHALL NOT modify the BGPsec_PATH attribute. When a BGPsec speaker sends a BGPsec UPDATE message to a peer that is within the same confederation but in a different Member-AS, the BGPsec speaker puts its Member-AS Number in the AS Number field of the Secure_Path Segment that it adds to the BGPsec UPDATE message. Additionally, in this case, the Member-AS that generates the Secure_Path Segment sets the Confed_Segment flag to 1. Further, the signature is generated with a private key corresponding to the BGPsec speaker's Member-AS Number. (Note: In this document, intra-Member-AS peering is regarded as iBGP, and inter-Member-AS peering is regarded as eBGP. The latter is also known as confederation-eBGP.)
当BGPsec发言人向属于其自身成员AS的对等方发送BGPsec更新消息时，联盟成员不得修改BGPsec_路径属性。当BGPsec演讲者向同一联盟内但不同成员AS中的对等方发送BGPsec更新消息时，BGPsec演讲者将其成员AS编号放入其添加到BGPsec更新消息的安全路径段的AS编号字段中。此外，在这种情况下，生成安全路径段的成员AS将Confed_段标志设置为1。此外，使用与BGPsec演讲者的成员AS号码相对应的私钥生成签名。（注：在本文档中，成员内部AS对等被视为iBGP，成员间AS对等被视为eBGP。后者也称为联邦eBGP。）
Within a confederation, the verification of BGPsec signatures added by other members of the confederation is optional. Note that if a confederation chooses not to verify digital signatures within the confederation, then BGPsec is not able to provide any assurances about the integrity of the Member-AS Numbers placed in Secure_Path Segments where the Confed_Segment flag is set to 1.
在联邦内，联邦其他成员添加的BGPsec签名的验证是可选的。请注意，如果联盟选择不验证联盟内的数字签名，则BGPsec无法提供任何关于成员完整性的保证，因为在安全路径段（其中Confed_段标志设置为1）中放置了数字。
When a confederation member receives a BGPsec UPDATE message from a peer within the confederation and propagates it to a peer outside the confederation, it needs to remove all of the Secure_Path Segments added by confederation members as well as the corresponding Signature Segments. To do this, the confederation member propagating the route outside the confederation does the following:
当联盟成员从联盟内的对等方接收到BGPsec更新消息并将其传播到联盟外的对等方时，它需要删除联盟成员添加的所有安全路径段以及相应的签名段。为此，在联盟外部传播路线的联盟成员执行以下操作：
o First, starting with the most recently added Secure_Path Segment, remove all of the consecutive Secure_Path Segments that have the Confed_Segment flag set to 1. Stop this process once a Secure_Path Segment that has its Confed_Segment flag set to 0 is reached. Keep a count of the number of segments removed in this fashion.
o 首先，从最近添加的安全路径段开始，删除所有连续的安全路径段，这些安全路径段的Confed_段标志设置为1。一旦到达其Confed_段标志设置为0的安全_路径段，请停止此过程。记录以这种方式删除的段数。
o Second, starting with the most recently added Signature Segment, remove a number of Signature Segments equal to the number of Secure_Path Segments removed in the previous step. (That is, remove the K most recently added Signature Segments, where K is the number of Secure_Path Segments removed in the previous step.)
o 其次，从最近添加的签名段开始，删除与上一步中删除的安全路径段数量相等的签名段数量。（也就是说，删除最近添加的K个签名段，其中K是在上一步中删除的Secure_Path段数。）
o Finally, add a Secure_Path Segment containing, in the AS field, the AS Confederation Identifier (the public AS number of the confederation) as well as a corresponding Signature Segment. Note that all fields other than the AS field are populated as per Section 4.2.
o 最后，在AS字段中添加一个安全路径段，其中包含AS联盟标识符（联盟的公共AS编号）以及相应的签名段。请注意，AS字段以外的所有字段均按照第4.2节进行填充。
Finally, as discussed above, an AS confederation MAY optionally decide that its members will not verify digital signatures added by members. In such a confederation, when a BGPsec speaker runs the algorithm in Section 5.2, the BGPsec speaker, during the process of signature verifications, first checks whether the Confed_Segment flag in a Secure_Path Segment is set to 1. If the flag is set to 1, the BGPsec speaker skips the verification for the corresponding signature and immediately moves on to the next Secure_Path Segment. Note that as specified in Section 5.2, it is an error when a BGPsec speaker receives, from a peer who is not in the same AS confederation, a BGPsec UPDATE message containing a Confed_Segment flag set to 1.
最后，如上所述，as联盟可以选择决定其成员不验证成员添加的数字签名。在这样的联盟中，当BGPsec演讲者运行第5.2节中的算法时，BGPsec演讲者在签名验证过程中，首先检查安全路径段中的Confed_段标志是否设置为1。如果标志设置为1，BGPsec扬声器将跳过相应签名的验证，并立即转到下一个安全路径段。请注意，如第5.2节所述，当BGPsec扬声器从与联邦不同的对等方接收到包含设置为1的Confed_段标志的BGPsec更新消息时，这是一个错误。
BGPsec UPDATE messages do not contain the AS_PATH attribute. However, the AS_PATH attribute can be reconstructed from the BGPsec_PATH attribute. This is necessary in the case where a route advertisement is received via a BGPsec UPDATE message and then propagated to a peer via a non-BGPsec UPDATE message (e.g., because the latter peer does not support BGPsec). Note that there may be additional cases where an implementation finds it useful to perform this reconstruction. Before attempting to reconstruct an AS_PATH for
BGPsec更新消息不包含AS_PATH属性。但是，AS_路径属性可以从BGPsec_路径属性重建。在通过BGPsec更新消息接收路由公告，然后通过非BGPsec更新消息传播到对等方（例如，因为后者不支持BGPsec）的情况下，这是必要的。请注意，在其他情况下，实现可能会发现执行此重建非常有用。在尝试重建的AS_路径之前
the purpose of forwarding an unsigned (non-BGPsec) UPDATE message to a peer, a BGPsec speaker MUST perform the basic integrity checks listed in Section 5.2 to ensure that the received BGPsec UPDATE message is properly formed.
为了向对等方转发未签名（非BGPsec）更新消息，BGPsec发言人必须执行第5.2节中列出的基本完整性检查，以确保收到的BGPsec更新消息格式正确。
The AS_PATH attribute can be constructed from the BGPsec_PATH attribute as follows. Starting with a blank AS_PATH attribute, process the Secure_Path Segments in order from least recently added (corresponding to the origin) to most recently added. For each Secure_Path Segment, perform the following steps:
AS_PATH属性可以从BGPsec_PATH属性构建，如下所示。从一个空白的AS_PATH属性开始，按从最近添加（对应于原点）到最近添加的顺序处理安全_路径段。对于每个安全路径段，执行以下步骤：
1. If the Secure_Path Segment has pCount=0, then do nothing (i.e., move on to process the next Secure_Path Segment).
1. 如果安全路径段的pCount=0，则不执行任何操作（即，继续处理下一个安全路径段）。
2. If the Secure_Path Segment has pCount greater than 0 and the Confed_Segment flag is set to 1, then look at the most recently added segment in the AS_PATH.
2. 如果安全_路径段的pCount大于0，并且Confed_段标志设置为1，则查看AS_路径中最近添加的段。
* In the case where the AS_PATH is blank or in the case where the most recently added segment is of type AS_SEQUENCE, add (prepend to the AS_PATH) a new AS_PATH segment of type AS_CONFED_SEQUENCE. This segment of type AS_CONFED_SEQUENCE shall contain a number of elements equal to the pCount field in the current Secure_Path Segment. Each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then the segment of type AS_CONFED_SEQUENCE contains X copies of the Secure_Path Segment's AS Number field.)
* 在AS_路径为空或最近添加的段类型为AS_序列的情况下，添加（在AS_路径之前）AS_序列类型的新AS_路径段。此类型为“已确认”序列的段应包含与当前安全路径段中的pCount字段相等的多个元素。这些元素中的每一个都应为当前安全路径段中包含的AS编号。（也就是说，如果pCount字段是X，那么类型为AS_confided_序列的段包含安全路径段的AS Number字段的X个副本。）
* In the case where the most recently added segment in the AS_PATH is of type AS_CONFED_SEQUENCE, then add (prepend to the segment) a number of elements equal to the pCount field in the current Secure_Path Segment. The value of each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then add X copies of the Secure_Path Segment's AS Number field to the existing AS_CONFED_SEQUENCE.)
* 如果AS_路径中最近添加的段属于AS_确认_序列类型，则在当前安全_路径段中添加（在段前添加）与pCount字段相等的元素数。这些元素的值应为当前安全路径段中包含的AS编号。（也就是说，如果pCount字段为X，则将安全路径段的AS Number字段的X个副本添加到现有AS_confided_序列中。）
3. If the Secure_Path Segment has pCount greater than 0 and the Confed_Segment flag is set to 0, then look at the most recently added segment in the AS_PATH.
3. 如果安全_路径段的pCount大于0，并且Confed_段标志设置为0，则查看AS_路径中最近添加的段。
* In the case where the AS_PATH is blank or in the case where the most recently added segment is of type AS_CONFED_SEQUENCE, add (prepend to the AS_PATH) a new AS_PATH segment of type AS_SEQUENCE. This segment of type AS_SEQUENCE shall contain a number of elements equal to the pCount field in the current Secure_Path Segment. Each of these elements shall be the AS
* 在AS_路径为空或最近添加的段类型为AS_CONFED_序列的情况下，添加（在AS_路径之前）AS_序列类型的新AS_路径段。AS_序列类型的该段应包含与当前安全路径段中的pCount字段相等的多个元素。这些元素中的每一个都应为
number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then the segment of type AS_SEQUENCE contains X copies of the Secure_Path Segment's AS Number field.)
当前安全路径段中包含的编号。（也就是说，如果pCount字段为X，则类型为AS_序列的段包含Secure_路径段的AS Number字段的X个副本。）
* In the case where the most recently added segment in the AS_PATH is of type AS_SEQUENCE, then add (prepend to the segment) a number of elements equal to the pCount field in the current Secure_Path Segment. The value of each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then add X copies of the Secure_Path Segment's AS Number field to the existing AS_SEQUENCE.)
* 如果AS_路径中最近添加的段属于AS_序列类型，则在当前安全_路径段中添加（在段前添加）与pCount字段相等的元素数。这些元素的值应为当前安全路径段中包含的AS编号。（也就是说，如果pCount字段为X，则将Secure_路径段的AS Number字段的X个副本添加到现有AS_序列中。）
As part of the procedure described above, the following additional actions are performed in order not to exceed the size limitations of AS_SEQUENCE and AS_CONFED_SEQUENCE. While adding the next Secure_Path Segment (with its prepends, if any) to the AS_PATH being assembled, if it would cause the AS_SEQUENCE (or AS_CONFED_SEQUENCE) at hand to exceed the limit of 255 AS numbers per segment [RFC4271] [RFC5065], then the BGPsec speaker would follow the recommendations in RFC 4271 [RFC4271] and RFC 5065 [RFC5065] of creating another segment of the same type (AS_SEQUENCE or AS_CONFED_SEQUENCE) and continue filling that.
作为上述程序的一部分，执行以下附加操作，以不超过As_序列和As_CONFED_序列的尺寸限制。在将下一个安全路径段（及其前缀，如果有的话）添加到正在组装的AS_路径时，如果它会导致手头的AS_序列（或AS_CONFED_序列）超过每个段255个AS数的限制[RFC4271][RFC5065]，那么BGPsec扬声器将遵循RFC 4271[RFC4271]和RFC 5065[RFC5065]中的建议创建另一个相同类型的段（作为_序列或作为_确认的_序列）并继续填充该段。
Finally, one special case of reconstruction of AS_PATH is when the BGPsec_PATH attribute is absent. As explained in Section 4.1, when a BGPsec speaker originates a prefix and sends it to a BGPsec-capable iBGP peer, the BGPsec_PATH is not attached. So, when received from a BGPsec-capable iBGP peer, no BGPsec_PATH attribute in a BGPsec UPDATE message is equivalent to an empty AS_PATH [RFC4271].
最后，重建AS_路径的一种特殊情况是缺少BGPsec_路径属性。如第4.1节所述，当BGPsec扬声器发出前缀并将其发送给支持BGPsec的iBGP对等方时，BGPsec_路径不连接。因此，当从支持BGPsec的iBGP对等方接收时，BGPsec更新消息中的BGPsec_路径属性不等于空的AS_路径[RFC4271]。
Upon receiving a BGPsec UPDATE message from an external (eBGP) peer, a BGPsec speaker SHOULD validate the message to determine the authenticity of the path information contained in the BGPsec_PATH attribute. Typically, a BGPsec speaker will also wish to perform origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]) on an incoming BGPsec UPDATE message, but such validation is independent of the validation described in this section.
收到来自外部（eBGP）对等方的BGPsec更新消息后，BGPsec发言人应验证该消息，以确定BGPsec_路径属性中包含的路径信息的真实性。通常，BGPsec演讲者还希望对传入的BGPsec更新消息执行来源验证（请参阅RFC 6483[RFC6483]和RFC 6811[RFC6811]），但此类验证独立于本节所述的验证。
Section 5.1 provides an overview of BGPsec validation, and Section 5.2 provides a specific algorithm for performing such validation. (Note that an implementation need not follow the specific algorithm in Section 5.2 as long as the input/output behavior of the validation is identical to that of the algorithm in Section 5.2.) During exceptional conditions (e.g., the BGPsec
第5.1节概述了BGPsec验证，第5.2节提供了执行此类验证的具体算法。（请注意，只要验证的输入/输出行为与第5.2节中的算法相同，实施无需遵循第5.2节中的特定算法。）在异常情况下（例如，BGPsec
speaker receives an incredibly large number of UPDATE messages at once), a BGPsec speaker MAY temporarily defer validation of incoming BGPsec UPDATE messages. The treatment of such BGPsec UPDATE messages, whose validation has been deferred, is a matter of local policy. However, an implementation SHOULD ensure that deferment of validation and status of deferred messages is visible to the operator.
说话人一次收到数量惊人的更新消息），BGPsec说话人可能会暂时推迟对传入BGPsec更新消息的验证。此类BGPsec更新消息（其验证已延迟）的处理是本地策略的问题。但是，实现应确保操作员可以看到延迟验证和延迟消息的状态。
The validity of BGPsec UPDATE messages is a function of the current RPKI state. When a BGPsec speaker learns that the RPKI state has changed (e.g., from an RPKI validating cache via the RPKI-Router protocol [RFC8210]), the BGPsec speaker MUST rerun validation on all affected UPDATE messages stored in its Adj-RIB-In [RFC4271]. For example, when a given RPKI router certificate ceases to be valid (e.g., it expires or is revoked), all UPDATE messages containing a signature whose SKI matches the SKI in the given certificate MUST be reassessed to determine if they are still valid. If this reassessment determines that the validity state of an UPDATE message has changed, then, depending on local policy, it may be necessary to rerun best path selection.
BGPsec更新消息的有效性是当前RPKI状态的函数。当BGPsec扬声器得知RPKI状态已更改时（例如，通过RPKI路由器协议[RFC8210]从RPKI验证缓存），BGPsec扬声器必须在[RFC4271]中对其Adj RIB中存储的所有受影响的更新消息重新运行验证。例如，当给定的RPKI路由器证书不再有效（例如，它过期或被吊销）时，必须重新评估所有包含签名（其SKI与给定证书中的SKI匹配）的更新消息，以确定它们是否仍然有效。如果此重新评估确定更新消息的有效状态已更改，则可能需要根据本地策略重新运行最佳路径选择。
BGPsec UPDATE messages do not contain an AS_PATH attribute. The Secure_Path contains AS path information for the BGPsec UPDATE message. Therefore, a BGPsec speaker MUST utilize the AS path information in the Secure_Path in all cases where it would otherwise use the AS path information in the AS_PATH attribute. The only exception to this rule is when AS path information must be updated in order to propagate a route to a peer (in which case the BGPsec speaker follows the instructions in Section 4). Section 4.4 provides an algorithm for constructing an AS_PATH attribute from a BGPsec_PATH attribute. Whenever the use of AS path information is called for (e.g., loop detection or the use of the AS path length in best path selection), the externally visible behavior of the implementation shall be the same as if the implementation had run the algorithm in Section 4.4 and used the resulting AS_PATH attribute as it would for a non-BGPsec UPDATE message.
BGPsec更新消息不包含AS_路径属性。安全路径包含BGPsec更新消息的路径信息。因此，BGPsec演讲者必须在所有情况下使用安全_路径中的AS路径信息，否则将使用AS_路径属性中的AS路径信息。此规则的唯一例外是必须更新AS路径信息，以便将路由传播到对等方（在这种情况下，BGPsec扬声器遵循第4节中的说明）。第4.4节提供了从BGPsec_路径属性构造AS_路径属性的算法。每当需要使用AS路径信息时（例如，环路检测或在最佳路径选择中使用AS路径长度），实现的外部可见行为应与实现已运行第4.4节中的算法并使用结果as_路径属性的情况相同，如同对非BGPsec更新消息一样。
Validation of a BGPsec UPDATE message makes use of data from RPKI router certificates. In particular, it is necessary that the recipient have access to the following data obtained from valid RPKI router certificates: the AS Number, Public Key, and Subject Key Identifier from each valid RPKI router certificate.
BGPsec更新消息的验证使用来自RPKI路由器证书的数据。特别是，接收方必须能够访问从有效RPKI路由器证书获得的以下数据：每个有效RPKI路由器证书的AS编号、公钥和使用者密钥标识符。
Note that the BGPsec speaker could perform the validation of RPKI router certificates on its own and extract the required data, or it could receive the same data from a trusted cache that performs RPKI
请注意，BGPsec演讲者可以自己执行RPKI路由器证书的验证并提取所需的数据，也可以从执行RPKI的可信缓存接收相同的数据
validation on behalf of (some set of) BGPsec speakers. (For example, the trusted cache could deliver the necessary validity information to the BGPsec speaker by using the Router Key PDU (Protocol Data Unit) for the RPKI-Router protocol [RFC8210].)
代表（部分）BGPsec发言人进行验证。（例如，可信缓存可以通过使用RPKI路由器协议[RFC8210]的路由器密钥PDU（协议数据单元）向BGPsec扬声器提供必要的有效性信息。）
To validate a BGPsec UPDATE message containing the BGPsec_PATH attribute, the recipient performs the validation steps specified in Section 5.2. The validation procedure results in one of two states: 'Valid' and 'Not Valid'.
要验证包含BGPsec_路径属性的BGPsec更新消息，收件人将执行第5.2节中指定的验证步骤。验证过程会导致两种状态之一：“有效”和“无效”。
It is expected that the output of the validation procedure will be used as an input to BGP route selection. That said, BGP route selection, and thus the handling of the validation states, is a matter of local policy and is handled using local policy mechanisms. Implementations SHOULD enable operators to set such local policy on a per-session basis. (That is, it is expected that some operators will choose to treat BGPsec validation status differently for UPDATE messages received over different BGP sessions.)
预计验证程序的输出将用作BGP路由选择的输入。也就是说，BGP路由选择以及验证状态的处理是本地策略的问题，并且使用本地策略机制进行处理。实现应使操作员能够在每个会话的基础上设置此类本地策略。（也就是说，对于通过不同BGP会话接收的更新消息，一些运营商可能会选择不同的方式处理BGPsec验证状态。）
BGPsec validation need only be performed at the eBGP edge. The validation status of a BGP signed/unsigned UPDATE message MAY be conveyed via iBGP from an ingress edge router to an egress edge router via some mechanism, according to local policy within an AS. As discussed in Section 4, when a BGPsec speaker chooses to forward a (syntactically correct) BGPsec UPDATE message, it SHOULD be forwarded with its BGPsec_PATH attribute intact (regardless of the validation state of the UPDATE message). Based entirely on local policy, an egress router receiving a BGPsec UPDATE message from within its own AS MAY choose to perform its own validation.
BGPsec验证只需在eBGP边缘执行。根据AS内的本地策略，BGP签名/未签名更新消息的验证状态可以通过iBGP经由某种机制从入口边缘路由器传送到出口边缘路由器。如第4节所述，当BGPsec演讲者选择转发（语法正确的）BGPsec更新消息时，应将其BGPsec_路径属性完整地转发（无论更新消息的验证状态如何）。完全基于本地策略，从其自身AS接收BGPsec更新消息的出口路由器可以选择执行其自身验证。
This section specifies an algorithm for validation of BGPsec UPDATE messages. A conformant implementation MUST include a BGPsec update validation algorithm that is functionally equivalent to the externally visible behavior of this algorithm.
本节指定验证BGPsec更新消息的算法。一致性实现必须包括BGPsec更新验证算法，该算法在功能上等同于该算法的外部可见行为。
First, the recipient of a BGPsec UPDATE message performs a check to ensure that the message is properly formed. Both syntactical and protocol violation errors are checked. The BGPsec_PATH attribute MUST be present when a BGPsec UPDATE message is received from an external (eBGP) BGPsec peer and also when such an UPDATE message is propagated to an internal (iBGP) BGPsec peer (see Section 4.2). The error checks specified in Section 6.3 of [RFC4271] are performed, except that for BGPsec UPDATE messages the checks on the AS_PATH attribute do not apply and instead the following checks on the BGPsec_PATH attribute are performed:
首先，BGPsec更新消息的接收者执行检查以确保消息的格式正确。检查语法和协议冲突错误。当从外部（eBGP）BGPsec对等方接收到BGPsec更新消息时，以及当此类更新消息传播到内部（iBGP）BGPsec对等方时，必须存在BGPsec_路径属性（参见第4.2节）。执行[RFC4271]第6.3节中规定的错误检查，但对于BGPsec更新消息，AS_路径属性的检查不适用，而是对BGPsec_路径属性执行以下检查：
1. Check to ensure that the entire BGPsec_PATH attribute is syntactically correct (conforms to the specification in this document).
1. 检查以确保整个BGPsec_路径属性的语法正确（符合本文档中的规范）。
2. Check that the AS number in the most recently added Secure_Path Segment (i.e., the one corresponding to the eBGP peer from which the UPDATE message was received) matches the AS number of that peer as specified in the BGP OPEN message. (Note: This check is performed only at an ingress BGPsec router where the UPDATE message is first received from a peer AS.)
2. 检查最近添加的安全路径段中的AS编号（即，与接收更新消息的eBGP对等方对应的编号）是否与BGP OPEN消息中指定的该对等方的AS编号匹配。（注意：此检查仅在入口BGPsec路由器上执行，其中更新消息首先从对等AS接收。）
3. Check that each Signature_Block contains one Signature Segment for each Secure_Path Segment in the Secure_Path portion of the BGPsec_PATH attribute. (Note that the entirety of each Signature_Block MUST be checked to ensure that it is well formed, even though the validation process may terminate before all signatures are cryptographically verified.)
3. 检查每个签名块是否包含BGPsec_路径属性的安全_路径部分中每个安全_路径段的一个签名段。（注意，必须检查每个签名_块的整体，以确保其格式正确，即使验证过程可能在所有签名通过加密验证之前终止。）
4. Check that the UPDATE message does not contain an AS_PATH attribute.
4. 检查更新消息是否不包含AS_PATH属性。
5. If the UPDATE message was received from a BGPsec peer that is not a member of the BGPsec speaker's AS confederation, check to ensure that none of the Secure_Path Segments contain a Flags field with the Confed_Segment flag set to 1.
5. 如果从不是BGPsec演讲者AS联盟成员的BGPsec对等方接收到更新消息，请检查以确保没有任何安全_路径段包含Confed_段标志设置为1的标志字段。
6. If the UPDATE message was received from a BGPsec peer that is a member of the BGPsec speaker's AS confederation, check to ensure that the Secure_Path Segment corresponding to that peer contains a Flags field with the Confed_Segment flag set to 1.
6. 如果从作为BGPsec发言人AS联盟成员的BGPsec对等方接收到更新消息，请检查以确保与该对等方对应的安全路径段包含一个标志字段，其中Confed_段标志设置为1。
7. If the UPDATE message was received from a peer that is not expected to set pCount=0 (see Sections 4.2 and 4.3), then check to ensure that the pCount field in the most recently added Secure_Path Segment is not equal to 0. (Note: See Section 7.2 for router configuration guidance related to this item.)
7. 如果从不希望将pCount设置为0的对等方接收到更新消息（请参阅第4.2节和第4.3节），则检查以确保最近添加的安全路径段中的pCount字段不等于0。（注：有关此项的路由器配置指南，请参见第7.2节。）
8. Using the equivalent of AS_PATH corresponding to the Secure_Path in the UPDATE message (see Section 4.4), check that the local AS number is not present in the AS path (i.e., rule out an AS loop).
8. 使用与更新消息中的安全路径相对应的等效AS_路径（参见第4.4节），检查AS路径中是否不存在本地AS编号（即，排除AS循环）。
If any of these checks fail, it is an error in the BGPsec_PATH attribute. BGPsec speakers MUST handle any syntactical or protocol errors in the BGPsec_PATH attribute by using the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606]. (Note: Since the AS number of a transparent route server does appear in the Secure_Path with pCount=0, the route server MAY check to see if its local AS is
如果其中任何一项检查失败，则BGPsec_路径属性中存在错误。BGPsec发言人必须使用RFC 7606[RFC7606]中定义的“视为撤回”方法处理BGPsec_路径属性中的任何语法或协议错误。（注意：由于透明路由服务器的AS编号确实出现在pCount=0的Secure_路径中，因此路由服务器可能会检查其本地AS是否为
listed in the Secure_Path, and this check MAY be included in the loop-detection check listed above.)
在安全路径中列出，此检查可能包括在上面列出的循环检测检查中。）
Next, the BGPsec speaker examines the Signature_Blocks in the BGPsec_PATH attribute. A Signature_Block corresponding to an algorithm suite that the BGPsec speaker does not support is not considered in the validation process. If there is no Signature_Block corresponding to an algorithm suite that the BGPsec speaker supports, then in order to consider the UPDATE message in the route selection process, the BGPsec speaker MUST strip the Signature_Block(s), reconstruct the AS_PATH from the Secure_Path (see Section 4.4), and treat the UPDATE message as if it were received as an unsigned BGP UPDATE message.
接下来，BGPsec演讲者检查BGPsec_路径属性中的签名_块。验证过程中不考虑与BGPsec演讲者不支持的算法套件相对应的签名块。如果没有对应于BGPSEC说话人支持的算法套件的签名块，那么为了考虑路由选择过程中的更新消息，BGPSEC发言者必须删除签名块（S），从SeCURIL路径重构ASSPATH（参见第4.4节），并将更新消息视为未签名的BGP更新消息。
For each remaining Signature_Block (corresponding to an algorithm suite supported by the BGPsec speaker), the BGPsec speaker iterates through the Signature Segments in the Signature_Block, starting with the most recently added segment (and concluding with the least recently added segment). Note that there is a one-to-one correspondence between Signature Segments and Secure_Path Segments within the BGPsec_PATH attribute. The following steps make use of this correspondence:
对于每个剩余的签名_块（对应于BGPsec演讲者支持的算法套件），BGPsec演讲者迭代签名_块中的签名段，从最近添加的段开始（以最近添加的段结束）。请注意，在BGPsec_路径属性中，签名段和安全_路径段之间存在一对一的对应关系。以下步骤利用此对应关系：
o Step 1: Let there be K AS hops in a received BGPsec_PATH attribute that is to be validated. Let AS(1), AS(2), ..., AS(K+1) denote the sequence of AS numbers from the origin AS to the validating AS. Let Secure_Path Segment N and Signature Segment N in the BGPsec_PATH attribute refer to those corresponding to AS(N) (where N = 1, 2, ..., K). The BGPsec speaker that is processing and validating the BGPsec_PATH attribute resides in AS(K+1). Let Signature Segment N be the Signature Segment that is currently being verified.
o 步骤1：在要验证的接收到的BGPsec_路径属性中有K个AS跃点。设AS（1），AS（2），…，AS（K+1）表示从原点AS到验证AS的AS数序列。让BGPsec_路径属性中的安全_路径段N和签名段N引用与AS（N）（其中N=1，2，…，K）相对应的部分。正在处理和验证BGPsec_路径属性的BGPsec扬声器位于AS（K+1）中。让签名段N为当前正在验证的签名段。
o Step 2: Locate the public key needed to verify the signature (in the current Signature Segment). To do this, consult the valid RPKI router certificate data and look up all valid (AS Number, Public Key, Subject Key Identifier) triples in which the AS matches the AS number in the corresponding Secure_Path Segment. Of these triples that match the AS number, check whether there is an SKI that matches the value in the Subject Key Identifier field of the Signature Segment. If this check finds no such matching SKI value, then mark the entire Signature_Block as 'Not Valid' and proceed to the next Signature_Block.
o 步骤2：找到验证签名所需的公钥（在当前签名段中）。为此，请查阅有效的RPKI路由器证书数据，并查找所有有效的（AS编号、公钥、使用者密钥标识符）三元组，其中AS与相应安全路径段中的AS编号匹配。在这些匹配AS编号的三元组中，检查是否有与签名段的Subject Key Identifier字段中的值匹配的SKI。如果此检查未发现此类匹配的SKI值，则将整个签名\u块标记为“无效”，并继续下一个签名\u块。
o Step 3: Compute the digest function (for the given algorithm suite) on the appropriate data.
o 步骤3：在适当的数据上计算摘要函数（对于给定的算法套件）。
In order to verify the digital signature in Signature Segment N, construct the sequence of octets to be hashed as shown in Figure 9 (using the notations defined in Step 1). (Note that this sequence is the same sequence that was used by AS(N) that created the Signature Segment N (see Section 4.2 and Figure 8).)
为了验证签名段N中的数字签名，如图9所示（使用步骤1中定义的符号），构造要散列的八位字节序列。（注意，该序列与创建签名段N的AS（N）使用的序列相同（参见第4.2节和图8）。）
+------------------------------------+
| Target AS Number |
+------------------------------------+----\
| Signature Segment : N-1 | \
+------------------------------------+ |
| Secure_Path Segment : N | |
+------------------------------------+ \
... > Data from
+------------------------------------+ / N Segments
| Signature Segment : 1 | |
+------------------------------------+ |
| Secure_Path Segment : 2 | |
+------------------------------------+ /
| Secure_Path Segment : 1 | /
+------------------------------------+---/
| Algorithm Suite Identifier |
+------------------------------------+
| AFI |
+------------------------------------+
| SAFI |
+------------------------------------+
| NLRI |
+------------------------------------+
+------------------------------------+
| Target AS Number |
+------------------------------------+----\
| Signature Segment : N-1 | \
+------------------------------------+ |
| Secure_Path Segment : N | |
+------------------------------------+ \
... > Data from
+------------------------------------+ / N Segments
| Signature Segment : 1 | |
+------------------------------------+ |
| Secure_Path Segment : 2 | |
+------------------------------------+ /
| Secure_Path Segment : 1 | /
+------------------------------------+---/
| Algorithm Suite Identifier |
+------------------------------------+
| AFI |
+------------------------------------+
| SAFI |
+------------------------------------+
| NLRI |
+------------------------------------+
Figure 9: Sequence of Octets to Be Hashed for Signature Verification of Signature Segment N; N = 1,2, ..., K, Where K Is the Number of AS Hops in the BGPsec_PATH Attribute
图9：为验证签名段N的签名而散列的八位字节序列；N=1,2，…，K，其中K是BGPsec_路径属性中的AS跃点数
The elements in this sequence (Figure 9) MUST be ordered exactly as shown. For the first segment to be processed (the most recently added segment (i.e., N = K) given that there are K hops in the Secure_Path), the 'Target AS Number' is AS(K+1), the AS number of the BGPsec speaker validating the UPDATE message. Note that if a BGPsec speaker uses multiple AS Numbers (e.g., the BGPsec speaker is a member of a confederation), the AS number used here MUST be the AS number announced in the OPEN message for the BGP session over which the BGPsec UPDATE message was received.
此序列中的元素（图9）必须按所示顺序排列。对于要处理的第一个段（最近添加的段（即，N=K），假定在安全路径中有K个跃点，“目标AS编号”为AS（K+1），即验证更新消息的BGPsec扬声器的AS编号。请注意，如果BGPsec发言人使用多个AS号码（例如，BGPsec发言人是联邦成员），则此处使用的AS号码必须是收到BGPsec更新消息的BGP会话的开放消息中宣布的AS号码。
For each other Signature Segment (N smaller than K), the 'Target AS Number' is AS(N+1), the AS number in the Secure_Path Segment that corresponds to the Signature Segment added immediately after the one being processed (that is, in the Secure_Path Segment that
对于每个其他签名段（N小于K），“目标AS编号”为AS（N+1），安全_路径段中的AS编号对应于在处理的签名段之后立即添加的签名段（即，在
corresponds to the Signature Segment that the validator just finished processing).
对应于验证器刚刚完成处理的签名段）。
The Secure_Path and Signature Segment are obtained from the BGPsec_PATH attribute. The AFI, SAFI, and NLRI fields are obtained from the MP_REACH_NLRI attribute [RFC4760]. Additionally, in the Prefix field within the NLRI field (see Section 5 in RFC 4760 [RFC4760]), all of the trailing bits MUST be set to 0 when constructing this sequence.
安全路径和签名段从BGPsec路径属性中获取。AFI、SAFI和NLRI字段从MP_REACH_NLRI属性[RFC4760]获取。此外，在NLRI字段内的前缀字段中（参见RFC 4760[RFC4760]中的第5节），在构造该序列时，所有尾随位必须设置为0。
o Step 4: Use the signature validation algorithm (for the given algorithm suite) to verify the signature in the current segment. That is, invoke the signature validation algorithm on the following three inputs: the value of the Signature field in the current segment, the digest value computed in Step 3 above, and the public key obtained from the valid RPKI data in Step 2 above. If the signature validation algorithm determines that the signature is invalid, then mark the entire Signature_Block as 'Not Valid' and proceed to the next Signature_Block. If the signature validation algorithm determines that the signature is valid, then continue processing Signature Segments (within the current Signature_Block).
o 步骤4：使用签名验证算法（针对给定的算法套件）验证当前段中的签名。也就是说，在以下三个输入上调用签名验证算法：当前段中签名字段的值、上面步骤3中计算的摘要值以及上面步骤2中从有效RPKI数据获得的公钥。如果签名验证算法确定签名无效，则将整个签名块标记为“无效”，然后继续下一个签名块。如果签名验证算法确定签名有效，则继续处理签名段（在当前签名块内）。
If all Signature Segments within a Signature_Block pass validation (i.e., all segments are processed and the Signature_Block has not yet been marked 'Not Valid'), then the Signature_Block is marked as 'Valid'.
如果签名块内的所有签名段都通过了验证（即，所有段都已处理且签名块尚未标记为“无效”），则签名块将标记为“有效”。
If at least one Signature_Block is marked as 'Valid', then the validation algorithm terminates and the BGPsec UPDATE message is deemed 'Valid'. (That is, if a BGPsec UPDATE message contains two Signature_Blocks, then the UPDATE message is deemed 'Valid' if the first Signature_Block is marked 'Valid' OR the second Signature_Block is marked 'Valid'.)
如果至少有一个签名块被标记为“有效”，则验证算法终止，BGPsec更新消息被视为“有效”。（即，如果BGPsec更新消息包含两个签名块，则如果第一个签名块标记为“有效”或第二个签名块标记为“有效”，则更新消息被视为“有效”。）
Note that there is currently no support for bilateral negotiation (using BGP capabilities) between BGPsec peers to use a particular (digest and signature) algorithm suite. This is because the algorithm suite used by the sender of a BGPsec UPDATE message MUST be understood not only by the peer to whom it is directly sending the message but also by all BGPsec speakers to whom the route advertisement is eventually propagated. Therefore, selection of an algorithm suite cannot be a local matter negotiated by BGP peers but instead must be coordinated throughout the Internet.
请注意，目前不支持BGPsec对等方之间使用特定（摘要和签名）算法套件进行双边协商（使用BGP功能）。这是因为BGPsec更新消息的发送者使用的算法套件不仅必须被直接向其发送消息的对等方理解，而且还必须被路由广告最终传播到的所有BGPsec说话者理解。因此，算法套件的选择不能是BGP对等方协商的本地问题，而必须在整个互联网上进行协调。
To this end, [RFC8208] specifies a mandatory-to-use 'current' algorithm suite for use by all BGPsec speakers.
为此，[RFC8208]规定所有BGPsec扬声器必须使用“当前”算法套件。
It is anticipated that, in the future, [RFC8208] or its successor will be updated to specify a transition from the 'current' algorithm suite to a 'new' algorithm suite. During the period of transition, all BGPsec UPDATE messages SHOULD simultaneously use both the 'current' algorithm suite and the 'new' algorithm suite. (Note that Sections 3 and 4 specify how the BGPsec_PATH attribute can contain signatures, in parallel, for two algorithm suites.) Once the transition is complete, the use of the old 'current' algorithm will be deprecated, the use of the 'new' algorithm will be mandatory, and a subsequent 'even newer' algorithm suite may be specified as "recommended to implement". Once the transition has successfully been completed in this manner, BGPsec speakers SHOULD include only a single Signature_Block (corresponding to the 'new' algorithm).
预计将来，[RFC8208]或其后续版本将更新，以指定从“当前”算法套件到“新”算法套件的过渡。在过渡期间，所有BGPsec更新消息应同时使用“当前”算法套件和“新”算法套件。（请注意，第3节和第4节规定了BGPsec_PATH属性如何并行包含两个算法套件的签名。）转换完成后，旧“当前”算法的使用将被弃用，“新”算法的使用将是强制性的，随后的“甚至更新”算法套件可能被指定为：“建议实施”。以这种方式成功完成转换后，BGPsec扬声器应仅包含一个签名块（对应于“新”算法）。
Depending on the method of generating key identifiers [RFC7093], the size of the SKI in an RPKI router certificate may vary. The SKI field in the BGPsec_PATH attribute has a fixed size of 20 octets (see Figure 7). If the SKI is longer than 20 octets, then use the leftmost 20 octets of the SKI (excluding the tag and length) [RFC7093]. If the SKI value is shorter than 20 octets, then pad the SKI (excluding the tag and length) to the right (least significant octets) with octets having "0" values.
根据生成密钥标识符的方法[RFC7093]，RPKI路由器证书中SKI的大小可能会有所不同。BGPsec_路径属性中的滑雪场大小固定为20个八位字节（见图7）。如果SKI长度超过20个八位字节，则使用SKI最左边的20个八位字节（不包括标签和长度）[RFC7093]。如果SKI值小于20个八位字节，则用具有“0”值的八位字节将SKI（不包括标记和长度）填充到右侧（最低有效八位字节）。
This section discusses potential changes to BGPsec that would require substantial changes to the processing of the BGPsec_PATH and thus necessitate a new version of BGPsec. Examples of such changes include:
本节讨论了BGPsec的潜在变更，这些变更需要对BGPsec_路径的处理进行重大变更，因此需要新版本的BGPsec。这些变化的例子包括：
o A new type of signature algorithm that produces signatures of variable length
o 一种产生可变长度签名的新型签名算法
o A new type of signature algorithm for which the number of signatures in the Signature_Block is not equal to the number of ASes in the Secure_Path (e.g., aggregate signatures)
o 一种新型签名算法，其签名块中的签名数不等于安全路径中的ASE数（例如，聚合签名）
o Changes to the data that is protected by the BGPsec signatures (e.g., attributes other than the AS path)
o 对受BGPsec签名保护的数据的更改（例如，AS路径以外的属性）
In the case that such a change to BGPsec were deemed desirable, it is expected that a subsequent version of BGPsec would be created and that this version of BGPsec would specify a new BGP path attribute --
如果认为需要对BGPsec进行此类更改，则预计将创建BGPsec的后续版本，并且该版本的BGPsec将指定新的BGP路径属性--
let's call it "BGPsec_PATH_Two" -- that is designed to accommodate the desired changes to BGPsec. In such a case, [RFC8208] or its successor would be updated to specify algorithm suites appropriate for the new version of BGPsec.
让我们称之为“BGPsec_PATH_Two”——它旨在适应对BGPsec所需的更改。在这种情况下，[RFC8208]或其后续版本将被更新，以指定适合新版本BGPsec的算法套件。
At this point, a transition would begin that is analogous to the algorithm transition discussed in Section 6.1. During the transition period, all BGPsec speakers SHOULD simultaneously include both the BGPsec_PATH attribute and the new BGPsec_PATH_Two attribute. Once the transition is complete, the use of BGPsec_PATH could then be deprecated, at which point BGPsec speakers should include only the new BGPsec_PATH_Two attribute. Such a process could facilitate a transition to a new BGPsec semantics in a backwards-compatible fashion.
此时，将开始类似于第6.1节中讨论的算法转换的转换。在过渡期间，所有BGPsec扬声器应同时包含BGPsec_路径属性和新的BGPsec_路径_两个属性。一旦转换完成，就可能不推荐使用BGPsec_PATH，此时BGPsec扬声器应该只包含新的BGPsec_PATH_Two属性。这样的过程可以以向后兼容的方式促进向新的BGPsec语义的转换。
Some operations and management issues that are closely relevant to BGPsec protocol specification and deployment are highlighted here. The best practices concerning operations and deployment of BGPsec are provided in [RFC8207].
这里强调了与BGPsec协议规范和部署密切相关的一些操作和管理问题。[RFC8207]中提供了有关BGPsec操作和部署的最佳实践。
Section 2.2 describes the negotiation required to establish a BGPsec-capable peering session. Not only must the BGPsec capability be exchanged (and agreed on), but the BGP multiprotocol extension [RFC4760] for the same AFI and the 4-byte AS capability [RFC6793] MUST also be exchanged. Failure to properly negotiate a BGPsec session -- due to a missing capability, for example -- may still result in the exchange of BGP (unsigned) UPDATE messages. It is RECOMMENDED that an implementation log the failure to properly negotiate a BGPsec session. Also, an implementation MUST have the ability to prevent a BGP session from being established if configured to only use BGPsec.
第2.2节描述了建立支持BGPsec的对等会话所需的协商。不仅必须交换（并商定）BGPsec能力，还必须交换相同AFI的BGP多协议扩展[RFC4760]和4字节AS能力[RFC6793]。未能正确协商BGPsec会话（例如，由于缺少功能）仍可能导致交换BGP（未签名）更新消息。建议实施日志记录未能正确协商BGPsec会话的情况。此外，如果配置为仅使用BGPsec，则实现必须能够阻止建立BGP会话。
A peer that is an Internet Exchange Point (IXP) (i.e., route server) with a transparent AS is expected to set pCount=0 in its Secure_Path Segment while forwarding an UPDATE message to a peer (see Section 4.2). Clearly, such an IXP MUST configure its BGPsec router to set pCount=0 in its Secure_Path Segment. This also means that a BGPsec speaker MUST be configured so that it permits pCount=0 from an IXP peer. Two other cases where pCount is set to 0 are in the contexts of an AS confederation (see Section 4.3) and of AS migration [RFC8206]. In these two cases, pCount=0 is set and accepted within the same AS (albeit the AS has two different identities). Note that
作为互联网交换点（IXP）（即路由服务器）的对等方，在将更新消息转发给对等方时，其安全路径段中的pCount=0应设置为透明（见第4.2节）。显然，这样的IXP必须将其BGPsec路由器配置为在其安全路径段中设置pCount=0。这也意味着必须对BGPsec扬声器进行配置，以便它允许来自IXP对等机的pCount=0。pCount设置为0的另外两种情况是在AS联盟（见第4.3节）和AS迁移[RFC8206]的上下文中。在这两种情况下，在同一AS中设置并接受pCount=0（尽管AS有两个不同的标识）。注意
if a BGPsec speaker does not expect a peer AS to set its pCount=0 and if an UPDATE message received from that peer violates this, then the UPDATE message MUST be considered to be in error (see the list of checks in Section 5.2). See Section 8.4 for a discussion of security considerations concerning pCount=0.
如果BGPsec演讲者不希望对等方AS将其pCount设置为0，并且如果从该对等方接收到的更新消息违反了这一点，则必须将更新消息视为错误（参见第5.2节中的检查列表）。有关pCount=0的安全注意事项的讨论，请参见第8.4节。
During the validation of a BGPsec UPDATE message, route processor performance speedup can be achieved by incorporating the following observations. An UPDATE message is deemed 'Valid' if at least one of the Signature_Blocks is marked as 'Valid' (see Section 5.2). Therefore, if an UPDATE message contains two Signature_Blocks and the first one verified is found 'Valid', then the second Signature_Block does not have to be verified. And if the UPDATE message is chosen for best path, then the BGPsec speaker adds its signature (generated with the respective algorithm) to each of the two Signature_Blocks and forwards the UPDATE message. Also, a BGPsec UPDATE message is deemed 'Not Valid' if at least one signature in each of the Signature_Blocks is invalid. This principle can also be used for route processor workload savings, i.e., the verification for a Signature_Block terminates early when the first invalid signature is encountered.
在验证BGPsec更新消息期间，通过结合以下观察结果，可以实现路由处理器性能加速。如果至少有一个签名块被标记为“有效”，则更新消息被视为“有效”（见第5.2节）。因此，如果更新消息包含两个签名块，并且第一个已验证的签名块被发现为“有效”，则第二个签名块不必验证。如果更新消息被选择为最佳路径，那么BGPsec演讲者将其签名（使用各自的算法生成）添加到两个签名块中的每一个，并转发更新消息。此外，如果每个签名块中至少有一个签名无效，则BGPsec更新消息被视为“无效”。该原理还可用于路由处理器工作负载的节省，即，当遇到第一个无效签名时，签名块的验证提前终止。
Many signature algorithms are non-deterministic. That is, many signature algorithms will produce different signatures each time they are run (even when they are signing the same data with the same key). Therefore, if a BGPsec router receives a BGPsec UPDATE message from a peer and later receives a second BGPsec UPDATE message from the same peer for the same prefix with the same Secure_Path and SKIs, the second UPDATE message MAY differ from the first UPDATE message in the signature fields (for a non-deterministic signature algorithm). However, the two sets of signature fields will not differ if the sender caches and reuses the previous signature. For a deterministic signature algorithm, the signature fields MUST be identical between the two UPDATE messages. On the basis of these observations, an implementation MAY incorporate optimizations in update validation processing.
许多签名算法是不确定的。也就是说，许多签名算法在每次运行时都会产生不同的签名（即使它们使用相同的密钥对相同的数据进行签名）。因此，如果BGPsec路由器从对等方接收BGPsec更新消息，并且随后从同一对等方接收具有相同安全路径和SKI的相同前缀的第二BGPsec更新消息，则第二更新消息在签名字段中可能不同于第一更新消息（对于非确定性签名算法）。但是，如果发送方缓存并重用以前的签名，则这两组签名字段不会有所不同。对于确定性签名算法，两条更新消息之间的签名字段必须相同。基于这些观察结果，一个实现可以在更新验证处理中包含优化。
It is possible that a stub customer of an ISP employs a private AS number. Such a stub customer cannot publish a ROA in the Global RPKI for the private AS number and the prefixes that they use. Also, the Global RPKI cannot support private AS numbers (i.e., BGPsec speakers in private ASes cannot be issued router certificates in the Global
ISP的存根客户可能会使用私人AS号码。这样的存根客户无法在全局RPKI中发布其使用的专用AS编号和前缀的ROA。此外，全局RPKI不能支持专用AS号码（即，专用ASE中的BGPsec扬声器不能在全局ASE中获得路由器证书）
RPKI). For interactions between the stub customer (with the private AS number) and the ISP, the following two scenarios are possible:
RPKI）。对于存根客户（使用专用AS号码）和ISP之间的交互，可能存在以下两种情况：
1. The stub customer sends an unsigned BGP UPDATE message for a prefix to the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose to propagate the prefix to its non-BGPsec and BGPsec peers. If so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the private AS number and then (a) re-originate the prefix without any signatures towards its non-BGPsec peer and (b) re-originate the prefix including its own signature towards its BGPsec peer. In both cases (i.e., (a) and (b)), the prefix MUST have a ROA in the Global RPKI authorizing the ISP's AS to originate it.
1. 存根客户向ISP的AS发送前缀的未签名BGP更新消息。ISP AS中的边缘BGPsec扬声器可以选择将前缀传播到其非BGPsec和BGPsec对等方。如果是这样，ISP的edge BGPsec扬声器必须使用专用AS编号剥离AS_路径，然后（a）向其非BGPsec对等方重新发起前缀，而无任何签名，（b）向其BGPsec对等方重新发起前缀，包括其自己的签名。在这两种情况下（即，（a）和（b）），前缀必须在全局RPKI中具有ROA，授权ISP的AS发起它。
2. The ISP and the stub customer may use a local RPKI repository (using a mechanism such as one of the mechanisms described in [SLURM]). Then, there can be a ROA for the prefix originated by the stub AS, and the eBGP speaker in the stub AS can be a BGPsec speaker having a router certificate, albeit the ROA and router certificate are valid only locally. With this arrangement, the stub AS sends a signed UPDATE message for the prefix to the ISP's AS. An edge BGPsec speaker in the ISP's AS validates the UPDATE message, using RPKI data based on the local RPKI view. Further, it may choose to propagate the prefix to its non-BGPsec and BGPsec peers. If so, the ISP's edge BGPsec speaker MUST strip the Secure_Path and the Signature Segment received from the stub AS with the private AS number and then (a) re-originate the prefix without any signatures towards its non-BGPsec peer and (b) re-originate the prefix including its own signature towards its BGPsec peer. In both cases (i.e., (a) and (b)), the prefix MUST have a ROA in the Global RPKI authorizing the ISP's AS to originate it.
2. ISP和存根客户可以使用本地RPKI存储库（使用[SLURM]中描述的机制之一）。然后，对于由存根AS发起的前缀可以存在ROA，并且存根AS中的eBGP扬声器可以是具有路由器证书的BGPsec扬声器，尽管ROA和路由器证书仅在本地有效。通过这种安排，存根AS向ISP的AS发送前缀的签名更新消息。ISP AS中的edge BGPsec扬声器使用基于本地RPKI视图的RPKI数据验证更新消息。此外，它可以选择将前缀传播到其非BGPsec和BGPsec对等方。如果是这样，ISP的edge BGPsec扬声器必须将安全路径和从存根AS接收到的签名段与专用AS号剥离，然后（a）向其非BGPsec对等方重新发起前缀，而不带任何签名，以及（b）向其BGPsec对等方重新发起前缀，包括其自身签名。在这两种情况下（即，（a）和（b）），前缀必须在全局RPKI中具有ROA，授权ISP的AS发起它。
It is possible that private AS numbers are used in an AS confederation [RFC5065]. The BGPsec protocol requires that when a BGPsec UPDATE message propagates through a confederation, each Member-AS that forwards it to a peer Member-AS MUST sign the UPDATE message (see Section 4.3). However, the Global RPKI cannot support private AS numbers. In order for the BGPsec speakers in Member-ASes with private AS numbers to have digital certificates, there MUST be a mechanism in place in the confederation that allows the establishment of a local, customized view of the RPKI, augmenting the Global RPKI repository data as needed. Since this mechanism (for augmenting and maintaining a local image of RPKI data) operates locally within an AS or AS confederation, it need not be standard based. However, a standard-based mechanism can be used (see [SLURM]). Recall that in order to prevent exposure of the internals of AS confederations, a
AS联合会[RFC5065]中可能使用专用AS号码。BGPsec协议要求，当BGPsec更新消息通过联盟传播时，将其转发给对等成员AS的每个成员AS必须签署更新消息（参见第4.3节）。但是，全局RPKI不能支持私有AS编号。为了让拥有私人AS号码的成员ASE中的BGPsec演讲者拥有数字证书，联盟中必须有一种机制，允许建立RPKI的本地定制视图，根据需要增加全局RPKI存储库数据。由于该机制（用于增强和维护RPKI数据的本地映像）在AS或AS联盟内本地运行，因此不需要基于标准。但是，可以使用基于标准的机制（参见[SLURM]）。回想一下，为了防止暴露AS联盟的内部
BGPsec speaker exporting to a non-member removes all intra-confederation Secure_Path Segments and Signatures (see Section 4.3).
BGPsec扬声器导出到非成员将删除所有联邦内部安全路径段和签名（见第4.3节）。
The deployment structure, technologies, and best practices concerning Global RPKI data to reach routers (via local RPKI caches) are described in [RFC6810], [RFC8210], [RFC8181], [RFC7115], [RFC8207], and [RFC8182]. For example, Serial-Number-based incremental update mechanisms are used for efficient transfer of just the data records that have changed since the last update [RFC6810] [RFC8210]. The update notification file is used by Relying Parties (RPs) to discover whether any changes exist between the state of the Global RPKI repository and the RP's cache [RFC8182]. The notification describes the location of (1) the files containing the snapshot and (2) incremental deltas, which can be used by the RP to synchronize with the repository. Making use of these technologies and best practices results in enabling robustness, efficiency, and better security for the BGPsec routers and RPKI caches in terms of the flow of RPKI data from repositories to RPKI caches to routers. With these mechanisms, it is believed that an attacker wouldn't be able to meaningfully correlate RPKI data flows with BGPsec RP (or router) actions, thus avoiding attacks that may attempt to determine the set of ASes interacting with an RP via the interactions between the RP and RPKI servers.
[RFC6810]、[RFC8210]、[RFC8181]、[RFC7115]、[RFC8207]和[RFC8182]中描述了有关全局RPKI数据到达路由器（通过本地RPKI缓存）的部署结构、技术和最佳实践。例如，基于序列号的增量更新机制仅用于有效传输自上次更新[RFC6810][RFC8210]以来已更改的数据记录。依赖方（RP）使用更新通知文件来发现全局RPKI存储库的状态和RP的缓存之间是否存在任何更改[RFC8182]。通知描述了（1）包含快照的文件和（2）增量增量增量增量的位置，RP可以使用这些增量增量增量与存储库同步。利用这些技术和最佳实践，就RPKI数据从存储库到RPKI缓存再到路由器的流动而言，BGPsec路由器和RPKI缓存能够实现健壮性、效率和更好的安全性。有了这些机制，攻击者将无法有意义地将RPKI数据流与BGPsec RP（或路由器）操作关联起来，从而避免可能试图通过RP和RPKI服务器之间的交互确定与RP交互的ASE集的攻击。
During Graceful Restart (GR), restarting and receiving BGPsec speakers MUST follow the procedures specified in [RFC4724] for restarting and receiving BGP speakers, respectively. In particular, the behavior of retaining the forwarding state for the routes in the Loc-RIB [RFC4271] and marking them as stale, as well as not differentiating between stale routing information and other information during forwarding, will be the same as the behavior specified in [RFC4724].
在正常重新启动（GR）过程中，重新启动和接收BGPsec扬声器必须分别按照[RFC4724]中规定的程序重新启动和接收BGP扬声器。特别是，在Loc RIB[RFC4271]中保留路由的转发状态并将其标记为陈旧，以及在转发期间不区分陈旧路由信息和其他信息的行为将与[RFC4724]中规定的行为相同。
The Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 is used for signing UPDATE messages in BGPsec [RFC8208]. For ECDSA, it is stated in Section 6.3 of [FIPS186-4] that a new secret random number "k" shall be generated prior to the generation of each digital signature. A high-entropy random bit generator (RBG) must be used for generating "k", and any potential bias in the "k" generation algorithm must be mitigated (see the methods described in [FIPS186-4] and [SP800-90A]).
带有曲线P-256的椭圆曲线数字签名算法（ECDSA）用于签署BGPsec[RFC8208]中的更新消息。对于ECDSA，[FIPS186-4]第6.3节规定，在生成每个数字签名之前，应生成一个新的秘密随机数“k”。必须使用高熵随机位发生器（RBG）生成“k”，并且必须缓解“k”生成算法中的任何潜在偏差（参见[FIPS186-4]和[SP800-90A]中描述的方法）。
What will migration from BGP to BGPsec look like? What are the benefits for the first adopters? Initially, small groups of contiguous ASes would be doing BGPsec. There would possibly be one or more such groups in different geographic regions of the global Internet. Only the routes originated within each group and propagated within its borders would get the benefits of cryptographic AS path protection. As BGPsec adoption grows, each group grows in size, and eventually they join together to form even larger BGPsec-capable groups of contiguous ASes. The benefit for early adopters starts with AS path security within the regions of contiguous ASes spanned by their respective groups. Over time, they would see those regions of contiguous ASes grow much larger.
从BGP迁移到BGPsec会是什么样子？对第一批采用者有什么好处？最初，一小群相邻的ASE将进行BGPsec。在全球互联网的不同地理区域可能会有一个或多个这样的群体。只有源于每个组并在其边界内传播的路由才能获得加密作为路径保护的好处。随着BGPsec采用率的增长，每个组的规模都在增长，最终它们结合在一起，形成更大的BGPsec能力组的连续ASE。早期采用者的好处首先是其各自组所跨越的相邻ASE区域内的AS路径安全。随着时间的推移，他们会看到这些相邻的ASE区域变得更大。
During partial deployment, if an AS in the path doesn't support BGPsec, then BGP goes back to traditional mode, i.e., BGPsec UPDATE messages are converted to unsigned UPDATE messages before forwarding to that AS (see Section 4.4). At this point, the assurance that the UPDATE message propagated via the sequence of ASes listed is lost. In other words, for the BGPsec routers residing in the ASes starting from the origin AS to the AS before the one not supporting BGPsec, the assurance can still be provided, but not beyond that (for the UPDATE messages in consideration).
在部分部署期间，如果路径中的AS不支持BGPsec，则BGP将返回到传统模式，即BGPsec更新消息在转发到该AS之前转换为未签名的更新消息（参见第4.4节）。此时，无法保证通过列出的ASE序列传播的更新消息。换句话说，对于驻留在ASE中的BGPsec路由器，从源AS到不支持BGPsec的AS之前的AS，仍然可以提供保证，但不能超过此保证（对于考虑中的更新消息）。
For a discussion of the BGPsec threat model and related security considerations, please see RFC 7132 [RFC7132].
有关BGPsec威胁模型和相关安全注意事项的讨论，请参阅RFC 7132[RFC7132]。
When used in conjunction with origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]), a BGPsec speaker who receives a valid BGPsec UPDATE message containing a route advertisement for a given prefix is provided with the following security guarantees:
当与来源验证（参见RFC 6483[RFC6483]和RFC 6811[RFC6811]）一起使用时，接收到包含给定前缀的路由公告的有效BGPsec更新消息的BGPsec扬声器具有以下安全保证：
o The origin AS number corresponds to an AS that has been authorized, in the RPKI, by the IP address space holder to originate route advertisements for the given prefix.
o 源AS编号对应于IP地址空间持有者在RPKI中授权的AS，以发起给定前缀的路由广告。
o For each AS in the path, a BGPsec speaker authorized by the holder of the AS number intentionally chose (in accordance with local policy) to propagate the route advertisement to the subsequent AS in the path.
o 对于路径中的每个AS，AS号码持有人授权的BGPsec演讲者有意选择（根据当地政策）将路由广告传播到路径中的后续AS。
That is, the recipient of a valid BGPsec UPDATE message is assured that the UPDATE message propagated via the sequence of ASes listed in the Secure_Path portion of the BGPsec_PATH attribute. (It should be noted that BGPsec does not offer any guarantee that the data packets would flow along the indicated path; it only guarantees that the BGP UPDATE message conveying the path indeed propagated along the indicated path.) Furthermore, the recipient is assured that this path terminates in an AS that has been authorized by the IP address space holder as a legitimate destination for traffic to the given prefix.
也就是说，有效BGPsec更新消息的接收者确保更新消息通过BGPsec_路径属性的安全_路径部分中列出的ASE序列传播。（需要注意的是，BGPsec不保证数据包沿着指示路径流动；它只保证传输路径的BGP更新消息确实沿着指示路径传播。）此外，接收者确信该路径终止于一个AS，该AS已被IP地址空间持有者授权为到给定前缀的通信的合法目的地。
Note that although BGPsec provides a mechanism for an AS to validate that a received UPDATE message has certain security properties, the use of such a mechanism to influence route selection is completely a matter of local policy. Therefore, a BGPsec speaker can make no assumptions about the validity of a route received from an external (eBGP) BGPsec peer. That is, a compliant BGPsec peer may (depending on the local policy of the peer) send UPDATE messages that fail the validity test in Section 5. Thus, a BGPsec speaker MUST completely validate all BGPsec UPDATE messages received from external peers. (Validation of UPDATE messages received from internal peers is also a matter of local policy; see Section 5.)
请注意，尽管BGPsec为AS提供了一种机制来验证接收到的更新消息是否具有某些安全属性，但使用这种机制来影响路由选择完全是本地策略的问题。因此，BGPsec演讲者不能对从外部（eBGP）BGPsec对等方接收的路由的有效性做出任何假设。也就是说，符合BGPsec的对等方可以（取决于对等方的本地策略）发送未通过第5节中有效性测试的更新消息。因此，BGPsec发言人必须完全验证从外部对等方接收的所有BGPsec更新消息。（验证从内部对等方收到的更新消息也是本地政策的问题；请参见第5节。）
There may be cases where a BGPsec speaker deems 'Valid' (as per the validation algorithm in Section 5.2) a BGPsec UPDATE message that contains both a 'Valid' and a 'Not Valid' Signature_Block. That is, the UPDATE message contains two sets of signatures corresponding to two algorithm suites, and one set of signatures verifies correctly and the other set of signatures fails to verify. In this case, the protocol specifies that a BGPsec speaker choosing to propagate the route advertisement in such an UPDATE message MUST add its signature to each of the Signature_Blocks (see Section 4.2). Thus, the BGPsec speaker creates a signature using both algorithm suites and creates a new UPDATE message that contains both the 'Valid' and the 'Not Valid' set of signatures (from its own vantage point).
在某些情况下，BGPsec发言人认为包含“有效”和“无效”签名块的BGPsec更新消息“有效”（根据第5.2节中的验证算法）。也就是说，更新消息包含两组对应于两个算法套件的签名，其中一组签名验证正确，另一组签名验证失败。在这种情况下，协议规定，选择在此类更新消息中传播路由广告的BGPsec演讲者必须将其签名添加到每个签名块（参见第4.2节）。因此，BGPsec演讲者使用两种算法套件创建一个签名，并创建一个新的更新消息，其中包含“有效”和“无效”签名集（从其自身的有利位置）。
To understand the reason for such a design decision, consider the case where the BGPsec speaker receives an UPDATE message with both a set of algorithm A signatures that are 'Valid' and a set of algorithm B signatures that are 'Not Valid'. In such a case, it is possible (perhaps even likely, depending on the state of the algorithm transition) that some of the BGPsec speaker's peers (or other entities further downstream in the BGP topology) do not support algorithm A. Therefore, if the BGPsec speaker were to remove the 'Not Valid' set of signatures corresponding to algorithm B, such entities would treat the message as though it were unsigned. By
为了理解这样的设计决定的原因，考虑BGPSEC说话者接收一组更新消息的情况，该算法包括一组算法“有效”签名和一组“无效”的算法B签名。在这种情况下，可能（甚至可能，取决于算法转换的状态）一些BGPsec演讲者的对等方（或BGP拓扑中更下游的其他实体）不支持算法a。因此，如果BGPsec演讲者要删除与算法B相对应的“无效”签名集，这些实体会将消息视为未签名。通过
including the 'Not Valid' set of signatures when propagating a route advertisement, the BGPsec speaker ensures that downstream entities have as much information as possible to make an informed opinion about the validation status of a BGPsec UPDATE message.
在传播路由公告时包括“无效”签名集，BGPsec发言人确保下游实体拥有尽可能多的信息，以便对BGPsec更新消息的验证状态发表知情意见。
Note also that during a period of partial BGPsec deployment, a downstream entity might reasonably treat unsigned messages differently from BGPsec UPDATE messages that contain a single set of 'Not Valid' signatures. That is, by removing the set of 'Not Valid' signatures, the BGPsec speaker might actually cause a downstream entity to 'upgrade' the status of a route advertisement from 'Not Valid' to unsigned. Finally, note that in the above scenario, the BGPsec speaker might have deemed algorithm A signatures 'Valid' only because of some issue with the RPKI state local to its AS (for example, its AS might not yet have obtained a Certificate Revocation List (CRL) indicating that a key used to verify an algorithm A signature belongs to a newly revoked certificate). In such a case, it is highly desirable for a downstream entity to treat the UPDATE message as 'Not Valid' (due to the revocation) and not as 'unsigned' (which would happen if the 'Not Valid' Signature_Blocks were removed en route).
还请注意，在部分BGPsec部署期间，下游实体可能会合理地将未签名消息与包含一组“无效”签名的BGPsec更新消息区别对待。也就是说，通过删除一组“无效”签名，BGPsec说话人实际上可能会导致下游实体将路由公告的状态从“无效”升级为“未签名”。最后，请注意，在上述场景中，BGPsec演讲者可能认为算法A签名“有效”，只是因为其AS的本地RPKI状态存在一些问题（例如，其AS可能尚未获得证书吊销列表（CRL）表示用于验证算法的密钥（签名属于新吊销的证书）。在这种情况下，下游实体非常希望将更新消息视为“无效”（由于撤销），而不是“未签名”（如果在途中删除了“无效”签名块，则会发生这种情况）。
A similar argument applies to the case where a BGPsec speaker (for some reason, such as a lack of viable alternatives) selects as its best path (to a given prefix) a route obtained via a 'Not Valid' BGPsec UPDATE message. In such a case, the BGPsec speaker should propagate a signed BGPsec UPDATE message, adding its signature to the 'Not Valid' signatures that already exist. Again, this is to ensure that downstream entities are able to make an informed decision and not erroneously treat the route as unsigned. It should also be noted that due to possible differences in RPKI data observed at different vantage points in the network, a BGPsec UPDATE message deemed 'Not Valid' at an upstream BGPsec speaker may be deemed 'Valid' by another BGP speaker downstream.
类似的论点适用于BGPsec演讲者（出于某些原因，例如缺乏可行的替代方案）选择通过“无效”BGPsec更新消息获得的路由作为其最佳路径（到给定前缀）的情况。在这种情况下，BGPsec发言人应传播已签名的BGPsec更新消息，将其签名添加到已存在的“无效”签名中。同样，这是为了确保下游实体能够做出明智的决定，并且不会错误地将路线视为未签名。还应注意，由于在网络中不同有利位置观察到的RPKI数据可能存在差异，上游BGPsec说话人认为“无效”的BGPsec更新消息可能被下游的另一个BGP说话人认为“有效”。
Indeed, when a BGPsec speaker signs an outgoing UPDATE message, it is not attesting to a belief that all signatures prior to its own signature are valid. Instead, it is merely asserting that:
事实上，当BGPsec演讲者在传出的更新消息上签名时，它并不能证明其自己签名之前的所有签名都是有效的。相反，它只是断言：
o The BGPsec speaker received the given route advertisement with the indicated prefix, AFI, SAFI, and Secure_Path, and
o BGPsec演讲者接收到具有指示前缀、AFI、SAFI和安全路径的给定路由广告，以及
o The BGPsec speaker chose to propagate an advertisement for this route to the peer (implicitly) indicated by the 'Target AS Number'.
o BGPsec演讲者选择将此路由的广告传播到由“Target AS Number”指示的对等方（隐式）。
The BGPsec update validation procedure is a potential target for denial-of-service attacks against a BGPsec speaker. The mitigation of denial-of-service attacks that are specific to the BGPsec protocol is considered here.
BGPsec更新验证过程是针对BGPsec扬声器的拒绝服务攻击的潜在目标。此处考虑了特定于BGPsec协议的拒绝服务攻击的缓解。
To mitigate the effectiveness of such denial-of-service attacks, BGPsec speakers should implement an update validation algorithm that performs expensive checks (e.g., signature verification) after performing checks that are less expensive (e.g., syntax checks). The validation algorithm specified in Section 5.2 was chosen so as to perform checks that are likely to be expensive after checks that are likely to be inexpensive. However, the relative cost of performing required validation steps may vary between implementations, and thus the algorithm specified in Section 5.2 may not provide the best denial-of-service protection for all implementations.
为降低此类拒绝服务攻击的有效性，BGPsec演讲者应实施更新验证算法，在执行较便宜的检查（如语法检查）后执行昂贵的检查（如签名验证）。选择第5.2节中规定的验证算法，以便在可能便宜的检查之后执行可能昂贵的检查。但是，执行所需验证步骤的相对成本可能因实施而异，因此第5.2节中指定的算法可能无法为所有实施提供最佳拒绝服务保护。
Additionally, sending UPDATE messages with very long AS paths (and hence a large number of signatures) is a potential mechanism to conduct denial-of-service attacks. For this reason, it is important that an implementation of the validation algorithm stops attempting to verify signatures as soon as an invalid signature is found. (This ensures that long sequences of invalid signatures cannot be used for denial-of-service attacks.) Furthermore, implementations can mitigate such attacks by only performing validation on UPDATE messages that, if valid, would be selected as the best path. That is, if an UPDATE message contains a route that would lose out in best path selection for other reasons (e.g., a very long AS path), then it is not necessary to determine the BGPsec-validity status of the route.
此外，使用非常长的AS路径（以及大量签名）发送更新消息是进行拒绝服务攻击的潜在机制。因此，验证算法的实现必须在发现无效签名后立即停止验证签名的尝试。（这确保了长序列的无效签名不能用于拒绝服务攻击。）此外，实现可以通过仅对更新消息执行验证来减轻此类攻击，如果更新消息有效，将被选为最佳路径。也就是说，如果更新消息包含因其他原因（例如，非常长的AS路径）而在最佳路径选择中丢失的路由，则无需确定路由的BGPsec有效性状态。
The mechanism of setting the pCount field to 0 is included in this specification to enable route servers in the control path to participate in BGPsec without increasing the length of the AS path. Two other scenarios where pCount=0 is utilized are in the contexts of an AS confederation (see Section 4.3) and of AS migration [RFC8206]. In these two scenarios, pCount=0 is set and also accepted within the same AS (albeit the AS has two different identities). However, entities other than route servers, confederation ASes, or migrating ASes could conceivably use this mechanism (set the pCount to 0) to attract traffic (by reducing the length of the AS path) illegitimately. This risk is largely mitigated if every BGPsec speaker follows the operational guidance in Section 7.2 for configuration for setting pCount=0 and/or accepting pCount=0 from a peer. However, note that a recipient of a BGPsec UPDATE message
本规范包含将pCount字段设置为0的机制，以使控制路径中的路由服务器能够参与BGPsec，而不增加AS路径的长度。使用pCount=0的另外两种情况是在AS联盟（见第4.3节）和AS迁移[RFC8206]的上下文中。在这两个场景中，设置了pCount=0，并且在同一AS中也接受它（尽管AS有两个不同的标识）。然而，除了路由服务器、联盟ASE或迁移ASE之外的实体可以想象使用此机制（将pCount设置为0）非法吸引流量（通过减少AS路径的长度）。如果每个BGPsec演讲者都遵循第7.2节中关于设置pCount=0和/或从对等方接受pCount=0的配置的操作指南，则该风险将大大降低。但是，请注意，BGPsec更新消息的收件人
within which an upstream entity two or more hops away has set pCount to 0 is unable to verify for themselves whether pCount was set to 0 legitimately.
如果两个或多个跃点之外的上游实体已将pCount设置为0，则无法自行验证pCount是否合法设置为0。
There is a possibility of passing a BGPsec UPDATE message via tunneling between colluding ASes. For example, let's say that AS-X does not peer with AS-Y but colludes with AS-Y, and it signs and sends a BGPsec UPDATE message to AS-Y by tunneling. AS-Y can then further sign and propagate the BGPsec UPDATE message to its peers. It is beyond the scope of the BGPsec protocol to detect this form of malicious behavior. BGPsec is designed to protect messages sent within BGP (i.e., within the control plane) -- not when the control plane is bypassed.
有可能通过共谋ASE之间的隧道传递BGPsec更新消息。例如，假设AS-X不与AS-Y对等，而是与AS-Y共谋，它通过隧道方式签名并向AS-Y发送BGPsec更新消息。AS-Y随后可以进一步签名并将BGPsec更新消息传播给其对等方。检测这种形式的恶意行为超出了BGPsec协议的范围。BGPsec设计用于保护在BGP内（即控制平面内）发送的消息，而不是在绕过控制平面时。
A variant of the collusion by tunneling mentioned above can happen in the context of AS confederations. When a BGPsec router (outside of a confederation) is forwarding an UPDATE message to a Member-AS in the confederation, it signs the UPDATE message to the public AS number of the confederation and not to the member's AS number (see Section 4.3). The Member-AS can tunnel the signed UPDATE message to another Member-AS as received (i.e., without adding a signature). The UPDATE message can then be propagated using BGPsec to other confederation members or to BGPsec neighbors outside of the confederation. This kind of operation is possible, but no grave security or reachability compromise is feared for the following reasons:
上述隧道共谋的一种变体可能发生在AS联盟的情况下。当BGPsec路由器（联盟外）向联盟内的成员转发更新消息时，它会将更新消息作为联盟的编号向公众签名，而不是向成员的AS编号签名（见第4.3节）。成员AS可以将已签名的更新消息通过隧道传输到接收到的另一个成员（即，不添加签名）。然后，可以使用BGPsec将更新消息传播到其他联盟成员或联盟外的BGPsec邻居。这种操作是可能的，但由于以下原因，不存在严重的安全或可达性问题：
o The confederation members belong to one organization, and strong internal trust is expected.
o 邦联成员属于一个组织，预计会有强大的内部信任。
o Recall that the signatures that are internal to the confederation MUST be removed prior to forwarding the UPDATE message to an outside BGPsec router (see Section 4.3).
o 回想一下，在将更新消息转发到外部BGPsec路由器之前，必须删除联邦内部的签名（参见第4.3节）。
BGPsec does not provide protection against attacks at the transport layer. As with any BGP session, an adversary on the path between a BGPsec speaker and its peer is able to perform attacks such as modifying valid BGPsec UPDATE messages to cause them to fail validation, injecting (unsigned) BGP UPDATE messages without BGPsec_PATH attributes, injecting BGPsec UPDATE messages with BGPsec_PATH attributes that fail validation, or causing the peer to tear down the BGP session. The use of BGPsec does nothing to increase the power of an on-path adversary -- in particular, even an on-path adversary cannot cause a BGPsec speaker to believe that a BGPsec-invalid route is valid. However, as with any BGP session, BGPsec sessions SHOULD be protected by appropriate transport security mechanisms (see the Security Considerations section in [RFC4271]).
BGPsec不提供针对传输层攻击的保护。与任何BGP会话一样，BGPsec扬声器与其对等方之间路径上的对手能够执行攻击，例如修改有效的BGPsec更新消息以使其验证失败，注入（未签名）不带BGPsec_路径属性的BGP更新消息，使用验证失败的BGPsec_路径属性注入BGPsec更新消息，或导致对等方中断BGP会话。使用BGPsec不会增加路径上对手的力量——特别是，即使是路径上对手也不能让BGPsec演讲者相信BGPsec无效路由是有效的。但是，与任何BGP会话一样，BGPsec会话应通过适当的传输安全机制进行保护（请参阅[RFC4271]中的安全注意事项部分）。
There is a possibility of replay attacks, defined as follows. In the context of BGPsec, a replay attack occurs when a malicious BGPsec speaker in the AS path suppresses a prefix withdrawal (implicit or explicit). Further, a replay attack is said to occur also when a malicious BGPsec speaker replays a previously received BGPsec announcement for a prefix that has since been withdrawn. The mitigation strategy for replay attacks involves router certificate rollover; please see [ROLLOVER] for details.
存在重播攻击的可能性，定义如下。在BGPsec上下文中，当AS路径中的恶意BGPsec说话者抑制前缀提取（隐式或显式）时，会发生重播攻击。此外，当恶意BGPsec说话者重放先前接收到的BGPsec声明以获取后来被撤回的前缀时，据说也会发生重放攻击。重放攻击的缓解策略包括路由器证书翻转；有关详细信息，请参见[滚动]。
IANA has registered a new BGP capability described in Section 2.1 in the "Capability Codes" registry's "IETF Review" range [RFC8126]. The description for the new capability is "BGPsec Capability". This document is the reference for the new capability.
IANA已在“能力代码”注册中心的“IETF审查”范围[RFC8126]中注册了第2.1节所述的新BGP能力。新能力的描述为“BGPsec能力”。本文档是新功能的参考。
IANA has also registered a new path attribute described in Section 3 in the "BGP Path Attributes" registry. The code for this new attribute is "BGPsec_PATH". This document is the reference for the new attribute.
IANA还在“BGP路径属性”注册表中注册了第3节所述的新路径属性。这个新属性的代码是“BGPsec_PATH”。此文档是新属性的参考。
IANA has defined the "BGPsec Capability" registry in the "Resource Public Key Infrastructure (RPKI)" group. The registry is as shown in Figure 10, with values assigned from Section 2.1:
IANA在“资源公钥基础设施（RPKI）”组中定义了“BGPsec能力”注册表。注册表如图10所示，其值来自第2.1节：
+------+------------------------------------+------------+
| Bits | Field | Reference |
+------+------------------------------------+------------+
| 0-3 | Version | [RFC8205] |
| | Value = 0x0 | |
+------+------------------------------------+------------+
| 4 | Direction | [RFC8205] |
| |(Both possible values 0 and 1 are | |
| | fully specified by this RFC) | |
+------+------------------------------------+------------+
| 5-7 | Unassigned | [RFC8205] |
| | Value = 000 (in binary) | |
+------+------------------------------------+------------+
+------+------------------------------------+------------+
| Bits | Field | Reference |
+------+------------------------------------+------------+
| 0-3 | Version | [RFC8205] |
| | Value = 0x0 | |
+------+------------------------------------+------------+
| 4 | Direction | [RFC8205] |
| |(Both possible values 0 and 1 are | |
| | fully specified by this RFC) | |
+------+------------------------------------+------------+
| 5-7 | Unassigned | [RFC8205] |
| | Value = 000 (in binary) | |
+------+------------------------------------+------------+
Figure 10: IANA Registry for BGPsec Capability
图10:BGPsec功能的IANA注册表
The Direction bit (fourth bit) has a value of either 0 or 1, and both values are fully specified by this document. Future Version values and future values of the Unassigned bits are assigned using the "Standards Action" registration procedures defined in RFC 8126 [RFC8126].
方向位（第四位）的值为0或1，这两个值均由本文档完全指定。使用RFC 8126[RFC8126]中定义的“标准操作”注册程序分配未分配位的未来版本值和未来值。
IANA has defined the "BGPsec_PATH Flags" registry in the "Resource Public Key Infrastructure (RPKI)" group. The registry is as shown in Figure 11, with one value assigned from Section 3.1:
IANA在“资源公钥基础设施（RPKI）”组中定义了“BGPsec_路径标志”注册表。注册表如图11所示，其中一个值来自第3.1节：
+------+-------------------------------------------+------------+
| Flag | Description | Reference |
+------+-------------------------------------------+------------+
| 0 | Confed_Segment | [RFC8205] |
| | Bit value = 1 means Flag set | |
| | (indicates Confed_Segment) | |
| | Bit value = 0 is default | |
+------+-------------------------------------------+------------+
| 1-7 | Unassigned | [RFC8205] |
| | Value: All 7 bits set to zero | |
+------+-------------------------------------------+------------+
+------+-------------------------------------------+------------+
| Flag | Description | Reference |
+------+-------------------------------------------+------------+
| 0 | Confed_Segment | [RFC8205] |
| | Bit value = 1 means Flag set | |
| | (indicates Confed_Segment) | |
| | Bit value = 0 is default | |
+------+-------------------------------------------+------------+
| 1-7 | Unassigned | [RFC8205] |
| | Value: All 7 bits set to zero | |
+------+-------------------------------------------+------------+
Figure 11: IANA Registry for BGPsec_PATH Flags Field
图11:BGPsec_路径标志字段的IANA注册表
Future values of the Unassigned bits are assigned using the "Standards Action" registration procedures defined in RFC 8126 [RFC8126].
未分配位的未来值使用RFC 8126[RFC8126]中定义的“标准操作”注册程序进行分配。
[IANA-AF] IANA, "Address Family Numbers", <https://www.iana.org/assignments/address-family-numbers>.
[IANA-AF]IANA，“地址系列编号”<https://www.iana.org/assignments/address-family-numbers>.
[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>.
[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>.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <https://www.rfc-editor.org/info/rfc4724>.
[RFC4724]Sangli，S.，Chen，E.，Fernando，R.，Scudder，J.，和Y.Rekhter，“BGP的优雅重启机制”，RFC 4724，DOI 10.17487/RFC4724，2007年1月<https://www.rfc-editor.org/info/rfc4724>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，DOI 10.17487/RFC4760，2007年1月<https://www.rfc-editor.org/info/rfc4760>.
[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>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC5492]Scudder，J.和R.Chandra，“BGP-4的能力广告”，RFC 5492，DOI 10.17487/RFC5492，2009年2月<https://www.rfc-editor.org/info/rfc5492>.
[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>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487]Huston，G.，Michaelson，G.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，DOI 10.17487/RFC6487，2012年2月<https://www.rfc-editor.org/info/rfc6487>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-editor.org/info/rfc6793>.
[RFC6793]Vohra，Q.和E.Chen，“BGP对四个八位组自治系统（AS）数字空间的支持”，RFC 6793，DOI 10.17487/RFC6793，2012年12月<https://www.rfc-editor.org/info/rfc6793>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.
[RFC7606]Chen，E.，Ed.，Scudder，J.，Ed.，Mohapatra，P.，和K.Patel，“BGP更新消息的修订错误处理”，RFC 7606，DOI 10.17487/RFC7606，2015年8月<https://www.rfc-editor.org/info/rfc7606>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>.
[RFC8208]Turner，S.和O.Borchert，“BGPsec算法、密钥格式和签名格式”，RFC 8208，DOI 10.17487/RFC8208，2017年9月<https://www.rfc-editor.org/info/rfc8208>.
[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>.
[Borchert] Borchert, O. and M. Baer, "Subject: Modification request: draft-ietf-sidr-bgpsec-protocol-14", message to the IETF SIDR WG Mailing List, 10 February 2016, <https://mailarchive.ietf.org/arch/msg/ sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5Mu>.
[Borchert]Borchert，O.和M.Baer，“主题：修改请求：草案-ietf-sidr-bgpsec-protocol-14”，发送给ietf sidr工作组邮件列表的信息，2016年2月10日<https://mailarchive.ietf.org/arch/msg/ sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5Mu>。
[FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", NIST FIPS Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS186-4]国家标准与技术研究所，“数字签名标准（DSS）”，NIST FIPS出版物186-4，DOI 10.6028/NIST.FIPS.186-42013年7月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>。
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, DOI 10.17487/RFC6472, December 2011, <https://www.rfc-editor.org/info/rfc6472>.
[RFC6472]Kumari，W.和K.Sriram，“在BGP中不使用AS_集和AS_CONFED_集的建议”，BCP 172，RFC 6472，DOI 10.17487/RFC6472，2011年12月<https://www.rfc-editor.org/info/rfc6472>.
[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>.
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, <https://www.rfc-editor.org/info/rfc6483>.
[RFC6483]Huston，G.和G.Michaelson，“使用资源证书公钥基础设施（PKI）和路由起源授权（ROA）验证路由起源”，RFC 6483，DOI 10.17487/RFC6483，2012年2月<https://www.rfc-editor.org/info/rfc6483>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.
[RFC6810]Bush，R.和R.Austein，“资源公钥基础设施（RPKI）到路由器协议”，RFC 6810，DOI 10.17487/RFC6810，2013年1月<https://www.rfc-editor.org/info/rfc6810>.
[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>.
[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods for Generating Key Identifiers Values", RFC 7093, DOI 10.17487/RFC7093, December 2013, <https://www.rfc-editor.org/info/rfc7093>.
[RFC7093]Turner，S.，Kent，S.，和J.Manger，“生成关键标识符值的其他方法”，RFC 7093，DOI 10.17487/RFC7093，2013年12月<https://www.rfc-editor.org/info/rfc7093>.
[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>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, <https://www.rfc-editor.org/info/rfc7132>.
[RFC7132]Kent，S.和A.Chi，“BGP路径安全的威胁模型”，RFC 7132，DOI 10.17487/RFC7132，2014年2月<https://www.rfc-editor.org/info/rfc7132>.
[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", July 2017, <https://www.rfc-editor.org/info/rfc8181>.
[RFC8181]Weiler，S.，Sonalker，A.，和R.Austein，“资源公钥基础设施（RPKI）的发布协议”，2017年7月<https://www.rfc-editor.org/info/rfc8181>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <https://www.rfc-editor.org/info/rfc8182>.
[RFC8182]Bruijnzeels，T.，Muravskiy，O.，Weber，B.，和R.Austein，“RPKI存储库增量协议（RRDP）”，RFC 8182，DOI 10.17487/RFC8182，2017年7月<https://www.rfc-editor.org/info/rfc8182>.
[RFC8206] George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, September 2017, <https://www.rfc-editor.org/info/rfc8206>.
[RFC8206]George，W.和S.Murphy，“BGPsec对自主系统（AS）迁移的考虑”，RFC 8206，DOI 10.17487/RFC8206，2017年9月<https://www.rfc-editor.org/info/rfc8206>.
[RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211, RFC 8207, DOI 10.17487/RFC8207, September 2017, <https://www.rfc-editor.org/info/rfc8207>.
[RFC8207]布什，R.，“BGPsec运营考虑”，BCP 211，RFC 8207，DOI 10.17487/RFC8207，2017年9月<https://www.rfc-editor.org/info/rfc8207>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/info/rfc8210>.
[RFC8210]Bush，R.和R.Austein，“资源公钥基础设施（RPKI）到路由器协议，版本1”，RFC 8210，DOI 10.17487/RFC8210，2017年9月<https://www.rfc-editor.org/info/rfc8210>.
[ROLLOVER] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", Work in Progress, draft-ietf-sidrops-bgpsec-rollover-01, August 2017.
[滚动]Weis，B.，Gagliano，R.，和K.Patel，“BGPsec路由器证书滚动”，正在进行的工作，草稿-ietf-sidrops-BGPsec-ROLLOVER-012017年8月。
[SLURM] Mandelberg, D., Ma, D., and T. Bruijnzeels, "Simplified Local internet nUmber Resource Management with the RPKI", Work in Progress, draft-ietf-sidr-slurm-04, March 2017.
[SLURM]Mandelberg，D.，Ma，D.，和T.Bruijnzeels，“使用RPKI简化本地互联网号码资源管理”，正在进行的工作，草稿-ietf-sidr-SLURM-042017年3月。
[SP800-90A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST SP 800-90A Rev 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-90Ar1.pdf>.
[SP800-90A]国家标准与技术研究所，“使用确定性随机位发生器生成随机数的建议”，NIST SP 800-90A第1版，DOI 10.6028/NIST.SP.800-90Ar1，2015年6月<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-90Ar1.pdf>。
Acknowledgements
致谢
The authors would like to thank Michael Baer, Oliver Borchert, David Mandelberg, Mehmet Adalier, Sean Turner, Wes George, Jeff Haas, Alvaro Retana, Nevil Brownlee, Matthias Waehlisch, Tim Polk, Russ Mundy, Wes Hardaker, Sharon Goldberg, Ed Kern, Doug Maughan, Pradosh Mohapatra, Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger Volk, and David Ward for their review, comments, and suggestions during the course of this work. Thanks are also due to many IESG reviewers whose comments greatly helped improve the clarity, accuracy, and presentation in the document.
作者要感谢迈克尔·贝尔、奥利弗·博尔切特、大卫·曼德尔伯格、默米特·阿达利尔、肖恩·特纳、韦斯·乔治、杰夫·哈斯、阿尔瓦罗·雷塔纳、内维尔·布朗利、马蒂亚斯·韦利希、蒂姆·波尔克、罗斯·蒙迪、韦斯·哈达克、沙龙·戈德伯格、埃德·克恩、道格·莫哈普拉、马克·雷诺兹、希瑟·席勒、杰森·席勒、鲁迪格·沃尔克、，以及David Ward在这项工作过程中的审查、评论和建议。感谢许多IESG评审员的评论，他们的评论极大地帮助提高了文档的清晰度、准确性和表达方式。
The authors particularly wish to acknowledge Oliver Borchert and Michael Baer for their review and suggestions [Borchert] concerning the sequence of octets to be hashed (Figures 8 and 9 in Sections 4.2 and 5.2, respectively). This was an important contribution based on their implementation experience.
作者特别希望感谢Oliver Borchert和Michael Baer，感谢他们对要散列的八位字节序列的审查和建议[Borchert]（第4.2节和第5.2节中的图8和图9）。根据他们的实施经验，这是一项重要贡献。
Contributors
贡献者
The following people have made significant contributions to this document and should be considered co-authors:
以下人员对本文件做出了重大贡献，应被视为共同作者：
Rob Austein Dragon Research Labs Email: sra@hactrn.net
Rob Austein Dragon研究实验室电子邮件：sra@hactrn.net
Steven Bellovin Columbia University Email: smb@cs.columbia.edu
Steven Bellovin哥伦比亚大学电子邮件：smb@cs.columbia.edu
Russ Housley Vigil Security Email: housley@vigilsec.com
Russ Housley守夜安全电子邮件：housley@vigilsec.com
Stephen Kent BBN Technologies Email: kent@alum.mit.edu
Stephen Kent BBN Technologies电子邮件：kent@alum.mit.edu
Warren Kumari Google Email: warren@kumari.net
Warren Kumari谷歌电子邮件：warren@kumari.net
Doug Montgomery USA National Institute of Standards and Technology Email: dougm@nist.gov
Doug Montgomery美国国家标准与技术研究所电子邮件：dougm@nist.gov
Chris Morrow Google, Inc. Email: morrowc@google.com
Chris Morrow Google，Inc.电子邮件：morrowc@google.com
Sandy Murphy SPARTA, Inc., a Parsons Company Email: sandy@tislabs.com
桑迪·墨菲·斯巴达公司，帕森斯公司电子邮件：sandy@tislabs.com
Keyur Patel Arrcus Email: keyur@arrcus.com
Keyur Patel Arrcus电子邮件：keyur@arrcus.com
John Scudder Juniper Networks Email: jgs@juniper.net
John Scudder Juniper Networks电子邮件：jgs@juniper.net
Samuel Weiler W3C/MIT Email: weiler@csail.mit.edu
Samuel Weiler W3C/MIT电子邮件：weiler@csail.mit.edu
Authors' Addresses
作者地址
Matthew Lepinski (editor) New College of Florida 5800 Bay Shore Road Sarasota, FL 34243 United States of America
Matthew Lepinski（编辑）美国佛罗里达州萨拉索塔湾海岸路5800号佛罗里达新学院，邮编34243
Email: mlepinski@ncf.edu
Email: mlepinski@ncf.edu
Kotikalapudi Sriram (editor) USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899 United States of America
Kotikalapudi Sriram（编辑）美国国家标准与技术研究所100 Bureau Drive Gaithersburg，MD 20899美利坚合众国
Email: kotikalapudi.sriram@nist.gov
Email: kotikalapudi.sriram@nist.gov