Independent Submission K. Sriram, Ed.
Request for Comments: 8374 USA NIST
Category: Informational April 2018
ISSN: 2070-1721
Independent Submission K. Sriram, Ed.
Request for Comments: 8374 USA NIST
Category: Informational April 2018
ISSN: 2070-1721
BGPsec Design Choices and Summary of Supporting Discussions
BGPsec设计选择和支持讨论总结
Abstract
摘要
This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification). The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETF SIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes.
本文件阐述了RFC 8205（BGPsec协议规范）初稿的设计原理。设计师需要平衡许多竞争因素，本文件列出了支持或反对每项设计选择的决策。本文件还简要总结了有助于决策过程的论点。在适当的情况下，本文件还提供了设计决策的简要说明，这些设计决策随着IETF SIDR工作组对规范的审查和更新而改变，并导致RFC 8205。这些注释强调了差异，并提供了有关这些设计变更的细节和基本原理的指针。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc8374.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8374.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................4
2. Creating Signatures and the Structure of BGPsec Update
Messages ........................................................5
2.1. Origin Validation Using ROAs ...............................5
2.2. Attributes Signed by an Originating AS .....................6
2.3. Attributes Signed by an Upstream AS ........................7
2.4. Attributes That Are Not Signed .............................8
2.5. Receiving Router Actions ...................................9
2.6. Prepending of ASes in AS Path .............................10
2.7. RPKI Data That Needs to Be Included in Updates ............10
3. Withdrawal Protection ..........................................11
3.1. Withdrawals Not Signed ....................................11
3.2. Signature Expire Time for Withdrawal Protection
(a.k.a. Mitigation of Replay Attacks) .....................12
3.3. Should Route Expire Time be Communicated in a
Separate Message? .........................................13
3.4. Effect of Expire Time Updates in BGPsec on RFD ............14
4. Signature Algorithms and Router Keys ...........................16
4.1. Signature Algorithms ......................................16
4.2. Agility of Signature Algorithms ...........................17
4.3. Sequential Aggregate Signatures ...........................18
4.4. Protocol Extensibility ....................................19
4.5. Key per Router (Rogue Router Problem) .....................20
4.6. Router ID .................................................20
5. Optimizations and Resource Sizing ..............................21
5.1. Update Packing and Repacking ..............................21
5.2. Signature per Prefix vs. Signature per Update .............22
5.3. Maximum BGPsec Update PDU Size ............................22
5.4. Temporary Suspension of Attestations and Validations ......23
1. Introduction ....................................................4
2. Creating Signatures and the Structure of BGPsec Update
Messages ........................................................5
2.1. Origin Validation Using ROAs ...............................5
2.2. Attributes Signed by an Originating AS .....................6
2.3. Attributes Signed by an Upstream AS ........................7
2.4. Attributes That Are Not Signed .............................8
2.5. Receiving Router Actions ...................................9
2.6. Prepending of ASes in AS Path .............................10
2.7. RPKI Data That Needs to Be Included in Updates ............10
3. Withdrawal Protection ..........................................11
3.1. Withdrawals Not Signed ....................................11
3.2. Signature Expire Time for Withdrawal Protection
(a.k.a. Mitigation of Replay Attacks) .....................12
3.3. Should Route Expire Time be Communicated in a
Separate Message? .........................................13
3.4. Effect of Expire Time Updates in BGPsec on RFD ............14
4. Signature Algorithms and Router Keys ...........................16
4.1. Signature Algorithms ......................................16
4.2. Agility of Signature Algorithms ...........................17
4.3. Sequential Aggregate Signatures ...........................18
4.4. Protocol Extensibility ....................................19
4.5. Key per Router (Rogue Router Problem) .....................20
4.6. Router ID .................................................20
5. Optimizations and Resource Sizing ..............................21
5.1. Update Packing and Repacking ..............................21
5.2. Signature per Prefix vs. Signature per Update .............22
5.3. Maximum BGPsec Update PDU Size ............................22
5.4. Temporary Suspension of Attestations and Validations ......23
6. Incremental Deployment and Negotiation of BGPsec ...............24
6.1. Downgrade Attacks .........................................24
6.2. Inclusion of Address Family in Capability Advertisement ...24
6.3. Incremental Deployment: Capability Negotiation ............25
6.4. Partial Path Signing ......................................25
6.5. Consideration of Stub ASes with Resource
Constraints: Encouraging Early Adoption ...................26
6.6. Proxy Signing .............................................27
6.7. Multiple Peering Sessions between ASes ....................28
7. Interaction of BGPsec with Common BGP Features .................29
7.1. Peer Groups ...............................................29
7.2. Communities ...............................................29
7.3. Consideration of iBGP Speakers and Confederations .........30
7.4. Consideration of Route Servers in IXPs ....................31
7.5. Proxy Aggregation (a.k.a. AS_SETs) ........................32
7.6. 4-Byte AS Numbers .........................................32
8. BGPsec Validation ..............................................33
8.1. Sequence of BGPsec Validation Processing in a Receiver ....33
8.2. Signing and Forwarding Updates when Signatures
Failed Validation .........................................34
8.3. Enumeration of Error Conditions ...........................35
8.4. Procedure for Processing Unsigned Updates .................36
8.5. Response to Syntactic Errors in Signatures and
Recommendations for How to React to Them ..................36
8.6. Enumeration of Validation States ..........................37
8.7. Mechanism for Transporting Validation State through iBGP ..39
9. Operational Considerations .....................................41
9.1. Interworking with BGP Graceful Restart ....................41
9.2. BCP Recommendations for Minimizing Churn:
Certificate Expiry/Revocation and Signature Expire Time ...42
9.3. Outsourcing Update Validation .............................42
9.4. New Hardware Capability ...................................43
9.5. Signed Peering Registrations ..............................44
10. Security Considerations .......................................44
11. IANA Considerations ...........................................44
12. Informative References ........................................44
Acknowledgements ..................................................49
Contributors ......................................................49
Author's Address ..................................................50
6. Incremental Deployment and Negotiation of BGPsec ...............24
6.1. Downgrade Attacks .........................................24
6.2. Inclusion of Address Family in Capability Advertisement ...24
6.3. Incremental Deployment: Capability Negotiation ............25
6.4. Partial Path Signing ......................................25
6.5. Consideration of Stub ASes with Resource
Constraints: Encouraging Early Adoption ...................26
6.6. Proxy Signing .............................................27
6.7. Multiple Peering Sessions between ASes ....................28
7. Interaction of BGPsec with Common BGP Features .................29
7.1. Peer Groups ...............................................29
7.2. Communities ...............................................29
7.3. Consideration of iBGP Speakers and Confederations .........30
7.4. Consideration of Route Servers in IXPs ....................31
7.5. Proxy Aggregation (a.k.a. AS_SETs) ........................32
7.6. 4-Byte AS Numbers .........................................32
8. BGPsec Validation ..............................................33
8.1. Sequence of BGPsec Validation Processing in a Receiver ....33
8.2. Signing and Forwarding Updates when Signatures
Failed Validation .........................................34
8.3. Enumeration of Error Conditions ...........................35
8.4. Procedure for Processing Unsigned Updates .................36
8.5. Response to Syntactic Errors in Signatures and
Recommendations for How to React to Them ..................36
8.6. Enumeration of Validation States ..........................37
8.7. Mechanism for Transporting Validation State through iBGP ..39
9. Operational Considerations .....................................41
9.1. Interworking with BGP Graceful Restart ....................41
9.2. BCP Recommendations for Minimizing Churn:
Certificate Expiry/Revocation and Signature Expire Time ...42
9.3. Outsourcing Update Validation .............................42
9.4. New Hardware Capability ...................................43
9.5. Signed Peering Registrations ..............................44
10. Security Considerations .......................................44
11. IANA Considerations ...........................................44
12. Informative References ........................................44
Acknowledgements ..................................................49
Contributors ......................................................49
Author's Address ..................................................50
The goal of the BGPsec effort is to enhance the security of BGP by enabling full Autonomous System (AS) path validation based on cryptographic principles. Standards work on route origin validation based on a Resource PKI (RPKI) is already completed or nearing completion in the IETF SIDR WG [RFC6480] [RFC6482] [RFC6483] [RFC6487] [RFC6811]. The BGPsec effort is aimed at taking advantage of the same RPKI infrastructure developed in the SIDR WG to add cryptographic signatures to BGP updates, so that routers can perform full AS path validation [RFC7132] [RFC7353] [RFC8205]. The BGPsec protocol specification, [RFC8205], was published recently. The key high-level design goals of the BGPsec protocol are as follows [RFC7353]:
BGPsec的目标是通过基于密码原理的完全自治系统（AS）路径验证来增强BGP的安全性。IETF SIDR工作组[RFC6480][RFC6482][RFC6483][RFC6487][RFC6811]已经完成或即将完成基于资源PKI（RPKI）的路由源验证标准工作。BGPsec的工作旨在利用SIDR WG中开发的相同RPKI基础设施向BGP更新添加加密签名，以便路由器可以执行完全AS路径验证[RFC7132][RFC7353][RFC8205]。BGPsec协议规范[RFC8205]最近发布。BGPsec协议的关键高层设计目标如下[RFC7353]：
o Rigorous path validation for all announced prefixes -- not merely showing that a path is not impossible.
o 对所有公布的前缀进行严格的路径验证——而不仅仅是表明路径并非不可能。
o Incremental deployment capability -- no flag-day requirement for global deployment.
o 增量部署能力--全局部署不需要国旗日。
o Protection of AS paths only in inter-domain routing (External BGP (eBGP)) -- not applicable to Internal BGP (iBGP) (or to IGPs).
o 仅在域间路由（外部BGP（eBGP））中保护AS路径——不适用于内部BGP（iBGP）（或IGP）。
o Aiming for no increase in a provider's data exposure (e.g., not requiring any disclosure of peering relations).
o 旨在不增加提供商的数据暴露（例如，不要求披露任何对等关系）。
This document provides design justifications for the initial draft version of the BGPsec protocol specification [BGPsec-Initial]. The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the discussions that weighed in on the pros and cons and aided the decision process. Where appropriate, this document provides brief notes (starting with "Note:") on design decisions that changed from the approach taken in the initial draft version of the BGPsec protocol specification as the specification was reviewed and updated by the IETF SIDR WG. (These design decisions resulted in RFC 8205 [RFC8205].) The notes provide pointers to the details and/or discussions about the design changes.
本文件为BGPsec协议规范初稿【BGPsec初始版本】提供了设计依据。设计师需要平衡许多竞争因素，本文件列出了支持或反对每项设计选择的决策。本文件还提供了讨论的简要总结，这些讨论权衡了利弊并有助于决策过程。在适当的情况下，本文件提供了有关设计决策的简要说明（以“说明：”开头），这些设计决策与IETF SIDR工作组审查和更新的BGPsec协议规范初稿中采用的方法不同。（这些设计决策导致RFC 8205[RFC8205]）注释提供了关于设计变更的细节和/或讨论的指针。
The design choices and discussions are presented in the following sections (under the following eight broad categories, with many subtopics within each category):
以下章节介绍了设计选择和讨论（在以下八大类别下，每个类别中有许多子主题）：
o Section 2 ("Creating Signatures and the Structure of BGPsec Update Messages")
o 第2节（“创建签名和BGPsec更新消息的结构”）
o Section 3 ("Withdrawal Protection")
o 第3节（“撤回保护”）
o Section 4 ("Signature Algorithms and Router Keys")
o 第4节（“签名算法和路由器密钥”）
o Section 5 ("Optimizations and Resource Sizing")
o 第5节（“优化和资源规模”）
o Section 6 ("Incremental Deployment and Negotiation of BGPsec")
o 第6节（“BGPsec的增量部署和协商”）
o Section 7 ("Interaction of BGPsec with Common BGP Features")
o 第7节（“BGPsec与通用BGP功能的交互”）
o Section 8 ("BGPsec Validation")
o 第8节（“BGPsec验证”）
o Section 9 ("Operational Considerations")
o 第9节（“运营考虑”）
Route origin validation using Route Origin Authorizations (ROAs) [RFC6482] [RFC6811] is necessary and complements AS path attestation based on signed updates. Thus, the BGPsec design makes use of the origin validation capability facilitated by the ROAs in the RPKI.
使用路由来源授权（ROA）[RFC6482][RFC6811]进行路由来源验证是必要的，并作为基于签名更新的路径证明的补充。因此，BGPsec设计利用RPKI中ROA促进的原产地验证能力。
Note: In the finalized BGPsec protocol specification [RFC8205], BGPsec is synonymous with cryptographic AS path attestation. Origin validation and BGPsec (path signatures) are the two key pieces of the SIDR WG solution for BGP security.
注：在最终确定的BGPsec协议规范[RFC8205]中，BGPsec与加密AS路径认证同义。原产地验证和BGPsec（路径签名）是SIDR WG BGP安全解决方案的两个关键部分。
Route origin validation using RPKI constructs, as developed in the IETF SIDR WG, is a necessary component of BGP security. It provides cryptographic validation that the first-hop AS is authorized to originate a route for the prefix in question.
如IETF SIDR WG中所开发的，使用RPKI构造的路由源验证是BGP安全性的必要组成部分。它提供加密验证，即第一跳AS被授权为所讨论的前缀发起路由。
An originating AS will sign over the Network Layer Reachability Information (NLRI) length, NLRI prefix, its own AS number (ASN), the next ASN, the signature algorithm suite ID, and a signature Expire Time (see Section 3.2) for the update. The update signatures will be carried in a new optional, non-transitive BGP attribute.
发起AS将通过网络层可达性信息（NLRI）长度、NLRI前缀、其自身的AS编号（ASN）、下一个ASN、签名算法套件ID和更新的签名过期时间（见第3.2节）进行签名。更新签名将在一个新的可选、不可传递的BGP属性中携带。
Note: The finalized BGPsec protocol specification [RFC8205] differs from the above. There is no mention in RFC 8205 of a signature Expire Time field in the BGPsec update. Further, there are some additional details concerning attributes signed by the origin AS that can be found in Figure 8 in Section 4.2 of RFC 8205 [RFC8205]. In particular, the signed data also includes the Address Family Identifier (AFI) as described in RFC 8205. By adding the AFI in the data covered by a signature, a specific security concern was alleviated; see [Mandelberg1] (post to the SIDR WG Mailing List) and the discussion thread that followed on the topic. The AFI is obtained from the MP_REACH_NLRI attribute in the BGPsec update. As stated in Section 4.1 of RFC 8205, a BGPsec update message "MUST use the MP_REACH_NLRI attribute [RFC4760] to encode the prefix."
注：最终确定的BGPsec协议规范[RFC8205]与上述规范不同。RFC 8205中未提及BGPsec更新中的签名过期时间字段。此外，在RFC 8205[RFC8205]第4.2节的图8中，还可以找到一些关于由源代码签名的属性的附加细节。具体地，签名数据还包括如RFC 8205中所述的地址族标识符（AFI）。通过在签名覆盖的数据中添加AFI，缓解了特定的安全问题；请参阅[Mandelberg1]（发布到SIDR WG邮件列表）和主题后面的讨论线索。AFI是从BGPsec更新中的MP_REACH_NLRI属性获得的。如RFC 8205第4.1节所述，BGPsec更新消息“必须使用MP_REACH_NLRI属性[RFC4760]对前缀进行编码。”
The next-hop ASN is included in the data covered by the signature. Without this inclusion, the AS path cannot be secured; for example, the path can be shortened (by a MITM (man in the middle)) without being detected.
下一跳ASN包含在签名覆盖的数据中。如果不包含此项，AS路径将无法得到保护；例如，路径可以缩短（由MITM（中间人））而不被检测。
It was decided that only the originating AS needs to insert a signature Expire Time in the update, as it is the originator of the route. The origin AS also will re-originate, i.e., beacon, the update prior to the Expire Time of the advertisement (see Section 3.2). (For an explanation of why upstream ASes do not insert their respective signature Expire Times, please see Section 3.2.2.)
决定只有发起AS需要在更新中插入签名过期时间，因为它是路由的发起人。源AS也将在广告到期之前重新发起更新，即信标（见第3.2节）。（有关上游ASE不插入其各自签名过期时间的解释，请参见第3.2.2节。）
Note: Expire Time and beaconing were eventually replaced by router key rollover. The BGPsec protocol [RFC8205] is expected to make use of router key rollover to mitigate replay attacks and withdrawal suppression [BGPsec-Rollover] [Replay-Protection].
注意：过期时间和信标最终被路由器密钥翻转所取代。BGPsec协议[RFC8205]预计将利用路由器密钥翻转来减轻重放攻击和撤回抑制[BGPsec翻转][重放保护]。
It was decided that each signed update would include only one NLRI prefix. If more than one NLRI prefix were included and an upstream AS elected to propagate the advertisement for a subset of the prefixes, then the signature(s) on the update would break (see Sections 5.1 and 5.2). If a mechanism were employed to preserve
决定每个签名更新只包含一个NLRI前缀。如果包含多个NLRI前缀，并选择一个上游来传播前缀子集的广告，则更新上的签名将中断（见第5.1和5.2节）。如果使用一种机制来保护
prefixes that were dropped, this would reveal information to subsequent ASes that is not revealed in normal BGP operation. Thus, a trade-off was made to preserve the level of route information exposure that is intrinsic to BGP over the performance hit implied by limiting each update to carry only one prefix.
删除的前缀，这将向后续ASE显示正常BGP操作中未显示的信息。因此，为了保持BGP固有的路由信息暴露水平，而不是限制每次更新仅携带一个前缀所隐含的性能影响，我们进行了权衡。
The signature data is carried in an optional, non-transitive BGP attribute. The attribute is optional because this is the standard mechanism available in BGP to propagate new types of data. It was decided that the attribute should be non-transitive because of concern about the impact of sending the (potentially large) signatures to routers that don't understand them. Also, if a router that does not understand BGPsec somehow gets an update message with path signatures (i.e., the update includes the BGPsec_PATH attribute (see Section 3 of RFC 8205)), then it would be undesirable for that router to forward the update to all of its neighbors, especially those who do not understand BGPsec and may choke if they receive many updates with large optional BGP attributes. It is envisioned that BGPsec and traditional BGP will coexist while BGPsec is deployed incrementally.
签名数据包含在可选的、不可传递的BGP属性中。该属性是可选的，因为这是BGP中用于传播新类型数据的标准机制。由于担心将（可能较大的）签名发送到不理解它们的路由器的影响，因此决定该属性应该是非传递的。此外，如果不理解BGPsec的路由器以某种方式获得具有路径签名的更新消息（即，更新包括BGPsec_路径属性（参见RFC 8205第3节）），则该路由器不希望将更新转发给其所有邻居，尤其是那些不了解BGPsec的人，如果他们收到大量带有大型可选BGP属性的更新，可能会窒息。预计BGPsec和传统BGP将共存，而BGPsec将以增量方式部署。
In the context of BGPsec and throughout this document, an "upstream AS" simply refers to an AS that is further along in an AS path (the origin AS being the nearest to a prefix). In principle, an AS that is upstream from an originating AS would digitally sign the combined information, including the NLRI length, NLRI prefix, AS path, next ASN, signature algorithm suite ID, and Expire Time. There are multiple choices regarding what is signed by an upstream AS, as follows:
在BGPsec的上下文中以及在本文件中，“上游AS”仅指AS路径中较远的AS（原点为最接近前缀的AS）。原则上，源AS上游的AS将对组合信息进行数字签名，包括NLRI长度、NLRI前缀、AS路径、下一个ASN、签名算法套件ID和过期时间。关于上游签名的内容，有多种选择，如下所示：
o Method 1: The signature protects the combination of the NLRI length, NLRI prefix, AS path, next ASN, signature algorithm suite ID, and Expire Time,
o 方法1：签名保护NLRI长度、NLRI前缀、AS路径、下一个ASN、签名算法套件ID和过期时间的组合，
o Method 2: The signature protects just the combination of the previous signature (i.e., the signature of the neighbor AS who forwarded the update) and the next ASN, or
o 方法2：签名仅保护前一个签名（即转发更新的邻居的签名）和下一个ASN的组合，或
o Method 3: The signature protects everything that was received from the preceding AS plus the next (i.e., target) ASN; thus, ASi signs over the NLRI length, NLRI prefix, signature algorithm suite ID, Expire Time, {ASi, AS(i-1), AS(i-2), ..., AS2, AS1}, AS(i+1) (i.e., the next ASN), and {Sig(i-1), Sig(i-2), ..., Sig2, Sig1}.
o 方法3：签名保护从前一个AS加上下一个（即目标）ASN接收的所有内容；因此，ASi在NLRI长度、NLRI前缀、签名算法套件ID、过期时间、{ASi，AS（i-1）、AS（i-2）、…、AS2、AS1}、AS（i+1）（即下一个ASN）和{Sig（i-1）、Sig（i-2）、…、Sig2、Sig1}上签名。
Note: Please see the notes in Sections 2.2.1 and 2.2.2 regarding the elimination of the Expire Time field in the finalized BGPsec protocol specification [RFC8205].
注：请参阅第2.2.1节和第2.2.2节中关于在最终确定的BGPsec协议规范[RFC8205]中删除过期时间字段的注释。
It was decided that Method 2 will be used. Please see [BGPsec-Initial] for additional protocol details and syntax.
决定采用方法2。有关其他协议的详细信息和语法，请参见[BGPsec Initial]。
Note: The finalized BGPsec protocol specification [RFC8205] essentially uses Method 3 (except for Expire Time). Additional details concerning attributes signed by an upstream AS can be found in Figure 8 in Section 4.2 of RFC 8205 [RFC8205]. The decision to go with Method 3 (with suitable additions to the data signed) was motivated by a security concern that was associated with Method 2; see [Mandelberg2] (post to the SIDR WG Mailing List) and the discussion thread that followed on the topic. Also, there is a strong rationale for the sequence of octets to be hashed (as shown in Figure 8 in Section 4.2 of RFC 8205); this sequencing of data is motivated by implementation efficiency considerations. See [Borchert] (post to the SIDR WG Mailing List) for an explanation.
注：最终确定的BGPsec协议规范[RFC8205]基本上使用方法3（过期时间除外）。关于上游签名属性的其他详细信息，请参见RFC 8205[RFC8205]第4.2节中的图8。决定采用方法3（对签署的数据进行适当补充）是出于与方法2相关的安全考虑；请参阅[Mandelberg2]（发布到SIDR WG邮件列表）和主题后面的讨论线索。此外，八位字节序列进行散列也有充分的理由（如RFC 8205第4.2节图8所示）；这种数据排序是出于实施效率的考虑。请参见[Borchert]（发布到SIDR工作组邮件列表）了解解释。
The rationale for this choice (Method 2) was as follows. Signatures are performed over hash blocks. When the number of bytes to be signed exceeds one hash block, the remaining bytes will overflow into a second hash block, resulting in a performance penalty. So, it is advantageous to minimize the number of bytes being hashed. Also, an analysis of the three options noted above did not identify any vulnerabilities associated with this approach.
这一选择（方法2）的理由如下。签名在散列块上执行。当要签名的字节数超过一个哈希块时，剩余的字节将溢出到第二个哈希块中，导致性能损失。因此，最小化被散列的字节数是有利的。此外，对上述三个选项的分析并未发现与此方法相关的任何漏洞。
Any attributes other than those identified in Sections 2.2 and 2.3 are not signed. Examples of such attributes include the community attribute, the NO-EXPORT attribute, and Local_Pref.
除第2.2节和第2.3节中确定的属性外，任何属性均未签名。此类属性的示例包括community属性、NO-EXPORT属性和Local_Pref。
Any of the above-mentioned attributes that are not signed are viewed as local (e.g., do not need to propagate beyond the next hop) or lack clear security needs. NO-EXPORT is sent over a secured next hop and does not need signing. The BGPsec design should work with any transport-layer protections. It is well understood that the transport layer must be protected hop by hop (if only to prevent malicious session termination).
上述任何未签名的属性都被视为本地属性（例如，不需要传播到下一跳之后）或缺乏明确的安全需求。NO-EXPORT通过安全的下一跳发送，不需要签名。BGPsec设计应适用于任何传输层保护。众所周知，必须逐跳保护传输层（如果只是为了防止恶意会话终止）。
The following example describes the expected router actions on receipt of a signed update. Consider an update that was originated by AS1 with NLRI prefix p and has traversed the AS path [AS(i-1) AS(i-2) ... AS2 AS1] before arriving at ASi. Let the Expire Time (inserted by AS1) for the signature in this update be denoted as Te. Let AlgID represent the ID of the signature algorithm suite that is in use. The update is to be processed at ASi and possibly forwarded to AS(i+1). Let the attestations (signatures) inserted by each router in the AS path be denoted by Sig1, Sig2, ..., Sig(i-2), and Sig(i-1) corresponding to AS1, AS2, ..., AS(i-2), and AS(i-1), respectively.
以下示例描述了收到签名更新时预期的路由器操作。考虑由ASL1用NLRI前缀P发起的更新，并且在到达ASI之前已经遍历AS路径（AS（I-1）AS（I-2）…AS2 AS1]。将此更新中签名的过期时间（由AS1插入）表示为Te。让AlgID表示正在使用的签名算法套件的ID。更新将在ASi进行处理，并可能转发给AS（i+1）。让每个路由器在AS路径中插入的证明（签名）分别由对应于AS1、AS2、…、AS（i-2）和AS（i-1）的Sig1、Sig2、…、Sig（i-2）和Sig（i-1）表示。
The method (Method 2 in Section 2.3) selected for signing requires a receiving router in ASi to perform the following actions:
选择用于签名的方法（第2.3节中的方法2）要求ASi中的接收路由器执行以下操作：
o Validate the route origin pair (p, AS1) by performing a ROA match.
o 通过执行ROA匹配来验证路由原点对（p，AS1）。
o Verify that Te is greater than the clock time at the router performing these checks.
o 验证Te是否大于执行这些检查的路由器的时钟时间。
o Check Sig1 with inputs {NLRI length, p, AlgID, Te, AS1, AS2}.
o 使用输入{NLRI长度，p，AlgID，Te，AS1，AS2}检查Sig1。
o Check Sig2 with inputs {Sig1, AS3}.
o 用输入{Sig1，AS3}检查Sig2。
o Check Sig3 with inputs {Sig2, AS4}.
o 用输入{Sig2，AS4}检查Sig3。
o ...
o ...
o ...
o ...
o Check Sig(i-2) with inputs {Sig(i-3), AS(i-1)}.
o 用输入{Sig（i-3），AS（i-1）}检查Sig（i-2）。
o Check Sig(i-1) with inputs {Sig(i-2), ASi}.
o 用输入{Sig（i-2），ASi}检查Sig（i-1）。
o If the route that has been verified is selected as the best path (for prefix p), then generate Sig(i) with inputs {Sig(i-1), AS(i+1)}, and generate an update including Sig(i) to AS(i+1).
o 如果已验证的路由被选择为最佳路径（对于前缀p），则使用输入{Sig（i-1），as（i+1）}生成Sig（i），并生成包括Sig（i）到as（i+1）的更新。
Note: The above description of BGPsec update validation and forwarding differs in its details from the published BGPsec protocol specification [RFC8205]. Please see Sections 4 and 5 of [RFC8205].
注：上述BGPsec更新验证和转发的详细说明与已发布的BGPsec协议规范[RFC8205]不同。请参见[RFC8205]第4节和第5节。
See Section 8.1 for suggestions regarding efficient sequencing of BGPsec validation processing in a receiving router. Some or all of the validation actions may be performed by an off-board server (see Section 9.3).
有关接收路由器中BGPsec验证处理的有效排序的建议，请参见第8.1节。部分或全部验证操作可由非车载服务器执行（见第9.3节）。
Prepending will be allowed. Prepending is defined as including more than one instance of the AS number (ASN) of the router that is signing the update.
允许预编。预结束定义为包含对更新进行签名的路由器的as编号（ASN）的多个实例。
Note: The finalized BGPsec protocol specification [RFC8205] uses a pCount field associated with each AS in the path to indicate the number of prepends for that AS (see Figure 5 in Section 3.1 of [RFC8205]).
注：最终确定的BGPsec协议规范[RFC8205]使用与路径中每个AS关联的pCount字段来指示该AS的前置数（参见[RFC8205]第3.1节中的图5）。
The initial version [BGPsec-Initial] of the BGPsec specification calls for a signature to be associated with each prepended AS. The optimization of having just one signature for multiple prepended ASes was pursued later. The pCount field is now used to represent AS prepends; see Section 3.1 in RFC 8205.
BGPsec规范的初始版本[BGPsec initial]要求签名与每个前置AS关联。对于多个前置ASE，仅具有一个签名的优化在后面进行。pCount字段现在用于表示前缀；参见RFC 8205中的第3.1节。
Concerning the inclusion of RPKI data in an update, it was decided that only the Subject Key Identifier (SKI) of the router certificate must be included in a signed update. This information identifies the router certificate, based on the SKI generation criteria defined in [RFC6487].
关于在更新中包含RPKI数据的问题，决定只有路由器证书的主题密钥标识符（SKI）必须包含在签名更新中。该信息根据[RFC6487]中定义的SKI生成标准识别路由器证书。
Whether or not each router public key certificate should be included in a signed update was discussed. Inclusion of this information might be helpful for routers that do not have access to RPKI servers or temporarily lose connectivity to them. It is safe to assume that in the majority of network environments, intermittent connectivity would not be a problem. So, it is best to avoid this complexity, because the majority of the use environments do not have connectivity constraints. Because the SKI of a router certificate is a hash of the public key of that certificate, it suffices to select the public key from that certificate. This design assumes that each BGPsec router has access to a cache containing the relevant data from (validated) router certificates.
讨论了每个路由器公钥证书是否应包含在签名更新中。包含此信息可能有助于无法访问RPKI服务器或暂时失去与它们的连接的路由器。可以安全地假设，在大多数网络环境中，间歇性连接不会成为问题。因此，最好避免这种复杂性，因为大多数使用环境都没有连接约束。因为路由器证书的SKI是该证书公钥的散列，所以从该证书中选择公钥就足够了。此设计假定每个BGPsec路由器都可以访问包含来自（验证的）路由器证书的相关数据的缓存。
Withdrawals are not signed.
提款没有签字。
In the current BGP protocol, any AS can withdraw, at any time, any prefix it previously announced. The rationale for not signing withdrawals is that BGPsec assumes the use of transport security between neighboring BGPsec routers. Thus, no external entity can inject an update that withdraws a route or replay a previously transmitted update containing a withdrawal. Because the rationale for withdrawing a route is not visible to a neighboring BGPsec router, there are residual vulnerabilities associated with withdrawals. For example, a router that advertised a (valid) route may fail to withdraw that route when it is no longer viable. A router also might re-advertise a route that it previously withdrew, before the route is again viable. This latter vulnerability is mitigated by the Expire Time associated with the origin AS's signature (see Section 3.2).
在当前的BGP协议中，任何AS都可以在任何时候撤回其先前宣布的任何前缀。不签署取款的理由是BGPsec假设相邻BGPsec路由器之间使用传输安全。因此，任何外部实体都不能注入撤销路由的更新，也不能重播先前传输的包含撤销的更新。由于撤回路由的理由对相邻的BGPsec路由器不可见，因此存在与撤回相关的剩余漏洞。例如，公布（有效）路由的路由器在不再可行时可能无法撤回该路由。路由器也可能在路由再次可行之前重新公布其先前撤回的路由。后一个漏洞通过与源AS签名相关的过期时间得到缓解（见第3.2节）。
Repeated withdrawals and announcements for a prefix can run up the BGP Route Flap Damping (RFD) penalty [RFC2439] and may result in unreachability for that prefix at upstream routers. But what can the attacker gain from doing so? This phenomenon is intrinsic to the design and operation of RFD.
重复提取和通知前缀可能会导致BGP路由抖动阻尼（RFD）惩罚[RFC2439]，并可能导致上游路由器无法访问该前缀。但攻击者可以从中获得什么？这种现象是RFD设计和运行的固有现象。
3.2. Signature Expire Time for Withdrawal Protection (a.k.a. Mitigation of Replay Attacks)
3.2. 撤回保护的签名过期时间（又称重播攻击缓解）
Note: As mentioned earlier (Section 2.2.2), the Expire Time approach to mitigation of replay attacks and withdrawal suppression was subsequently changed to an approach based on router key rollover [BGPsec-Rollover] [Replay-Protection].
注：如前所述（第2.2.2节），缓解重播攻击和撤销抑制的过期时间方法随后更改为基于路由器密钥翻转[BGPsec翻转][重播保护]的方法。
Only the originating AS inserts a signature Expire Time in the update; all other ASes along an AS path do not insert Expire Times associated with their respective signatures. Further, the originating AS will re-originate a route sufficiently in advance of the Expire Time of its signature so that other ASes along an AS path will typically receive the re-originated route well ahead of the current Expire Time for that route.
只有原始AS在更新中插入签名过期时间；AS路径上的所有其他AS不会插入与其各自签名相关联的过期时间。此外，发起AS将在其签名的到期时间之前充分地重新发起路由，使得沿着AS路径的其他AS通常将在该路由的当前到期时间之前接收重新发起的路由。
It is recommended that the duration of the signature Expire Time be on the order of days (preferably), but it may be on the order of hours (about 4 to 8 hours) in some cases on the basis of perceived need for extra protection from replay attacks (i.e., where extra replay protection is perceived to be critical).
建议签名过期时间的持续时间为天（优选），但在某些情况下，基于对防止重放攻击的额外保护的感知需求（即，感知到额外重放保护至关重要），签名过期时间可能为小时（约4到8小时）。
Each AS should stagger the Expire Time values in the routes it originates. Re-origination will be done, say, at time Tb after origination or the last re-origination, where Tb will equal a certain percentage of the Expire Time, Te (for example, Tb = 0.75 x Te). The percentage will be configurable. Additional guidance can be provided via an operational considerations document later. Further, the actual re-origination time should be jittered with a uniform random distribution over a short interval {Tb1, Tb2} centered at Tb.
每个AS应在其发起的路由中错开过期时间值。重新发起将在发起后的时间Tb或最后一次重新发起时进行，其中Tb将等于到期时间的一定百分比Te（例如，Tb=0.75 x Te）。百分比将是可配置的。稍后可通过操作注意事项文件提供其他指导。此外，实际重新发起时间应在以Tb为中心的短间隔{Tb1，Tb2}上以均匀随机分布抖动。
It is also recommended that a receiving BGPsec router detect that the only attribute change in an announcement (relative to the current best path) is the Expire Time (besides, of course, the signatures). In that case, assuming that the update is found valid, the route processor should not re-announce the route to non-BGPsec peers. (It should sign and re-announce the route to BGPsec speakers only.) This procedure will reduce BGP chattiness for the non-BGPsec border routers.
还建议接收BGPsec路由器检测公告中唯一的属性更改（相对于当前最佳路径）是过期时间（当然，除了签名）。在这种情况下，假设发现更新有效，路由处理器不应向非BGPsec对等方重新宣布路由。（只应签署并向BGPsec发言人重新宣布路由。）此过程将减少非BGPsec边界路由器的BGP聊天次数。
Mitigation of BGPsec update replay attacks can be thought of as protection against malicious re-advertisements of withdrawn routes. If each AS along a path were to insert its own signature Expire Time, then there would be much additional BGP chattiness and an increase in BGP processing load due to the need to detect and react to multiple (possibly redundant) signature Expire Times. Furthermore, there would be no extra benefit from the point of view of mitigation of replay attacks as compared to having a single Expire Time corresponding to the signature of the originating AS.
BGPsec更新重播攻击的缓解可被视为防止撤回路由的恶意重新发布。如果一条路径上的每个AS都要插入自己的签名过期时间，那么由于需要检测和响应多个（可能是冗余的）签名过期时间，将会有更多的BGP聊天和BGP处理负载的增加。此外，从缓解重播攻击的角度来看，与具有与发起as的签名相对应的单个过期时间相比，不会有额外的好处。
As noted in Section 3.2.1, the recommended Expire Time value is on the order of days, but 4 to 8 hours may be used in some cases on the basis of perceived need for extra protection from replay attacks. Thus, different ASes may choose different values based on the perceived need to protect against malicious route replays. (A shorter Expire Time reduces the window during which an AS can maliciously replay the route. However, shorter Expire Time values cause routes to be refreshed more often, thus causing more BGP chatter.) Even a 4-hour duration seems long enough to keep the re-origination workload manageable. For example, if 500K routes are re-originated every 4 hours, it amounts to an increase in BGP update load of 35 updates per second; this can be considered reasonable. However, further analysis is needed to confirm these recommendations.
如第3.2.1节所述，建议的过期时间值以天为单位，但在某些情况下，基于对防止重播攻击的额外保护的感知需要，可以使用4到8小时。因此，不同的ASE可能会根据防范恶意路由重播的感知需求选择不同的值。（较短的过期时间缩短了AS恶意重播路由的时间窗口。但是，较短的过期时间值会导致路由更频繁地刷新，从而导致更多BGP聊天。）即使是4小时的持续时间似乎也足以使重新发起工作负载保持可控。例如，如果每4小时重新发起500K路由，则BGP更新负载将增加每秒35次更新；这是合理的。然而，需要进一步分析以确认这些建议。
As stated in Section 3.2.1, the originating AS will re-originate a route sufficiently in advance of its Expire Time. What is considered "sufficiently in advance"? To answer this question, modeling should be performed to determine the 95th-percentile convergence time of update propagation in a BGPsec-enabled Internet.
如第3.2.1节所述，始发As将在其到期时间之前充分重新始发路线。什么是“充分提前”？为了回答这个问题，应该进行建模，以确定启用BGPsec的互联网中更新传播的95%收敛时间。
Each BGPsec router should stagger the Expire Time values in the updates it originates, especially during table dumps to a neighbor or during its own recovery from a BGP session failure. By doing this, the re-origination (i.e., beaconing) workload at the router will be dispersed.
每个BGPsec路由器应在其发起的更新中错开过期时间值，特别是在向邻居转储表期间或在其自身从BGP会话故障恢复期间。通过这样做，路由器上的重新发起（即信标）工作负载将被分散。
The idea of sending a new signature Expire Time in a special message (rather than retransmitting the entire update with signatures) was considered. However, the decision was made to not do this. Re-origination to communicate a new signature Expire Time will be done by propagating a normal update message; no special type of message will be required.
考虑了在特殊消息中发送新的签名过期时间（而不是用签名重新传输整个更新）的想法。然而，决定不这样做。通过传播正常的更新消息，重新发起以传达新的签名过期时间；不需要特殊类型的消息。
It was suggested that if the re-beaconing of the signature Expire Time is carried in a separate special message, then any processing load related to the update may be reduced. But it was recognized that such a re-beaconing message by necessity entails AS path and prefix information and, hence, cannot be separated from the update.
有人建议，如果在单独的特殊消息中携带签名过期时间的重新信标，则可以减少与更新有关的任何处理负载。但人们认识到，这种重新信标的消息必然包含路径和前缀信息，因此不能与更新分离。
It was observed that at the edge of the Internet, there are frequent updates that may result from such simple situations as a BGP session being switched from one interface to another (e.g., from primary to backup) between two peering ASes (e.g., customer and provider). With traditional BGP, these updates do not propagate beyond the two ASes involved. But with BGPsec, the customer AS will put in a new signature Expire Time each time such an event happens; hence, the update will need to propagate throughout the Internet (limited only by the process of best-path selection). It was accepted that this cost of added churn will be unavoidable.
据观察，在互联网边缘，由于两个对等ASE（例如，客户和提供商）之间的BGP会话从一个接口切换到另一个接口（例如，从主接口切换到备份），可能会导致频繁的更新。对于传统的BGP，这些更新不会传播到涉及的两个ASE之外。但对于BGPsec，客户AS将在每次此类事件发生时输入新的签名过期时间；因此，更新需要在整个互联网上传播（仅受最佳路径选择过程的限制）。人们普遍认为，增加客户流失的成本是不可避免的。
With regard to the RFD protocol [RFC2439] [JunOS] [CiscoIOS], no differential treatment is required for Expire-Time-triggered (re-beaconed) BGPsec updates.
关于RFD协议[RFC2439][JunOS][CiscoIOS]，过期时间触发（重新信标）BGPsec更新不需要区别对待。
However, it was noted that it would be preferable if these updates did not cause route churn (and perhaps did not even require any RFD-related processing), since they are identical except for the change in the Expire Time value. This can be accomplished by not assigning an RFD penalty to Expire-Time-triggered updates. If the community agrees, this could be accommodated, but a change to the BGP-RFD protocol will be required.
然而，有人指出，如果这些更新不会引起路由搅动（甚至可能不需要任何与RFD相关的处理），则更可取，因为除了过期时间值的变化外，它们是相同的。这可以通过不为过期时间触发的更新分配RFD惩罚来实现。如果社区同意，这是可以接受的，但需要更改BGP-RFD协议。
To summarize, this decision is supported by the following observations:
总而言之，这一决定得到以下意见的支持：
1. Expire-Time-triggered updates are generally not preceded by withdrawals; hence, the path hunting and associated RFD exacerbation [Mao02] [RIPE580] problems are not anticipated.
1. 过期时间触发的更新通常不会在退出之前进行；因此，路径搜索和相关的RFD恶化[Mao02][RIPE580]问题是不可预测的。
2. Such updates would not normally change the best path (unless another concurrent event impacts the best path).
2. 此类更新通常不会更改最佳路径（除非另一个并发事件影响最佳路径）。
3. Expire-Time-triggered updates would have a negligible impact on RFD penalty accumulation because the re-advertisement interval is much longer relative to the half-time of RFD penalty decay.
3. 过期时间触发的更新对RFD惩罚累积的影响可以忽略不计，因为重新公布间隔相对于RFD惩罚衰减的一半时间要长得多。
Elaborating further on the third observation above, it may be noted that the re-advertisements (i.e., beacons) of a route for a given address prefix from a given peer will be received at intervals of several hours (see Section 3.2). During that time period, any incremental contribution to the RFD penalty due to an Expire-Time-triggered update would decay sufficiently to have negligible (if any) impact on damping the address prefix in question.
在进一步阐述上述第三个观察结果时，可以注意到，将每隔几个小时接收来自给定对等方的给定地址前缀的路由的重新广告（即，信标）（参见第3.2节）。在这段时间内，由于过期时间触发的更新而对RFD惩罚的任何增量贡献都将衰减到足以对所讨论的地址前缀产生可忽略的影响（如果有的话）。
Additional details regarding this analysis and justification are as follows:
有关该分析和理由的其他详细信息如下：
The frequency with which RFD penalty increments may be triggered for a given prefix from a given peer is the same as the re-beaconing frequency for that prefix from its origin AS. The re-beaconing frequency is on the order of once every several hours (see Section 3.2). The incremental RFD penalty assigned to a prefix due to a re-beaconed update varies, depending on the implementation. For example, it appears that the JunOS implementation [JunOS] would assign a penalty of 1000 or 500, depending on whether the re-beaconed update is regarded as a re-advertisement or an attribute change, respectively. Normally, a re-beaconed update would be treated as an attribute change. On the other hand, the Cisco implementation [CiscoIOS] assigns an RFD penalty only in the case of an actual flap (i.e., a route is available, then unavailable, or vice versa). So, it appears that Cisco's implementation of RFD would not assign any penalty for a re-beaconed update (i.e., a route was already advertised previously and was not withdrawn, and the re-beaconed update is merely updating the Expire Time attribute). Even if one assumes that an RFD penalty of 500 is assigned (corresponding to an attribute change according to the JunOS RFD implementation), it can be illustrated that the incremental effect it would have on damping the prefix in question would be negligible: the half-time of RFD
对于来自给定对等方的给定前缀，可以触发RFD惩罚增量的频率与该前缀从其原点as的重新信标频率相同。重设信标的频率大约为每几个小时一次（见第3.2节）。由于重新信标更新而分配给前缀的增量RFD惩罚因实现而异。例如，JunOS实现[JunOS]似乎将分配1000或500的惩罚，这分别取决于重新定位的更新是被视为重新发布还是属性更改。通常，重新定位的更新将被视为属性更改。另一方面，Cisco实施[CiscoIOS]仅在实际襟翼的情况下分配RFD惩罚（即，路线可用，然后不可用，反之亦然）。因此，Cisco的RFD实施似乎不会对重新定位的更新分配任何惩罚（即，之前已经公布了一条路由，并且没有撤回，而重新定位的更新只是更新过期时间属性）。即使假设分配了500的RFD惩罚（对应于根据JunOS RFD实现的属性更改），也可以说明它对阻尼所讨论前缀的增量影响可以忽略不计：RFD的一半时间
penalty decay is normally set to 15 minutes, whereas the re-beaconing frequency is on the order of once every several hours. An incremental penalty of 500 would decay to 31.25 in 1 hour, 0.12 in 2 hours, and 3x10^(-5) in 3 hours. It may also be noted that the threshold for route suppression is 3000 in JunOS and 2000 in Cisco IOS. Based on the foregoing analysis, it may be concluded that routine re-beaconing by itself would not result in RFD suppression of routes in the BGPsec protocol.
惩罚衰减通常设置为15分钟，而重新信标频率大约为每几个小时一次。500的增量罚款将在1小时内降至31.25，2小时内降至0.12，3小时内降至3x10^（-5）。还可能注意到，路由抑制的阈值在JunOS中为3000，在Cisco IOS中为2000。基于上述分析，可以得出结论，在BGPsec协议中，常规重新信标本身不会导致路由的RFD抑制。
Initially, the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 and SHA-256 will be used for generating BGPsec path signatures. One other signature algorithm, e.g., RSA-2048, will also be used during prototyping and testing. The use of a second signature algorithm is needed to verify the ability of the BGPsec implementations to change from a current algorithm to the next algorithm.
最初，将使用具有曲线P-256和SHA-256的椭圆曲线数字签名算法（ECDSA）生成BGPsec路径签名。在原型设计和测试期间，还将使用另一种签名算法，例如RSA-2048。需要使用第二个签名算法来验证BGPsec实现从当前算法更改为下一个算法的能力。
Note: The BGPsec cryptographic algorithms document [RFC8208] specifies only the ECDSA with curve P-256 and SHA-256.
注：BGPsec加密算法文档[RFC8208]仅指定了具有曲线P-256和SHA-256的ECDSA。
Initially, the RSA-2048 algorithm for BGPsec update signatures was considered as a choice because it is being used ubiquitously in the RPKI system. However, the use of ECDSA P-256 was decided upon because it yields a smaller signature size; hence, the update size and (in turn) the RIB size needed in BGPsec routers would be much smaller [RIB_size].
最初，BGPsec更新签名的RSA-2048算法被视为一种选择，因为它在RPKI系统中广泛使用。然而，决定使用ECDSA P-256，因为它产生较小的签名大小；因此，BGPsec路由器所需的更新大小和（反过来）RIB大小将小得多[RIB_大小]。
Using two different signature algorithms (e.g., ECDSA P-256 and RSA-2048) to test the transition from one algorithm to the other will increase confidence in prototype implementations.
使用两种不同的签名算法（例如ECDSA P-256和RSA-2048）来测试从一种算法到另一种算法的转换将提高原型实现的可信度。
Optimizations and specialized algorithms (e.g., for speedups) built on Elliptic Curve Cryptography (ECC) algorithms may have active IPR (intellectual property rights), but at the time of publication of this document no IPR had been disclosed to the IETF for the basic (unoptimized) algorithms. (To understand this better, [RFC6090] can be useful as a starting point.)
基于椭圆曲线密码（ECC）算法的优化和专用算法（例如，用于加速）可能具有有效的IPR（知识产权），但在本文件发布时，尚未向IETF披露基本（未优化）算法的IPR。（为了更好地理解这一点，[RFC6090]可以用作起点。）
Note: Recently, even open-source implementations have incorporated certain cryptographic optimizations and demonstrated significant performance speedup [Gueron]. Researchers continue to devote significant effort toward demonstrating substantial speedup for the ECDSA as part of BGPsec implementations [Mehmet1] [Mehmet2].
注意：最近，即使是开源实现也加入了某些加密优化，并显示出显著的性能加速[Gueron]。作为BGPsec实施的一部分[Mehmet1][Mehmet2]，研究人员继续致力于证明ECDSA的大幅加速。
During the transition period from one algorithm (i.e., the current algorithm) to the next (new) algorithm, the updates will carry two sets of signatures (i.e., two Signature_Blocks), one corresponding to each algorithm. Each Signature_Block will be preceded by its type-length field and an algorithm suite identifier. A BGPsec speaker that has been upgraded to handle the new algorithm should validate both Signature_Blocks and then add its corresponding signature to each Signature_Block for forwarding the update to the next AS. A BGPsec speaker that has not been upgraded to handle the new algorithm will strip off the Signature_Block of the new algorithm and then will forward the update after adding its own signature to the Signature_Block of the current algorithm.
在从一个算法（即当前算法）到下一个（新）算法的过渡期间，更新将携带两组签名（即两个签名块），每个签名块对应一个算法。每个签名块的前面将有其类型长度字段和算法套件标识符。已升级以处理新算法的BGPsec扬声器应验证两个签名块，然后将其相应的签名添加到每个签名块，以便将更新转发到下一个AS。尚未升级以处理新算法的BGPsec扬声器将剥离新算法的签名块，然后在将其自己的签名添加到当前算法的签名块后转发更新。
It was decided that there will be at most two Signature_Blocks per update.
决定每次更新最多有两个签名块。
Note: BGPsec path signatures are carried in the Signature_Block, which is an attribute contained in the BGPsec_PATH attribute (see Section 3.2 in [RFC8205]). The algorithm agility scheme described in the published BGPsec protocol specification is consistent with the above; see Section 6.1 of [RFC8205].
注：BGPsec路径签名包含在Signature_块中，Signature_块是BGPsec_路径属性中包含的一个属性（参见[RFC8205]中的第3.2节）。已发布的BGPsec协议规范中描述的算法敏捷性方案与上述一致；见[RFC8205]第6.1节。
A length field in the Signature_Block allows for delineation of the two signature blocks. Hence, a BGPsec router that doesn't know about a particular algorithm suite (and, hence, doesn't know how long signatures were for that algorithm suite) could still skip over the corresponding Signature_Block when parsing the message.
签名块中的长度字段允许描绘两个签名块。因此，不知道特定算法套件（因此不知道该算法套件的签名长度）的BGPsec路由器在解析消息时仍然可以跳过相应的签名块。
The overlap period between the two algorithms is expected to last 2 to 4 years. The RIB memory and cryptographic processing capacity will have to be sized to cope with such overlap periods when updates would contain two sets of signatures [RIB_size].
两种算法之间的重叠期预计将持续2至4年。当更新包含两组签名时，RIB内存和加密处理能力必须调整大小，以应对此类重叠期[RIB_size]。
The lifetime of a signature algorithm is anticipated to be much longer than the duration of a transition period from the current algorithm to a new algorithm. It is fully expected that all ASes will have converted to the required new algorithm within a certain amount of time that is much shorter than the interval in which a subsequent newer algorithm may be investigated and standardized for BGPsec. Hence, the need for more than two Signature_Blocks per update is not envisioned.
签名算法的生存期预计要比从当前算法到新算法的过渡期长得多。完全可以预期，所有ASE将在一定的时间内转换为所需的新算法，该时间比为BGPsec研究和标准化后续新算法的时间间隔短得多。因此，每次更新不需要两个以上的签名块。
There is currently weak or no support for the Sequential Aggregate Signature (SAS) approach. Please see Section 4.3.2 for a brief description of what the SAS is and what its pros and cons are.
目前对顺序聚合签名（SAS）方法的支持较弱或没有。请参阅第4.3.2节，了解SAS是什么及其优缺点的简要说明。
In the SAS method, there would be only one (aggregated) signature per signature block, irrespective of the number of AS hops. For example, ASn (the nth AS) takes as input the signatures of all previous ASes [AS1, ..., AS(n-1)] and produces a single composite signature. This composite signature has the property that a recipient who has the public keys for AS1, ..., ASn can verify (using only the single composite signature) that all of the ASes actually signed the message. The SAS could potentially result in savings in bandwidth and in Protocol Data Unit (PDU) size, and maybe in RIB size, but the signature generation and validation costs will be higher as compared to one signature per AS hop.
在SAS方法中，每个签名块只有一个（聚合）签名，而与AS跳数无关。例如，ASn（第n个AS）将所有先前AS[AS1，…，AS（n-1）]的签名作为输入，并生成单个复合签名。此复合签名具有以下属性：拥有AS1、…、ASn公钥的收件人可以验证（仅使用单个复合签名）所有ASE是否实际对消息进行了签名。SAS可能会节省带宽和协议数据单元（PDU）大小，也可能会节省RIB大小，但与每跳一个签名相比，签名生成和验证成本将更高。
SAS schemes exist in the literature, typically based on RSA or its equivalent. For a SAS with RSA and for the cryptographic strength needed for BGPsec signatures, a 2048-bit signature size (RSA-2048) would be required. However, without a SAS, the ECDSA with a 512-bit signature (256-bit key) would suffice for equivalent cryptographic strength. The larger signature size of RSA used with a SAS undermines the advantages of the SAS, because the average hop count, i.e., the number of ASes, for a route is about 3.8. In the end, it may turn out that the SAS has more complexity and does not provide sufficient savings in PDU size or RIB size to merit its use. Further exploration of this is needed to better understand SAS properties and applicability for BGPsec. There is also a concern that the SAS is not a time-tested cryptographic technique, and thus its adoption is potentially risky.
SAS方案存在于文献中，通常基于RSA或其等效方案。对于带有RSA的SAS和BGPsec签名所需的加密强度，需要2048位签名大小（RSA-2048）。但是，如果没有SAS，具有512位签名（256位密钥）的ECDSA就足以达到同等的加密强度。与SAS一起使用的RSA的较大签名大小削弱了SAS的优势，因为路由的平均跳数（即ASE数）约为3.8。最终，SAS可能会变得更加复杂，并且在PDU尺寸或肋骨尺寸方面无法提供足够的节省，因此不值得使用。为了更好地理解SAS特性和BGPsec的适用性，需要对此进行进一步的探索。还有一个问题是，SAS不是经过时间检验的加密技术，因此采用它有潜在的风险。
There is clearly a need to specify a transition path from a current protocol specification to a new version. When changes to the processing of the BGPsec path signatures are required, a new version of BGPsec will be required. Examples of this include changes to the data that is protected by the BGPsec signatures or adoption of a signature algorithm in which the number of signatures in the signature block may not correspond to one signature per AS in the AS path (e.g., aggregate signatures).
显然需要指定从当前协议规范到新版本的转换路径。当需要更改BGPsec路径签名的处理时，将需要新版本的BGPsec。这方面的示例包括对受BGPsec签名保护的数据的更改或采用签名算法，其中签名块中的签名数量可能不对应于AS路径中每个AS的一个签名（例如，聚合签名）。
This protocol-version transition mechanism is analogous to the algorithm transition discussed in Section 4.2. During the transition period from one protocol version (i.e., the current version) to the next (new) version, updates will carry two sets of signatures (i.e., two Signature_Blocks), one corresponding to each version. A protocol-version identifier is associated with each Signature_Block. Hence, each Signature_Block will be preceded by its type-length field and a protocol-version identifier. A BGPsec speaker that has been upgraded to handle the new version should validate both Signature_Blocks and then add its corresponding signature to each Signature_Block for forwarding the update to the next AS. A BGPsec speaker that has not been upgraded to handle the new protocol version will strip off the Signature_Block of the new version and then will forward the update with an attachment of its own signature to the Signature_Block of the current version.
该协议版本转换机制类似于第4.2节中讨论的算法转换。在从一个协议版本（即当前版本）到下一个（新）版本的过渡期间，更新将携带两组签名（即两个签名块），每个版本对应一组。协议版本标识符与每个签名块相关联。因此，每个签名块的前面将有其类型长度字段和协议版本标识符。已升级以处理新版本的BGPsec扬声器应验证两个签名块，然后将其相应的签名添加到每个签名块，以便将更新转发给下一个AS。尚未升级以处理新协议版本的BGPsec扬声器将剥离新版本的签名块，然后将更新及其自己的签名附件转发到当前版本的签名块。
Note: The details of protocol extensibility (i.e., transition to a new version of BGPsec) in the published BGPsec protocol specification (see Section 6.3 in [RFC8205]) differ somewhat from the above. In particular, the protocol-version identifier is not part of the BGPsec update. Instead, it is negotiated during the BGPsec capability exchange portion of BGPsec session negotiation.
注：已发布的BGPsec协议规范（见[RFC8205]第6.3节）中的协议扩展性细节（即，向新版本的BGPsec过渡）与上述有所不同。特别是，协议版本标识符不是BGPsec更新的一部分。而是在BGPsec会话协商的BGPsec能力交换部分进行协商。
In the case that a change to BGPsec is 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 (let's call it "BGPsec_PATH_TWO") that is designed to accommodate the desired changes to BGPsec. At this point, a transition would begin that is analogous to the algorithm transition discussed in Section 4.2. During the transition period, all BGPsec speakers will simultaneously include both the BGPsec_PATH (current) attribute (see Section 3 of RFC 8205) and the new BGPsec_PATH_TWO attribute. Once the transition is complete, the use of BGPsec_PATH could then be
如果认为需要对BGPsec进行更改，则预计将创建BGPsec的后续版本，并且该版本的BGPsec将指定一个新的BGP路径属性（我们称之为“BGPsec_path_TWO”），该属性旨在适应对BGPsec的所需更改。此时，将开始类似于第4.2节中讨论的算法转换的转换。在过渡期内，所有BGPsec扬声器将同时包括BGPsec_路径（当前）属性（参见RFC 8205第3节）和新的BGPsec_路径_两个属性。一旦转换完成，就可以使用BGPsec_路径
deprecated, at which point BGPsec speakers will include only the new BGPsec_PATH_TWO attribute. Such a process could facilitate a transition to new BGPsec semantics in a backwards-compatible fashion.
已弃用，此时BGPsec扬声器将仅包含新的BGPsec_PATH_TWO属性。这样一个过程可以促进以向后兼容的方式向新的BGPsec语义的转换。
Within each AS, each individual BGPsec router can have a unique pair of private and public keys [RFC8207].
在每个AS中，每个单独的BGPsec路由器可以有一对唯一的私钥和公钥[RFC8207]。
Given a unique key pair per router, if a router is compromised, its key pair can be revoked independently, without disrupting the other routers in the AS. Each per-router key pair will be represented in an end-entity certificate issued under the certification authority (CA) certificate of the AS. The Subject Key Identifier (SKI) in the signature points to the router certificate (and thus the unique public key) of the router that affixed its signature, so that a validating router can reliably identify the public key to use for signature verification.
给定每个路由器一个唯一的密钥对，如果一个路由器被破坏，其密钥对可以独立撤销，而不会中断AS中的其他路由器。每个路由器密钥对将在AS的证书颁发机构（CA）证书下颁发的终端实体证书中表示。签名中的主题密钥标识符（SKI）指向附加其签名的路由器的路由器证书（以及唯一公钥），以便验证路由器能够可靠地识别用于签名验证的公钥。
The router certificate subject name will be the string "ROUTER" followed by a decimal representation of a 4-byte ASN followed by the router ID. (Note: The details are specified in Section 3.1 in [RFC8209].)
路由器证书使用者名称将是字符串“router”，后跟4字节ASN的十进制表示，后跟路由器ID。（注：详细信息在[RFC8209]第3.1节中规定。）
Every X.509 certificate requires a subject name [RFC6487]. The stylized subject name adopted here is intended to facilitate debugging by including the ASN and router ID.
每个X.509证书都需要一个使用者名称[RFC6487]。此处采用的样式化主题名称旨在通过包含ASN和路由器ID来方便调试。
With traditional BGP [RFC4271], an originating BGP router normally packs multiple prefix announcements into one update if the prefixes all share the same BGP attributes. When an upstream BGP router forwards eBGP updates to its peers, it can also pack multiple prefixes (based on the shared AS path and attributes) into one update. The update propagated by the upstream BGP router may include only a subset of the prefixes that were packed in a received update.
对于传统的BGP[RFC4271]，如果前缀共享相同的BGP属性，则发起的BGP路由器通常将多个前缀通知打包到一个更新中。当上游BGP路由器将eBGP更新转发给其对等方时，它还可以将多个前缀（基于共享AS路径和属性）打包到一个更新中。由上游BGP路由器传播的更新可以仅包括在接收到的更新中打包的前缀的子集。
Each update contains exactly one prefix. This avoids a level of complexity that would otherwise be inevitable if the origin had packed and signed multiple prefixes in an update and an upstream AS decided to propagate an update containing only a subset of the prefixes in that update. BGPsec recommendations regarding packing and repacking may be revisited when optimizations are considered in the future.
每个更新只包含一个前缀。这避免了如果源站在更新中打包并签署了多个前缀，并且上游决定传播仅包含该更新中前缀子集的更新，则不可避免的复杂性。BGPsec关于包装和重新包装的建议可在将来考虑优化时重新考虑。
Currently, with traditional BGP, there are, on average, approximately four prefixes announced per update [RIB_size]. So, the number of BGP updates (carrying announcements) is about four times fewer, on average, as compared to the number of prefixes announced.
目前，对于传统的BGP，平均而言，每次更新[RIB_size]都会发布大约四个前缀。因此，BGP更新（携带公告）的数量平均比公布的前缀数量少四倍左右。
The current decision is to include only one prefix per secured update (see Section 2.2.2). When optimizations are considered in the future, the possibility of packing multiple prefixes into an update can also be considered. (Please see Section 5.2 for a discussion of signature per prefix vs. signature per update.) Repacking could be performed if signatures were generated on a per-prefix basis. However, one problem regarding this approach -- multiple prefixes in a BGP update but with a separate signature for each prefix -- is that the resulting BGP update violates the basic definition of a BGP update: the different prefixes will have different signatures and Expire Time attributes, while a BGP update (by definition) must have the same set of shared attributes for all prefixes it carries.
目前的决定是每个安全更新只包含一个前缀（见第2.2.2节）。将来考虑优化时，还可以考虑将多个前缀打包到更新中的可能性。（请参阅第5.2节，了解每个前缀的签名与每个更新的签名的讨论。）如果签名是基于每个前缀生成的，则可以执行重新打包。然而，这种方法的一个问题是——BGP更新中有多个前缀，但每个前缀都有一个单独的签名——结果BGP更新违反了BGP更新的基本定义：不同的前缀将具有不同的签名和过期时间属性，而BGP更新（根据定义）它所携带的所有前缀必须具有相同的共享属性集。
The initial design calls for including exactly one prefix per update; hence, there is only one signature in each secured update (modulo algorithm transition conditions).
初始设计要求每次更新只包含一个前缀；因此，每个安全更新中只有一个签名（模算法转换条件）。
Some notes to assist in future optimization discussions follow:
以下是一些有助于未来优化讨论的注释：
In the general case of one signature per update, multiple prefixes may be signed with one signature together with their shared AS path, next ASN, and Expire Time. If the "signature per update" technique is used, then there are potential savings in update PDU size as well as RIB memory size. But if there are any changes made to the announced prefix set along the AS path, then the AS where the change occurs would need to insert an Explicit Path Attribute (EPA) [Secure-BGP]. The EPA conveys information regarding what the prefix set contained prior to the change. There would be one EPA for each AS that made such a modification, and there would be a way to associate each EPA with its corresponding AS. This enables an upstream AS to know and verify what was announced and signed by prior ASes in the AS path (in spite of changes made to the announced prefix set along the way). The EPA adds complexity to processing (signature generation and validation); further increases the size of updates and, thus, of the RIB; and exposes data to downstream ASes that would not otherwise be exposed. Not all of the pros and cons of packing and repacking in the context of signature per prefix vs. signature per update (with packing) have been evaluated. But the current recommendation is for having only one prefix per update (no packing), so there is no need for the EPA.
在每次更新一个签名的一般情况下，可以使用一个签名对多个前缀及其共享AS路径、下一个ASN和过期时间进行签名。如果使用“每次更新签名”技术，则在更新PDU大小以及RIB内存大小方面有潜在的节约。但是，如果沿AS路径对公布的前缀集进行了任何更改，则发生更改的AS将需要插入显式路径属性（EPA）[安全BGP]。EPA传达了变更前前缀集包含的信息。进行此类修改的每个AS将有一个EPA，并且将有一种方法将每个EPA与其相应的AS相关联。这使上游AS能够知道并验证AS路径中先前的ASE所宣布和签署的内容（尽管沿途对宣布的前缀集进行了更改）。EPA增加了处理的复杂性（签名生成和验证）；进一步增加更新的大小，从而增加肋骨的大小；并向下游ASE公开否则不会公开的数据。在每个前缀签名与每个更新签名（打包）的上下文中，并非所有打包和重新打包的优缺点都得到了评估。但是目前的建议是每次更新只有一个前缀（无包装），因此不需要EPA。
The current BGP update message PDU size is limited to 4096 bytes [RFC4271]. The question was raised as to whether or not BGPsec would require a larger update PDU size.
当前BGP更新消息PDU大小限制为4096字节[RFC4271]。提出的问题是BGPsec是否需要更大的更新PDU大小。
The current thinking is that the maximum PDU size should be increased to 64 KB [BGP-Ext-Msg] so that there is sufficient room to accommodate two Signature_Blocks (i.e., one block with a current algorithm and another block with a new signature algorithm during a future transition period) for long AS paths.
当前的想法是，最大PDU大小应增加到64 KB[BGP Ext Msg]，以便有足够的空间容纳两个签名块（即，一个块具有当前算法，另一个块具有未来过渡期内的新签名算法）作为长路径。
Note: RFC 8205 states the following: "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."
注：RFC 8205声明如下：“所有BGPsec更新消息必须符合BGP的最大消息大小。如果生成的消息超过最大消息大小，则必须遵循RFC 4271[RFC4271]第9.2节中的指南。”
The current maximum message size for BGP updates is 4096 octets. An effort is underway in the IETF to extend it to a larger size [BGP-Ext-Msg]. BGPsec will conform to whatever maximum message size is available for BGP while adhering to the guidelines in Section 9.2 of RFC 4271 [RFC4271].
BGP更新的当前最大消息大小为4096个八位字节。IETF正在努力将其扩展到更大的规模[BGP Ext Msg]。BGPsec将遵守RFC 4271[RFC4271]第9.2节中的指南，同时遵守BGP可用的任何最大消息大小。
Note: Estimates for the average and maximum sizes anticipated for BGPsec update messages are provided in [MsgSize].
注：预计BGPsec更新消息的平均和最大大小的估计值在[MsgSize]中提供。
If a BGPsec-capable router needs to temporarily suspend/defer signing and/or validation of BGPsec updates during periods of route processor overload, the router may do so even though such suspension/deferment is not desirable; the specification does not forbid it. Following any temporary suspension, the router should subsequently send signed updates corresponding to the updates for which validation and signing were skipped. The router also may choose to skip only validation but still sign and forward updates during periods of congestion.
如果具有BGPsec能力的路由器需要在路由处理器过载期间临时挂起/延迟BGPsec更新的签名和/或验证，则即使这种挂起/延迟是不可取的，路由器也可以这样做；规范并没有禁止这样做。在任何临时暂停之后，路由器应随后发送与跳过验证和签名的更新相对应的签名更新。路由器还可以选择仅跳过验证，但在拥塞期间仍对更新进行签名和转发。
In some situations, a BGPsec router may be unable to keep up with the workload of performing signing and/or validation. This can happen, for example, during BGP session recovery when a router has to send the entire routing table to a recovering router in a neighboring AS (see [CPUworkload]). So, it is possible that a BGPsec router temporarily pauses performing the validation or signing of updates. When the workload eases, the BGPsec router should clear the validation or signing backlog and send signed updates corresponding to the updates for which validation and signing were skipped. During periods of overload, the router may simply send unsigned updates (with signatures dropped) or may sign and forward the updates with signatures (even though the router itself has not yet verified the signatures it received).
在某些情况下，BGPsec路由器可能无法跟上执行签名和/或验证的工作量。例如，在BGP会话恢复期间，当路由器必须将整个路由表发送到相邻AS中的恢复路由器时，可能会发生这种情况（请参见[CPUworkload]）。因此，BGPsec路由器可能会暂时暂停执行更新验证或签名。当工作负载减轻时，BGPsec路由器应清除验证或签名积压，并发送与跳过验证和签名的更新相对应的签名更新。在过载期间，路由器可能只发送未签名的更新（签名已删除），或者可以签名并转发带有签名的更新（即使路由器本身尚未验证其收到的签名）。
A BGPsec-capable AS may request (out of band) that a BGPsec-capable peer AS never downgrade a signed update to an unsigned update. However, in partial-deployment scenarios, it is not possible for a BGPsec router to require a BGPsec-capable eBGP peer to send only signed updates, except for prefixes originated by the peer's AS.
支持BGPsec的AS可能会请求（带外）支持BGPsec的对等AS从不将签名更新降级为未签名更新。但是，在部分部署场景中，BGPsec路由器不可能要求支持BGPsec的eBGP对等方仅发送签名更新，但由对等方AS发出的前缀除外。
Note: If BGPsec has not been negotiated with a peer, then a BGPsec router forwards only unsigned updates to that peer; the sending router does so by following the reconstruction procedure in Section 4.4 of [RFC8205] to generate an AS_PATH attribute corresponding to the BGPsec_PATH attribute in a received signed update. If the above-mentioned temporary suspension is ever applied, then the same AS_PATH reconstruction procedure should be utilized.
注意：如果BGPsec未与对等方协商，则BGPsec路由器仅将未签名的更新转发给该对等方；发送路由器通过遵循[RFC8205]第4.4节中的重建过程来生成与接收到的签名更新中的BGPsec_路径属性相对应的AS_路径属性。如果应用了上述临时暂停，则应使用与_路径重建相同的程序。
No attempt will be made in the BGPsec design to prevent downgrade attacks, i.e., a BGPsec-capable router sending unsigned updates when it is capable of sending signed updates.
BGPsec设计中不会试图防止降级攻击，即，支持BGPsec的路由器在能够发送签名更新时发送未签名更新。
BGPsec allows routers to temporarily suspend signing updates (see Section 5.4). Therefore, it would be contradictory if we were to try to incorporate in the BGPsec protocol a way to detect and reject downgrade attacks. One proposed way to detect downgrade attacks was considered, based on signed peering registrations (see Section 9.5).
BGPsec允许路由器暂时挂起签名更新（参见第5.4节）。因此，如果我们试图在BGPsec协议中加入一种检测和拒绝降级攻击的方法，这将是自相矛盾的。考虑了一种基于签名对等注册的检测降级攻击的方法（见第9.5节）。
It was decided that during capability negotiation, the address family for which the BGPsec speaker is advertising support for BGPsec will be shared using the Address Family Identifier (AFI). Initially, two address families would be included, namely, IPv4 and IPv6. BGPsec for use with other address families may be specified in the future. Simultaneous use of the two (i.e., IPv4 and IPv6) address families for the same BGPsec session will require that the BGPsec speaker include two instances of this capability (one for each address family) during BGPsec capability negotiation.
经决定，在能力协商期间，BGPsec发言人宣传支持BGPsec的地址系列将使用地址系列标识符（AFI）共享。最初，将包括两个地址系列，即IPv4和IPv6。将来可能会指定用于其他地址系列的BGPsec。在同一BGPsec会话中同时使用两个（即IPv4和IPv6）地址族将要求BGPsec演讲者在BGPsec能力协商期间包括该能力的两个实例（每个地址族一个）。
If new address families are supported in the future, they will be added in future versions of the specification. A comment was made that too many version numbers are bad for interoperability. Renegotiation on the fly to add a new address family (i.e., without changeover to a new version number) is desirable.
如果将来支持新的地址族，则将在规范的未来版本中添加它们。有人评论说，过多的版本号不利于互操作性。需要动态重新协商以添加新的地址系列（即不转换为新版本号）。
BGPsec will be incrementally deployable. BGPsec routers will use capability negotiation to agree to run BGPsec between them. If a BGPsec router's peer does not agree to run BGPsec, then the BGPsec router will run only traditional BGP with that peer, i.e., it will not send BGPsec (i.e., signed) updates to the peer.
BGPsec将以增量方式部署。BGPsec路由器将使用能力协商来同意在它们之间运行BGPsec。如果BGPsec路由器的对等方不同意运行BGPsec，则BGPsec路由器将仅与该对等方运行传统BGP，即不会向对等方发送BGPsec（即签名）更新。
Note: See Section 7.9 of [RFC8205] for a discussion of incremental / partial-deployment considerations. Also, Section 6 of [RFC8207] describes how edge sites (stub ASes) can sign updates that they originate but can receive only unsigned updates. This facilitates a less expensive upgrade to BGPsec in resource-limited stub ASes and expedites incremental deployment.
注：有关增量/部分部署注意事项的讨论，请参见[RFC8205]第7.9节。此外，[RFC8207]第6节描述了边缘站点（存根ASE）如何对其发起的更新进行签名，但只能接收未签名的更新。这有助于在资源有限的情况下以较低的成本升级到BGPsec，并加快增量部署。
The partial-deployment approach to incremental deployment will result in "BGPsec islands". Updates that originate within a BGPsec island will generally propagate with signed AS paths to the edges of that island. As BGPsec adoption grows, the BGPsec islands will expand outward (subsuming non-BGPsec portions of the Internet) and/or pairs of islands may join to form larger BGPsec islands.
增量部署的部分部署方法将导致“BGPsec孤岛”。在BGPsec孤岛内发起的更新通常会以有符号AS路径传播到该孤岛的边缘。随着BGPsec应用的增长，BGPsec孤岛将向外扩展（包括互联网的非BGPsec部分），和/或成对的孤岛可能会合并形成更大的BGPsec孤岛。
"Partial path signing" means that a BGPsec AS can be permitted to sign an update that was received unsigned from a downstream neighbor. That is, the AS would add its ASN to the AS path and sign the (previously unsigned) update to other neighboring (upstream) BGPsec ASes.
“部分路径签名”是指允许BGPsec AS对从下游邻居收到的未签名更新进行签名。也就是说，AS会将其ASN添加到AS路径，并将（先前未签名的）更新签名到其他相邻（上游）BGPsec ASE。
It was decided that partial path signing in BGPsec will not be allowed. A BGPsec update must be fully signed, i.e., each AS in the AS path must sign the update. So, in a signed update, there must be a signature corresponding to each AS in the AS path.
已决定不允许在BGPsec中进行部分路径签名。BGPsec更新必须完全签名，即AS路径中的每个AS都必须对更新进行签名。因此，在签名更新中，必须有一个签名对应于AS路径中的每个AS。
Partial path signing (as described above) implies that the AS path is not rigorously protected. Rigorous AS path protection is a key requirement of BGPsec [RFC7353]. Partial path signing clearly reintroduces the following attack vulnerability: if a BGPsec speaker is allowed to sign an unsigned update and if signed (i.e., partially or fully signed) updates would be preferred over unsigned updates, then a faulty, misconfigured, or subverted BGPsec speaker can manufacture any unsigned update it wants (by inserting a valid origin AS) and add a signature to it to increase the chance that its update will be preferred.
部分路径签名（如上所述）意味着as路径没有得到严格保护。严格的AS路径保护是BGPsec[RFC7353]的关键要求。部分路径签名显然会重新引入以下攻击漏洞：如果允许BGPsec扬声器对未签名更新进行签名，并且如果签名（即部分或完全签名）更新优于未签名更新，则错误、配置错误或被颠覆的BGPsec扬声器可以制造其想要的任何未签名更新（通过插入有效的源代码）并向其添加签名，以增加首选其更新的机会。
6.5. Consideration of Stub ASes with Resource Constraints: Encouraging Early Adoption
6.5. 考虑资源有限的问题：鼓励尽早采用
The protocol permits each pair of BGPsec-capable ASes to asymmetrically negotiate the use of BGPsec. Thus, a stub AS (or downstream customer AS) can agree to perform BGPsec only in the transmit direction and speak traditional BGP in the receive direction. In this arrangement, the ISP's (upstream) AS will not send signed updates to this stub or customer AS. Thus, the stub AS can avoid the need to hardware-upgrade its route processor and RIB memory to support BGPsec update validation.
该协议允许每对具有BGPsec能力的ASE不对称协商BGPsec的使用。因此，存根AS（或下游客户AS）可以同意仅在发送方向上执行BGPsec，而在接收方向上使用传统BGP。在这种安排下，ISP的（上游）AS不会向此存根或客户AS发送签名更新。因此，存根AS可以避免硬件升级其路由处理器和RIB内存以支持BGPsec更新验证。
Various other options were also considered for accommodating a resource-constrained stub AS, as discussed below:
还考虑了各种其他选项来容纳资源受限的存根，如下所述：
1. An arrangement that can be effected outside of the BGPsec specification is as follows. Through a private arrangement (invisible to other ASes), an ISP's AS (upstream AS) can truncate the stub AS (or downstream AS) from the path and sign the update as if the prefix is originating from the ISP's AS (even though the update originated unsigned from the customer AS). This way, the path will appear fully signed to the rest of the network. This alternative will require the owner of the prefix at the stub AS to issue a ROA for the upstream AS, so that the upstream AS is authorized to originate routes for the prefix.
1. 可在BGPsec规范之外实施的安排如下。通过私人安排（对其他AS不可见），ISP的AS（上游AS）可以从路径截断存根AS（或下游AS），并对更新进行签名，就像前缀源自ISP的AS一样（即使更新源于未经客户AS签名的更新）。这样，路径将对网络的其余部分显示为完全签名。此替代方案将要求存根AS处前缀的所有者为上游AS颁发ROA，以便上游AS被授权为前缀发起路由。
2. Another type of arrangement that can also be effected outside of the BGPsec specification is as follows. The stub AS does not sign updates, but it obtains an RPKI (CA) certificate and issues a router certificate under that CA certificate. It passes on the private key for the router certificate to its upstream provider.
2. 在BGPsec规范之外也可能影响的另一种安排类型如下。存根AS不会对更新进行签名，但会获得RPKI（CA）证书，并在该CA证书下颁发路由器证书。它将路由器证书的私钥传递给其上游提供商。
That ISP (i.e., the second-hop AS) would insert a signature on behalf of the stub AS using the private key obtained from the stub AS. This arrangement is called "proxy signing" (see Section 6.6).
该ISP（即第二跳AS）将使用从存根AS获得的私钥代表存根AS插入签名。这种安排称为“代理签名”（见第6.6节）。
3. An extended ROA is created that includes the stub AS as the originator of the prefix and the upstream provider as the second-hop AS, and partial signatures would be allowed (i.e., the stub AS need not sign the updates). It is recognized that this approach is also authoritative and not trust based. It was observed that the extended ROA is not much different from what is done with the ROA (in its current form) when a Provider-Independent (PI) address is originated from a provider's AS. This approach was rejected due to possible complications with the creation and use of a new RPKI object, namely, the extended ROA. Also, the validating BGPsec router has to perform a level of indirection with this approach, i.e., it must detect that an update is not fully signed and then look for the extended ROA to validate.
3. 创建一个扩展的ROA，其中包括作为前缀发起人的存根AS和作为第二跳AS的上游提供者，并且允许部分签名（即存根AS不需要对更新进行签名）。人们认识到，这种方法也是权威性的，不是基于信任的。据观察，当独立于提供商的（PI）地址源自提供商的AS时，扩展ROA与ROA（以其当前形式）的操作没有太大区别。由于创建和使用新的RPKI对象（即扩展ROA）可能会出现复杂情况，因此拒绝使用此方法。此外，验证BGPsec路由器必须使用这种方法执行一定程度的间接寻址，即，它必须检测到更新未完全签名，然后寻找扩展ROA进行验证。
4. Another method, based on a different form of indirection, would be as follows. The customer (stub) AS registers something like a Proxy Signer Authorization, which authorizes the second-hop (i.e., provider) AS to sign on behalf of the customer AS using the provider's own key [Dynamics]. This method allows for fully signed updates (unlike the approach based on the extended ROA). But this approach also requires the creation of a new RPKI object, namely, the Proxy Signer Authorization. In this approach, the second-hop AS and validating ASes have to perform a level of indirection. This approach was also rejected.
4. 另一种基于不同形式间接寻址的方法如下。客户（存根）AS注册类似于代理签名者授权的内容，授权第二个跃点（即提供商）AS使用提供商自己的密钥[Dynamics]代表客户签名。此方法允许完全签名的更新（与基于扩展ROA的方法不同）。但这种方法还需要创建一个新的RPKI对象，即代理签名者授权。在这种方法中，第二跳AS和验证AS必须执行一定级别的间接寻址。这种做法也遭到拒绝。
The various inputs regarding ISP preferences were taken into consideration, and eventually the decision in favor of asymmetric BGPsec was reached (Section 6.5.1). An advantage for a stub AS that does asymmetric BGPsec is that it only needs to minimally upgrade to BGPsec so it can sign updates to its upstream AS while it receives only unsigned updates. Thus, it can avoid the cost of increased processing and memory needed to perform update validations and to store signed updates in the RIBs, respectively.
考虑了与ISP偏好有关的各种输入，最终做出了有利于不对称BGPsec的决定（第6.5.1节）。存根与非对称BGPsec一样的一个优点是，它只需要最低限度地升级到BGPsec，这样它就可以对其上游的更新进行签名，而只接收未签名的更新。因此，它可以避免分别执行更新验证和在RIB中存储签名更新所需的增加的处理和内存的成本。
An ISP's AS (or upstream AS) can proxy-sign BGP announcements for a customer (downstream) AS, provided that the customer AS obtains an RPKI (CA) certificate, issues a router certificate under that CA certificate, and passes on the private key for that certificate to
ISP的AS（或上游AS）可以代理签署客户（下游AS）的BGP公告，前提是客户AS获得RPKI（CA）证书，在该CA证书下颁发路由器证书，并将该证书的私钥传递给
its upstream provider. That ISP (i.e., the second-hop AS) would insert a signature on behalf of the customer AS using the private key provided by the customer AS. This is a private arrangement between the two ASes and is invisible to other ASes. Thus, this arrangement is not part of the BGPsec protocol specification.
它的上游供应商。该ISP（即第二跳AS）将使用客户AS提供的私钥代表客户AS插入签名。这是两个ASE之间的私人安排，其他ASE看不到。因此，这种安排不是BGPsec协议规范的一部分。
BGPsec will not make any special provisions for an ISP to use its own private key to proxy-sign updates for a customer's AS. This type of proxy signing is considered a bad idea.
BGPsec不会对ISP使用自己的私钥为客户的AS代理签名更新做出任何特殊规定。这种类型的代理签名被认为是个坏主意。
Consider a scenario when a customer's AS (say, AS8) is multihomed to two ISPs, i.e., AS8 peers with AS1 and AS2 of ISP-1 and ISP-2, respectively. In this case, AS8 would have an RPKI (CA) certificate; it issues two separate router certificates (corresponding to AS1 and AS2) under that CA certificate, and it passes on the respective private keys for those two certificates to its upstream providers AS1 and AS2. Thus, AS8 has a proxy-signing service from both of its upstream ASes. In the future, if AS8 were to disconnect from ISP-2, then it would revoke the router certificate corresponding to AS2.
考虑一个场景，当客户AS（例如，AS8）被复用到两个ISP时，即AS8和ASP1和ASP2的AS8节点。在这种情况下，AS8将拥有RPKI（CA）证书；它在该CA证书下颁发两个单独的路由器证书（对应于AS1和AS2），并将这两个证书的各自私钥传递给其上游提供商AS1和AS2。因此，AS8具有来自其两个上游ASE的代理签名服务。将来，如果AS8与ISP-2断开连接，那么它将撤销与AS2对应的路由器证书。
No problems are anticipated when BGPsec-capable ASes have multiple peering sessions between them (between distinct routers).
当支持BGPsec的ASE之间（不同路由器之间）有多个对等会话时，预计不会出现任何问题。
In traditional BGP, multiple peering sessions between different pairs of routers (between two neighboring ASes) may be simultaneously used for load sharing. Similarly, BGPsec-capable ASes can also have multiple peering sessions between them. Because routers in an AS can have distinct private keys, the same update, when propagated over these multiple peering sessions, will result in multiple updates that may differ in their signatures. The peer (upstream) AS will apply its normal procedures for selecting a best path from those multiple updates (and updates from other peers).
在传统BGP中，不同路由器对之间（两个相邻ASE之间）的多个对等会话可同时用于负载共享。类似地，支持BGPsec的ASE之间也可以有多个对等会话。由于AS中的路由器可能具有不同的私钥，因此当通过这些多个对等会话传播相同的更新时，将导致多个更新，这些更新的签名可能不同。对等方（上游）AS将应用其正常程序从这些多个更新（以及其他对等方的更新）中选择最佳路径。
This decision regarding load balancing (vs. using one peering session as the primary for carrying data and another as the backup) is entirely local and is up to the two neighboring ASes.
关于负载平衡的决定（与使用一个对等会话作为承载数据的主会话和另一个作为备份）完全是本地的，由两个相邻的ASE决定。
In traditional BGP, the idea of peer groups is used in BGP routers to save on processing when generating and sending updates. Multiple peers for whom the same policies apply can be organized into peer groups. A peer group can typically have tens of ASes (and maybe as many as 300) in it.
在传统的BGP中，在BGP路由器中使用对等组的思想，以节省生成和发送更新时的处理时间。可以将应用相同策略的多个对等方组织为对等组。一个对等组通常可以有几十个ASE（可能多达300个）。
It was decided that BGPsec updates are generated to target unique AS peers, so there is no support for peer groups in BGPsec.
已决定生成BGPsec更新以将unique作为对等对象，因此BGPsec中不支持对等组。
BGPsec router processing can make use of peer groups preceding the signing of updates to peers. Some of the update processing prior to forwarding to members of a peer group can be done only once per update, as is done in traditional BGP. Prior to forwarding the update, a BGPsec speaker adds the peer's ASN to the data that needs to be signed and signs the update for each peer AS in the group individually.
BGPsec路由器处理可以在向对等方签署更新之前使用对等方组。在转发给对等组成员之前，某些更新处理在每次更新中只能执行一次，这与传统BGP中的做法相同。在转发更新之前，BGPsec发言人会将对等方的ASN添加到需要签名的数据中，并对组中的每个对等方的更新分别签名。
If updates were to be signed per peer group, information about the forward AS set that constitutes a peer group would have to be divulged (since the ASN of each peer would have to be included in the update). Some ISPs do not like to share this kind of information globally.
如果要对每个对等组的更新进行签名，则必须泄露有关构成对等组的转发AS集的信息（因为每个对等组的ASN都必须包含在更新中）。一些ISP不喜欢在全球范围内共享此类信息。
The need to provide protection in BGPsec for the community attribute was discussed.
讨论了在BGPsec中为社区属性提供保护的必要性。
Community attribute(s) will not be included in any message that is signed in BGPsec.
在BGPsec中签名的任何消息中都不会包含社区属性。
From a security standpoint, the community attribute, as currently defined, may be inherently defective. A substantial amount of work on the semantics of the community attribute is needed, and additional work on its security aspects also needs to be done. The community attribute is not necessarily transitive; it is often used only
从安全角度来看，当前定义的社区属性可能存在固有缺陷。在社区属性的语义方面需要做大量的工作，在其安全方面也需要做更多的工作。社区属性不一定是可传递的；它通常只被使用
between neighbors. In those contexts, transport-security mechanisms suffice to provide integrity and authentication. (There is no need to sign data when it is passed only between peers.) It was suggested that one could include only the transitive community attributes in any message that is signed and propagated (across the AS path). It was noted that there is a flag available (i.e., unused) in the community attribute, and it might be used by BGPsec (in some fashion). However, little information is available at this point about the use and function of this flag. It was speculated that this flag could potentially be used to indicate to BGPsec whether or not the community attribute needs protection. For now, community attributes will not be secured by BGPsec path signatures.
邻居之间。在这些环境中，传输安全机制足以提供完整性和身份验证。（当数据仅在对等方之间传递时，不需要对其进行签名。）有人建议，在任何经过签名和传播（通过AS路径）的消息中，只能包含可传递的社区属性。需要注意的是，社区属性中有一个可用（即未使用）的标志，BGPsec可能（以某种方式）使用该标志。但是，目前关于此标志的使用和功能的信息很少。据推测，该标志可能用于向BGPsec指示社区属性是否需要保护。目前，BGPsec路径签名不会保护社区属性。
An iBGP speaker that is also an eBGP speaker and that executes BGPsec will by necessity carry BGPsec data and perform eBGPsec functions. Confederations are eBGP clouds for administrative purposes and contain multiple Member-ASes. A Member-AS is not required to sign updates sent to another Member-AS within the same confederation. However, if BGPsec signing is applied in eBGP within a confederation, i.e., each Member-AS signs to the next Member-AS in the path within the confederation, then upon egress from the confederation, the Member-AS at the boundary must remove any and all signatures applied within the confederation. The Member-AS at the boundary of the confederation will sign the update to an eBGPsec peer using the public ASN of the confederation and its private key. The BGPsec specification will not specify how to perform this process.
同时也是eBGP扬声器并执行BGPsec的iBGP扬声器必须携带BGPsec数据并执行eBGPsec功能。联合会是出于管理目的的eBGP云，包含多个成员ASE。成员AS无需签署发送给同一联盟内其他成员的更新。但是，如果BGPsec签名应用于联邦内的eBGP中，即每个成员作为下一个成员的签名应用于联邦内的路径中，则在离开联邦时，边界处的成员必须移除联邦内应用的任何和所有签名。位于联盟边界的成员将使用联盟的公共ASN及其私钥向eBGPsec对等方签署更新。BGPsec规范不会指定如何执行此过程。
Note: In RFC 8205, signing a BGPsec update between Member-ASes within a confederation is required if the update were to propagate with signatures within the confederation. A Confed_Segment flag exists in each Secure_Path segment, and when set, it indicates that the corresponding signature belongs to a Member-AS. At the confederation boundary, all signatures with Confed_Segment flags set are removed from the update. RFC 8205 specifies in detail how all of this is done. Please see Figure 5 in Section 3.1 of [RFC8205], as well as Section 4.3 of [RFC8205], for details.
注意：在RFC 8205中，如果更新要在联盟内通过签名传播，则需要在联盟内的成员ASE之间签署BGPsec更新。每个安全路径段中都存在一个Confed_段标志，设置该标志时，它表示相应的签名属于成员AS。在联邦边界处，设置了Confed_段标志的所有签名将从更新中删除。RFC 8205详细说明了如何完成所有这一切。有关详细信息，请参见[RFC8205]第3.1节中的图5以及[RFC8205]第4.3节。
This topic may need to be revisited to flesh out the details carefully.
可能需要重新讨论这个主题，以仔细充实细节。
[BGPsec-Initial] made no special provisions to accommodate route servers in Internet Exchange Points (IXPs).
[BGPsec Initial]未对互联网交换点（IXP）中的路由服务器作出特殊规定。
Note: The above decision subsequently changed: RFC 8205 allows the accommodation of IXPs, especially for transparent route servers. The pCount (AS prepend count) field is set to zero for transparent route servers (see Section 4.2 of [RFC8205]). The operational guidance for preventing the misuse of pCount=0 is given in Section 7.2 of RFC 8205. Also, see Section 8.4 of RFC 8205 for a discussion of security considerations concerning pCount=0.
注：上述决定随后更改：RFC 8205允许容纳IXP，尤其是透明路由服务器。对于透明路由服务器，pCount（作为前置计数）字段设置为零（参见[RFC8205]第4.2节）。RFC 8205第7.2节给出了防止pCount=0误用的操作指南。此外，有关pCount=0的安全注意事项的讨论，请参见RFC 8205第8.4节。
There are basically three methods that an IXP may use to propagate routes: (A) direct bilateral peering through the IXP, (B) BGP peering between clients via peering with a route server at the IXP (without the IXP inserting its ASN in the path), and (C) BGP peering with an IXP route server, where the IXP inserts its ASN in the path. (Note: The IXP's route server does not change the NEXT_HOP attribute even if it inserts its ASN in the path.) It is very rare for an IXP to use Method C because it is less attractive for the clients if their AS path length increases by one due to the IXP. A measure of the extent of the use of Method A vs. Method B is given in terms of the corresponding IP traffic load percentages. As an example, at a major European IXP, these percentages are about 80% and 20% for Methods A and B, respectively (this data is based on private communication with IXPs circa 2011). However, as the IXP grows (in terms of number of clients), it tends to migrate more towards Method B because of the difficulties of managing up to n x (n-1)/2 direct interconnections between n peers in Method A.
IXP基本上可以使用三种方法来传播路由：（A）通过IXP进行直接双边对等，（B）通过与IXP上的路由服务器进行对等，在客户端之间进行BGP对等（无需IXP在路径中插入其ASN），以及（C）与IXP路由服务器进行BGP对等，其中IXP在路径中插入其ASN。（注意：即使IXP在路径中插入其ASN，IXP的路由服务器也不会更改NEXT_-HOP属性。）IXP很少使用方法C，因为如果其AS路径长度因IXP而增加1，则对客户端的吸引力会降低。根据相应的IP流量负载百分比，给出了方法A与方法B使用程度的度量。例如，在一个主要的欧洲IXP中，方法a和方法B的这些百分比分别约为80%和20%（该数据基于2011年左右与IXP的私人通信）。然而，随着IXP的增长（就客户端数量而言），它倾向于更多地向方法B迁移，因为在方法A中管理n个对等点之间多达nx（n-1）/2个直接互连的困难。
To the extent that an IXP is providing direct bilateral peering between clients (Method A), that model works naturally with BGPsec. Also, if the route server in the IXP plays the role of a regular BGPsec speaker (minus the routing part for payload) and inserts its own ASN in the path (Method C), then that model would also work well in the BGPsec Internet and this case is trivially supported in BGPsec.
就IXP提供客户端之间的直接双边对等（方法A）而言，该模型自然适用于BGPsec。此外，如果IXP中的路由服务器扮演常规BGPsec演讲者的角色（减去有效负载的路由部分），并在路径中插入其自己的ASN（方法C），那么该模型在BGPsec互联网中也能很好地工作，这种情况在BGPsec中不受支持。
Proxy aggregation (i.e., the use of AS_SETs in the AS path) will not be supported in BGPsec. There is no provision in BGPsec to sign an update when an AS_SET is part of an AS path. If a BGPsec-capable router receives an update that contains an AS_SET and also finds that the update is signed, then the router will consider the update malformed (i.e., a protocol error).
BGPsec不支持代理聚合（即在AS路径中使用AS_集）。当AS_集是AS路径的一部分时，BGPsec中没有对更新进行签名的规定。如果一个具有BGPSEC能力的路由器接收到一个包含ASSUSET的更新，并且还发现更新是签名的，那么路由器将考虑更新错误（即，协议错误）。
Note: Section 5.2 of RFC 8205 specifies that a receiving BGPsec router "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]."
注：RFC 8205第5.2节规定，接收BGPsec路由器“必须使用RFC 7606[RFC7606]中定义的“视为撤回”方法处理BGPsec_路径属性中的任何语法或协议错误。”
Proxy aggregation does occur in the Internet today, but it is very rare. Only a very small fraction (about 0.1%) of observed updates contain AS_SETs in the AS path [ASset]. Since traditional BGP currently allows for proxy aggregation with the inclusion of AS_SETs in the AS path, it is necessary that BGPsec specify what action a receiving router must take if such an update is received with attestation. BCP 172 [RFC6472] recommends against the use of AS_SETs in updates, so it is anticipated that the use of AS_SETs will diminish over time.
代理聚合确实出现在今天的互联网上，但非常罕见。只有一小部分（约0.1%）观测到的更新在AS路径[ASset]中包含AS_集。由于传统的BGP目前允许在AS路径中包含AS_集的情况下进行代理聚合，因此BGPsec有必要指定接收路由器在通过认证接收此类更新时必须采取的操作。BCP 172[RFC6472]建议不要在更新中使用AS_集，因此预计AS_集的使用将随着时间的推移而减少。
Not all (currently deployed) BGP speakers are capable of dealing with 4-byte ASNs [RFC6793]. The standard mechanism used to accommodate such speakers requires a peer AS to translate each 4-byte ASN in the AS path to a reserved 2-byte ASN (23456) before forwarding the update. This mechanism is incompatible with the use of BGPsec, since the ASN translation is equivalent to a route modification attack and will cause signatures corresponding to the translated 4-byte ASNs to fail validation.
并非所有（当前部署的）BGP扬声器都能够处理4字节ASN[RFC6793]。用于容纳此类扬声器的标准机制要求对等AS在转发更新之前将AS路径中的每个4字节ASN转换为保留的2字节ASN（23456）。此机制与BGPsec的使用不兼容，因为ASN转换相当于路由修改攻击，并将导致与转换的4字节ASN对应的签名无法通过验证。
BGP speakers that are BGPsec capable are required to process 4-byte ASNs.
支持BGPsec的BGP扬声器需要处理4字节ASN。
It is reasonable to assume that upgrades for 4-byte ASN support will be in place prior to the deployment of BGPsec.
可以合理地假设，4字节ASN支持的升级将在部署BGPsec之前到位。
It is natural to ask in what sequence a receiver must perform BGPsec update validation so that if a failure were to occur (i.e., the update was determined to be invalid) the processor would have spent the least amount of processing or other resources.
询问接收者必须以何种顺序执行BGPsec更新验证是很自然的，这样，如果发生故障（即，更新被确定为无效），处理器将花费最少的处理或其他资源。
There was agreement that the following sequence of receiver operations is quite meaningful; the following steps are included in [BGPsec-Initial]. However, the ordering of these validation-processing steps is not a normative part of the BGPsec specification.
与会者一致认为，以下接收器操作序列非常有意义；以下步骤包含在[BGPsec初始版本]中。然而，这些验证处理步骤的顺序不是BGPsec规范的规范性部分。
1. Verify that the signed update is syntactically correct. For example, check to see if the number of signatures matches the number of ASes in the AS path (after duly accounting for AS prepending).
1. 验证签名的更新在语法上是否正确。例如，检查签名的数量是否与AS路径中的ASE数量匹配（在适当考虑AS预结束后）。
2. Verify that the origin AS is authorized to advertise the prefix in question. This verification is based on data from ROAs and does not require any cryptographic operations.
2. 验证源AS是否有权公布相关前缀。此验证基于来自ROA的数据，不需要任何加密操作。
3. Verify that the advertisement has not yet expired.
3. 确认广告尚未过期。
4. Verify that the target ASN in the signature data matches the ASN of the router that is processing the advertisement. Note that the target-ASN check is also a non-cryptographic operation and is fast.
4. 验证签名数据中的目标ASN是否与处理播发的路由器的ASN匹配。请注意，目标ASN检查也是一种非加密操作，速度很快。
5. Validate the signature data starting from the most recent AS to the origin.
5. 验证从最新开始到原点的签名数据。
6. Locate the public key for the router from which the advertisement was received, using the SKI from the signature data.
6. 使用签名数据中的SKI查找接收广告的路由器的公钥。
7. Hash the data covered by the signature algorithm. Invoke the signature validation algorithm on the following three inputs: the locally computed hash, the received signature, and the public key. There will be one output: valid or invalid.
7. 散列签名算法覆盖的数据。对以下三个输入调用签名验证算法：本地计算的哈希、接收到的签名和公钥。将有一个输出：有效或无效。
8. Repeat steps 5 and 6 for each preceding signature in the Signature_Block until (a) the signature data for the origin AS is encountered and processed or (b) either of these steps fails.
8. 对signature_块中前面的每个签名重复步骤5和6，直到（a）遇到并处理了源的签名数据或（b）这些步骤中的任何一个失败。
Note: Significant refinements to the above list occurred in the progress towards RFC 8205. The detailed syntactic-error checklist is presented and explained in Section 5.2 of [RFC8205]. Also, a logical sequence of steps to be followed in the validation of Signature_Blocks is described in Section 5.2 of [RFC8205].
注：在实现RFC 8205的过程中，对上述清单进行了重大改进。[RFC8205]第5.2节介绍并解释了详细的语法错误检查表。此外，[RFC8205]第5.2节中描述了验证签名块时应遵循的逻辑步骤序列。
If the goal is to minimize computational costs associated with cryptographic operations, the sequence of receiver operations that is suggested above is viewed as appropriate. One additional interesting suggestion was that when there are two Signature_Blocks in an update, the validating router can first verify which of the two algorithms is cheaper, to save on processing. If that Signature_Block verifies, then the router can skip validating the other Signature_Block.
如果目标是最小化与密码操作相关的计算成本，则认为上面建议的接收器操作序列是适当的。另一个有趣的建议是，当更新中有两个签名块时，验证路由器可以首先验证这两种算法中哪一种更便宜，以节省处理时间。如果该签名块被验证，那么路由器可以跳过验证另一个签名块。
A BGPsec router should sign and forward a signed update to upstream peers if it selected the update as the best path, regardless of whether the update passed or failed validation (at this router).
如果BGPsec路由器选择更新作为最佳路径，则该路由器应签署已签署的更新并将其转发给上游对等方，无论更新是否通过验证（在此路由器上）。
The availability of RPKI data at different routers (in the same AS or different ASes) may differ, depending on the sources used to acquire RPKI data. Hence, an update may fail validation in one AS, and the same update may pass validation in another AS. Also, an update may fail validation at one router in an AS, and the same update may pass validation at another router in the same AS.
根据用于获取RPKI数据的来源，不同路由器（在相同或不同的ASE中）的RPKI数据可用性可能不同。因此，一个更新可能会在一个AS中验证失败，而同一个更新可能会在另一个AS中通过验证。此外，更新可能会在AS中的一个路由器上验证失败，并且同一更新可能会在AS中的另一个路由器上通过验证。
A BCP may be published later that will identify some update-failure conditions that may present unambiguous cases for rejecting the update (in which case the router would not select the AS path in the update). These cases are "TBD" (to be determined).
稍后可能会发布BCP，该BCP将识别一些更新失败条件，这些条件可能会出现拒绝更新的明确情况（在这种情况下，路由器不会在更新中选择AS路径）。这些情况为“待定”（待定）。
Enumeration of error conditions and the recommendations for how to react to them are still under discussion.
错误条件的列举以及如何应对的建议仍在讨论中。
TBD. Also, please see Section 8.5 for the decision and discussion specifically related to syntactic errors in signatures.
待定。此外，请参见第8.5节，了解与签名中语法错误相关的决定和讨论。
Note: Section 5.2 of RFC 8205 describes the detection of syntactic and protocol errors in BGPsec updates as well as how the updates with such errors are to be handled.
注：RFC 8205第5.2节描述了BGPsec更新中语法和协议错误的检测，以及如何处理出现此类错误的更新。
The following list is a first attempt to provide some possible error conditions and recommended receiver reactions in response to the detection of those errors. Refinements will follow after further discussions.
下面的列表是首次尝试提供一些可能的错误条件，以及针对这些错误的检测建议的接收器反应。在进一步讨论之后，将进行改进。
E1 Abnormalities where a peer (i.e., the preceding AS) should definitely not have propagated to a receiving eBGPsec router. For example, (A) the number of signatures does not match the number of ASes in the AS path (after accounting for AS prepending), (B) there is an AS_SET in the received update and the update has signatures, or (C) other syntactic errors with signatures have occurred.
E1异常，其中对等方（即前面的AS）绝对不应该传播到接收eBGPsec路由器。例如，（A）签名的数量与AS路径中ASE的数量不匹配（在考虑AS前缀之后），（B）接收到的更新中设置了AS_，并且更新有签名，或者（C）签名出现了其他语法错误。
Reaction: See Section 8.5.
反应：见第8.5节。
E2 Situations where a receiving eBGPsec router cannot find the certificate for an AS in the AS path.
E2接收eBGPsec路由器无法在AS路径中找到AS的证书的情况。
Reaction: Mark the update as "Invalid". It is acceptable to consider the update in the best-path selection. If it is chosen, then the router should sign and propagate the update.
反应：将更新标记为“无效”。在最佳路径选择中考虑更新是可以接受的。如果选择了它，那么路由器应该签名并传播更新。
E3 Situations where a receiving eBGPsec router cannot find a ROA for the {prefix, origin} pair in the update.
E3接收eBGPsec路由器在更新中找不到{prefix，origin}对的ROA的情况。
Reaction: Same as in (E2) above.
反应：与上述（E2）相同。
E4 Situations where the receiving eBGPsec router verifies signatures and finds that the update is "Invalid" (even though its peer might not have known, e.g., due to RPKI skew).
E4接收eBGPsec路由器验证签名并发现更新“无效”（即使其对等方可能不知道，例如由于RPKI扭曲）的情况。
Reaction: Same as in (E2) above.
反应：与上述（E2）相同。
In some networks, the best-path-selection policy may specify choosing an unsigned update over one with invalid signature(s). Hence, the signatures must not be stripped even if the update is "Invalid". No evil bit is set in the update (when it is "Invalid") because an upstream peer may not get that same answer when it tries to validate.
在某些网络中，最佳路径选择策略可能指定选择未签名的更新而不是签名无效的更新。因此，即使更新“无效”，也不得删除签名。更新中没有设置邪恶位（当它“无效”时），因为上游对等方在尝试验证时可能不会得到相同的答案。
An update may come in unsigned from an eBGP peer or internally (e.g., as an iBGP update). In the latter case, the route is being originated from within the AS in question.
更新可能来自未经签名的eBGP对等方或内部（例如，作为iBGP更新）。在后一种情况下，路由是从所讨论的网络内部发起的。
If an unsigned route is received from an eBGP peer and if it is selected, then the route will be forwarded unsigned to other eBGP peers -- even BGPsec-capable peers. If the route originated in this AS (IGP or iBGP) and is unsigned, then it should be signed and announced to external BGPsec-capable peers.
如果从eBGP对等方接收到未签名的路由，并且选择了该路由，则该路由将被无签名转发给其他eBGP对等方——甚至是支持BGPsec的对等方。如果路由源自此AS（IGP或iBGP）且未签名，则应签名并向支持BGPsec的外部对等方宣布。
It is also possible that an update received in IGP (or iBGP) may have private ASNs in the AS path. These private ASNs would normally appear in the rightmost portion of the AS path. It was noted that in this case the private ASNs to the right would be removed (as done in traditional BGP), and then the update will be signed by the originating AS and announced to BGPsec-capable eBGP peers.
在IGP（或iBGP）中接收的更新也可能在AS路径中有专用ASN。这些专用ASN通常会出现在AS路径的最右侧。需要注意的是，在这种情况下，右侧的专用ASN将被删除（如传统BGP中所做的），然后更新将由原始as签名，并向支持BGPsec的eBGP对等方宣布。
Note: See Section 7.5 of [RFC8205] for operational considerations for BGPsec in the context of private ASNs.
注：参见[RFC8205]第7.5节，了解私人ASN背景下BGPsec的运营注意事项。
8.5. Response to Syntactic Errors in Signatures and Recommendations for How to React to Them
8.5. 对签名中语法错误的响应以及如何应对这些错误的建议
Note: The contents of this subsection (i.e., Section 8.5) differ substantially from the recommendations in RFC 8205 regarding the handling of syntactic errors and protocol errors. Hence, the reader may skip this subsection and instead read Section 5.2 of [RFC8205]. This subsection (Section 8.5) is kept here for the sake of archival value concerning design discussions.
注：本小节（即第8.5节）的内容与RFC 8205中关于处理语法错误和协议错误的建议有很大不同。因此，读者可以跳过本小节，而阅读[RFC8205]的第5.2节。本小节（第8.5节）保留在此处，以便于有关设计讨论的档案价值。
Different types of error conditions were discussed in Section 8.3. Here, the focus is only on syntactic-error conditions in signatures.
第8.3节讨论了不同类型的误差条件。这里，我们只关注签名中的语法错误条件。
If there are syntactic-error conditions such as (A) AS_SET and BGPsec_PATH both appearing in an update, (B) the number of signatures not matching the number of ASes (after accounting for any AS prepending), or (C) a parsing issue occurring with the BGPsec_PATH attribute, then the update (with the signatures stripped) will still be considered in the best-path-selection algorithm. (**Note: This is not true in RFC 8205**.) If the update is selected as the best path, then the update will be propagated unsigned. The error condition will be logged locally.
如果存在语法错误条件，例如（A）as_集和BGPsec_路径都出现在更新中，（B）签名数与ASE数不匹配（在考虑任何as前缀后），或（C）BGPsec_路径属性出现解析问题，则更新（去掉签名）仍将在最佳路径选择算法中考虑。（**注意：这在RFC 8205**中不正确。）如果选择更新作为最佳路径，则更新将无符号传播。错误情况将在本地记录。
A BGPsec router will follow whatever the current IETF (IDR WG) recommendations are for notifying a peer that it is sending malformed messages.
BGPsec路由器将遵循当前IETF（IDR WG）的建议，通知对等方它正在发送格式错误的消息。
In the case when there are two Signature_Blocks in an update, and one or more syntactic errors are found to occur within one of them but the other one is free of any syntactic errors, then the update will still be considered in the best-path-selection algorithm after the syntactically bad Signature_Block has been removed. (**Note: This is not true in RFC 8205**.) If the update is selected as the best path, then the update will be propagated with only one (i.e., the error-free) Signature_Block. The error condition will be logged locally.
如果更新中有两个签名_块，并且发现其中一个出现一个或多个语法错误，但另一个没有任何语法错误，则在移除语法错误的签名_块后，更新仍将在最佳路径选择算法中考虑。（**注意：这在RFC 8205**中不正确。）如果选择更新作为最佳路径，则仅使用一个（即无错误）签名块传播更新。错误情况将在本地记录。
As stated above, a BGPsec router will follow whatever the current IETF (IDR WG) recommendations are for notifying a peer that it is sending malformed messages. Question: If the error is persistent and a full BGP table dump occurs, then would there be 500K such errors resulting in 500K "notify" messages sent to the peer that is generating the errors? Answer: Rate limiting would be applied to the notify messages and should prevent any overload due to these messages.
如上所述，BGPsec路由器将遵循当前IETF（IDR WG）的建议，通知对等方它正在发送格式错误的消息。问题：如果错误持续存在且发生完整的BGP表转储，那么是否会有500K个此类错误导致向生成错误的对等方发送500K条“通知”消息？答：速率限制将应用于通知消息，并应防止由于这些消息而导致的任何过载。
Various validation conditions are possible that can be mapped to validation states for possible input to the BGPsec decision process. These conditions can be related to whether an update is signed, Expire Time is checked, route origin validation is checked against a ROA, signature verification passed, etc.
可以将各种验证条件映射到验证状态，以便为BGPsec决策过程提供可能的输入。这些条件可能与是否签署更新、是否检查过期时间、是否根据ROA检查路由来源验证、是否通过签名验证等有关。
It was decided that BGPsec validation outcomes will be mapped to one of only two validation states: (1) Valid -- passed all validation checks (i.e., Expire Time check, route origin and Signature_Block validation) and (2) Invalid -- all other possibilities. "Invalid" would include situations such as the following:
决定BGPsec验证结果将映射到两种验证状态之一：（1）有效-通过所有验证检查（即过期时间检查、路由来源和签名块验证）和（2）无效-所有其他可能性。“无效”包括以下情况：
1. Due to a lack of RPKI data or insufficient RPKI data, validation was not performed.
1. 由于缺乏RPKI数据或RPKI数据不足，未进行验证。
2. The signature Expire Time check failed.
2. 签名过期时间检查失败。
3. Route origin validation failed.
3. 路由源验证失败。
4. Signature checks were performed, and one or more of them failed.
4. 已执行签名检查，其中一个或多个检查失败。
Note: Expire Time is obsolete (see the notes in Sections 2.2.1 and 2.2.2). RFC 8205 uses the states "Valid" and "Not Valid", but only with respect to AS path validation (i.e., not including the result of origin validation); see Section 5.1 of [RFC8205]. "Not Valid" includes all conditions in which path validation was attempted but a "Valid" result could not be reached. (Note: Path validation is not attempted in the case of syntactic or protocol errors in a BGPsec update; see Section 5.2 of [RFC8205].) Each Relying Party (RP) is expected to devise its own policy to suitably factor the results of origin validation [RFC6811] and path validation [RFC8205] into its path-selection decision.
注：过期时间已过时（见第2.2.1节和第2.2.2节中的注释）。RFC 8205使用状态“有效”和“无效”，但仅针对AS路径验证（即，不包括来源验证的结果）；见[RFC8205]第5.1节。“无效”包括尝试路径验证但无法达到“有效”结果的所有条件。（注：在BGPsec更新中出现语法或协议错误的情况下，不尝试进行路径验证；请参见[RFC8205]第5.2节）。每个依赖方（RP）应制定自己的政策，将来源验证[RFC6811]和路径验证[RFC8205]的结果适当地纳入其路径选择决策中。
It may be noted that the result of update validation is just an additional input for the BGP decision process. The router's local policy ultimately has control over what action (regarding BGP path selection) is taken.
可能需要注意的是，更新验证的结果只是BGP决策过程的额外输入。路由器的本地策略最终可以控制采取的操作（关于BGP路径选择）。
Initially, four validation states were considered:
最初，考虑了四种验证状态：
1. The update is not signed.
1. 更新未签名。
2. The update is signed, but the router does not have corresponding RPKI data to perform a validation check.
2. 更新已签名，但路由器没有相应的RPKI数据来执行验证检查。
3. The validation check was performed, and the check failed (Invalid).
3. 已执行验证检查，检查失败（无效）。
4. The validation check was performed, and the check passed (Valid).
4. 已执行验证检查，检查通过（有效）。
As stated above, it was later decided that BGPsec validation outcomes will be mapped to one of only two validation states. It was observed that an update can be invalid for many different reasons. To begin to differentiate these numerous reasons and to try to enumerate different flavors of the Invalid state will not likely be constructive in route-selection decisions and may even introduce new vulnerabilities in the system. However, some questions remain, such as the following:
如上所述，后来决定BGPsec验证结果将映射到仅有的两个验证状态之一。据观察，由于许多不同的原因，更新可能无效。在路由选择决策中，开始区分这些原因并尝试列举不同类型的无效状态不太可能具有建设性，甚至可能在系统中引入新的漏洞。然而，仍然存在一些问题，例如：
Question: Is there a need to define a separate validation state for the case when an update is not signed but the {prefix, origin} pair matches the ROA information? After some discussion, a tentative conclusion was reached: this is in principle similar to validation based on partial path signing (which was ruled out; see Section 6.4). So, there is no need to add another validation state for this case; treat it as "Invalid", considering that it is unsigned.
问题：当更新未签名，但{prefix，origin}对与ROA信息匹配时，是否需要为这种情况定义单独的验证状态？经过一些讨论，得出了一个初步结论：这在原则上类似于基于部分路径签名的验证（已被排除；见第6.4节）。因此，不需要为这种情况添加另一个验证状态；将其视为“无效”，因为它未签名。
Another remaining question: Would the RP want to give the update a higher preference over another unsigned update that failed origin validation or over a signed update that failed both signature and ROA validation?
剩下的另一个问题是：RP是否希望给更新一个更高的优先级，而不是给另一个未签名的更新一个未通过源验证的优先级，还是给签名的更新一个未通过签名和ROA验证的优先级？
BGPsec validation need be performed only at eBGP edges. The validation status of a BGP signed/unsigned update may be conveyed via iBGP from an ingress edge router to an egress edge router. Local policy in the AS will determine how the validation status is conveyed internally, using various preexisting mechanisms, e.g., setting a BGP community, or modifying a metric value such as Local_Pref or MED. A signed update that cannot be validated (except those with syntax errors) should be forwarded with signatures from the ingress router to the egress router, where it is signed when propagated towards other eBGPsec speakers in neighboring ASes. Based entirely on local policy settings, an egress router may trust the validation status conveyed by an ingress router, or it may perform its own validation. The latter approach may be used at an operator's discretion, under circumstances when RPKI skew is known to happen at different routers within an AS.
BGPsec验证只需在eBGP边缘执行。BGP签名/未签名更新的验证状态可以通过iBGP从入口边缘路由器传送到出口边缘路由器。AS中的本地策略将使用各种预先存在的机制（例如，设置BGP社区或修改度量值，如Local_Pref或MED）确定如何在内部传递验证状态。无法验证的已签名更新（语法错误的更新除外）应与签名一起从入口路由器转发到出口路由器，在出口路由器中，当它传播到相邻ASE中的其他eBGPsec扬声器时进行签名。完全基于本地策略设置，出口路由器可以信任入口路由器传送的验证状态，或者它可以执行自己的验证。在已知在AS内的不同路由器上发生RPKI偏移的情况下，运营商可自行决定使用后一种方法。
Note: An extended community for carrying the origin validation state in iBGP has been specified in RFC 8097 [RFC8097].
注意：RFC8097[RFC8097]中指定了在iBGP中承载原始验证状态的扩展社区。
The attribute used to represent the validation state can be carried between ASes, if desired. ISPs may like to carry it over their eBGP links between their own ASes (e.g., sibling ASes). A peer (or customer) may receive it over an eBGP link from a provider and may want to use it to shortcut their own validation check. However, the peer (or customer) should be aware that this validation-state attribute is just a preview of a neighbor's validation and must perform their own validation check to be sure of the actual state of the update's validation. Question: Should validation-state propagation be protected by attestation in cases where it is useful for diagnostics purposes? The decision was made to not protect the validation-state information using signatures.
如果需要，可以在ASE之间携带用于表示验证状态的属性。ISP可能希望通过自己的ASE（例如，兄弟ASE）之间的eBGP链接进行传输。对等方（或客户）可能会通过eBGP链接从提供商处接收到它，并可能希望使用它来简化自己的验证检查。但是，对等方（或客户）应该知道，此验证状态属性只是邻居验证的预览，并且必须执行自己的验证检查以确保更新验证的实际状态。问题：在验证状态传播对诊断有用的情况下，验证状态传播是否应该受到认证的保护？决定不使用签名保护验证状态信息。
The following validation states may be needed for propagation via iBGP between edge routers in an AS:
通过iBGP在AS中的边缘路由器之间传播可能需要以下验证状态：
o Validation states communicated in iBGP for an unsigned update (route origin validation result): (1) Valid, (2) Invalid, (3) NotFound (see [RFC6811]), (4) Validation Deferred.
o iBGP中针对未签名更新（路由源验证结果）传递的验证状态：（1）有效，（2）无效，（3）未找到（请参见[RFC6811]），（4）验证延迟。
* An update could be unsigned for either of the following two reasons, but they need not be distinguished: (a) it had no signatures (i.e., came in unsigned from an eBGP peer) or (b) signatures were present but stripped.
* 出于以下两个原因之一，更新可能未签名，但不需要区分：（a）它没有签名（即，来自eBGP对等方的未签名的更新）或（b）签名存在但已剥离。
o Validation states communicated in iBGP for a signed update: (1) Valid, (2) Invalid, (3) Validation Deferred.
o iBGP中针对签名更新传递的验证状态：（1）有效，（2）无效，（3）验证延迟。
The reason for conveying the additional "Validation Deferred" state may be illustrated as follows. An ingress edge Router A receiving an update from an eBGPsec peer may not attempt to validate signatures (e.g., in a processor overload situation), and in that case Router A should convey "Validation Deferred" state for that signed update (if selected for best path) in iBGP to other edge routers. An egress edge Router B, upon receiving the update from ingress Router A, would then be able to perform its own validation (origin validation for an unsigned update or origin/signature validation for a signed update). As stated before, the egress router (Router B in this example) may always choose to perform its own validation when it receives an update from iBGP (independently of the update's validation status conveyed in iBGP) to account for the possibility of RPKI data skew at different routers. These various choices are local and entirely at the operator's discretion.
传送附加“验证延迟”状态的原因可以如下所示。从eBGPsec对等方接收更新的入口边缘路由器A可能不会尝试验证签名（例如，在处理器过载的情况下），在这种情况下，路由器A应将iBGP中该签名更新的“验证延迟”状态（如果选择最佳路径）传递给其他边缘路由器。出口边缘路由器B在接收到来自入口路由器A的更新后，将能够执行其自身的验证（未签名更新的原点验证或签名更新的原点/签名验证）。如前所述，出口路由器（本例中的路由器B）在接收到来自iBGP的更新（独立于iBGP中传送的更新的验证状态）时可始终选择执行其自身的验证，以考虑不同路由器处RPKI数据偏斜的可能性。这些不同的选择是本地的，完全由运营商决定。
Note: Significant thought has been devoted to operations and management considerations subsequent to the writing of [BGPsec-Initial]. The reader is referred to [RFC8207] and Section 7 of [RFC8205] for details.
注：在编写[BGPsec初始版本]之后，对运营和管理考虑事项进行了大量思考。读者可参考[RFC8207]和[RFC8205]第7节了解详细信息。
BGP Graceful Restart (BGP-GR) [RFC4724] is a mechanism currently used to facilitate nonstop packet forwarding when the control plane is recovering from a fault (i.e., the BGP session is restarted) but the data plane is functioning. Two questions were raised: Are there any special concerns about how BGP-GR works while BGPsec is operational? Also, what happens if the BGP router operation transitions from traditional BGP operation to BGP-GR to BGPsec, in that order?
BGP优雅重启（BGP-GR）[RFC4724]是当前用于在控制平面从故障中恢复（即BGP会话重启）但数据平面正常工作时促进不间断数据包转发的机制。提出了两个问题：在BGPsec运行期间，是否对BGP-GR的工作方式有任何特别关注？此外，如果BGP路由器操作从传统的BGP操作过渡到BGP-GR再过渡到BGPsec，会发生什么情况？
No decision was made relative to this issue (at the time that [BGPsec-Initial] was written).
（在[BGPsec初始版本]编写之时）未就此问题做出任何决定。
Note: See Section 7.7 of [RFC8205] for comments concerning the operation of BGP-GR with BGPsec. They are consistent with the discussion below.
注：关于BGP-GR与BGPsec的操作，请参见[RFC8205]第7.7节。它们与下面的讨论一致。
BGP-GR can be implemented with BGPsec, just as it is currently implemented with traditional BGP. The Restart State bit, Forwarding State bit, End-of-RIB marker, staleness marker (in the Adj-RIB-In), and Selection_Deferral_Timer are key parameters associated with BGP-GR [RFC4724]. These parameters would apply to BGPsec, just as they apply to traditional BGP.
BGP-GR可以用BGPsec实现，就像目前用传统BGP实现一样。重启状态位、转发状态位、肋骨末端标记、老化标记（在Adj RIB in中）和选择延迟计时器是与BGP-GR相关的关键参数[RFC4724]。这些参数将适用于BGPsec，就像它们适用于传统BGP一样。
Regarding what happens if the BGP router transitions from traditional BGP to BGP-GR to BGPsec, the answer would simply be as follows. If there is a software upgrade to BGPsec during BGP-GR (assuming that the upgrade is being done on a live BGP speaker), then the BGP-GR session should be terminated before a BGPsec session is initiated. Once the eBGPsec peering session is established, the receiving eBGPsec speaker will see signed updates from the sending (newly upgraded) eBGPsec speaker. There is no apparent harm (it may, in fact, be desirable) if the receiving speaker continues to use previously learned unsigned BGP routes from the sending speaker until they are replaced by new BGPsec routes. However, if the Forwarding State bit is set to zero by the sending speaker (i.e., the newly upgraded speaker) during BGPsec session negotiation, then the
关于BGP路由器从传统BGP过渡到BGP-GR再过渡到BGPsec会发生什么，答案如下。如果在BGP-GR期间对BGPsec进行了软件升级（假设升级是在现场BGP扬声器上进行的），则应在启动BGPsec会话之前终止BGP-GR会话。一旦eBGPsec对等会话建立，接收eBGPsec扬声器将看到来自发送（新升级）eBGPsec扬声器的签名更新。如果接收扬声器继续使用先前从发送扬声器学习到的未签名BGP路由，直到它们被新的BGPsec路由替换，则不会有明显的伤害（事实上，这可能是可取的）。但是，如果在BGPsec会话协商期间发送扬声器（即新升级的扬声器）将转发状态位设置为零，则
receiving speaker would mark all previously learned unsigned BGP routes from that sending speaker as "stale" in its Adj-RIB-In. Then, as BGPsec updates are received (possibly interspersed with unsigned BGP updates), the "stale" routes will be replaced or refreshed.
接收说话人将在其Adj RIB in中将先前从发送说话人处学习到的所有未签名BGP路由标记为“过时”。然后，当收到BGPsec更新时（可能夹杂着未签名的BGP更新），将替换或刷新“过时”路由。
9.2. BCP Recommendations for Minimizing Churn: Certificate Expiry/ Revocation and Signature Expire Time
9.2. BCP关于减少流失的建议：证书过期/吊销和签名过期时间
Work related to this topic is still in progress.
与本专题有关的工作仍在进行中。
BCP recommendations for minimizing churn in BGPsec have been discussed. There are various potential strategies on how routers should react to such events as certificate expiry/revocation and signature Expire Time exhaustion [Dynamics]. The details will be documented in the near future after additional work is completed.
已经讨论了BCP关于在BGPsec中减少客户流失的建议。关于路由器应该如何应对诸如证书到期/撤销和签名到期时间耗尽等事件，存在各种潜在的策略[Dynamics]。在额外工作完成后，将在不久的将来记录详细信息。
Update signature validation and signing can be outsourced to an off-board server or processor.
更新签名验证和签名可以外包给非车载服务器或处理器。
Possibly, an off-router box (one or more per AS) can be used that performs path validation. For example, these capabilities might be incorporated into a route reflector. At an ingress router, one needs the Adj-RIB-In entries validated but not the RIB-out entries. So, the off-router box is probably unlike the traditional route reflector; it sits at the network edge and validates all incoming BGPsec updates. Thus, it appears that each router passes each BGPsec update it receives to the off-router box and receives a validation result before it stores the route in the Adj-RIB-In. Question: What about failure modes here? The failure modes would be dependent on the following:
可能的话，可以使用非路由器盒（一个或多个per AS）来执行路径验证。例如，这些功能可以合并到路由反射器中。在入口路由器上，需要验证Adj RIB In条目，而不是RIB out条目。因此，非路由器盒可能不同于传统的路由反射器；它位于网络边缘，验证所有传入的BGPsec更新。因此，似乎每个路由器将其接收到的每个BGPsec更新传递到非路由器盒，并在其将路由存储到Adj RIB in之前接收验证结果。问题：这里的故障模式是什么？故障模式取决于以下因素：
1. How much of the control plane is outsourced.
1. 有多少控制飞机是外包的。
2. How reliable the off-router box is (or, equivalently, communication to and from it).
2. 非路由器盒的可靠性（或与之通信的可靠性）。
3. How centralized vs. distributed this arrangement is.
3. 这种安排是集中还是分散。
When any kind of outsourcing is done, the user needs to be watchful and ensure that the outsourcing does not cross trust/security boundaries.
当完成任何类型的外包时，用户需要保持警惕，并确保外包不会跨越信任/安全边界。
It is assumed that BGPsec routers (Provider Edge (PE) routers and route reflectors) will require significantly upgraded hardware -- much more memory for RIBs and hardware cryptographic assistance. However, stub ASes would not need to make such upgrades because they can negotiate asymmetric BGPsec capability with their upstream ASes, i.e., they sign updates to the upstream AS but receive only unsigned BGP updates (see Section 6.5).
假定BGPsec路由器（提供商边缘（PE）路由器和路由反射器）将需要显著升级的硬件——RIB和硬件加密辅助需要更多内存。但是，存根ASE不需要进行此类升级，因为它们可以与其上游ASE协商非对称BGPsec能力，即，它们向上游ASE签署更新，但只接收未签署的BGP更新（见第6.5节）。
It is accepted that it might take several years to go beyond test deployment of BGPsec because of the need for additional route processor CPU and memory. However, because BGPsec deployment will be incremental and because signed updates are not sent outside of a set of contiguous BGPsec-enabled ASes, it is not clear how much additional (RIB) memory will be required during initial deployment. See [RIB_size] for preliminary results on modeling and estimation of BGPsec RIB size and its projected growth. Hardware cryptographic support reduces the computation burden on the route processor and offers good security for router private keys. However, given the incremental-deployment model, it also is not clear how substantial a cryptographic processing load will be incurred in the early phases of deployment.
由于需要额外的路由处理器CPU和内存，BGPsec的测试部署可能需要几年的时间。但是，由于BGPsec部署将是增量的，并且签名更新不会发送到一组连续的启用BGPsec的ASE之外，因此不清楚初始部署期间需要多少额外（RIB）内存。有关BGPsec肋骨尺寸及其预计增长的建模和估算的初步结果，请参见[肋骨尺寸]。硬件加密支持减少了路由处理器的计算负担，并为路由器私钥提供了良好的安全性。然而，考虑到增量部署模型，还不清楚在部署的早期阶段会产生多大的加密处理负载。
Note: There are recent detailed studies that considered software optimizations for BGPsec. In [Mehmet1] and [Mehmet2], computational optimizations for cryptographic processing (i.e., ECDSA speedup) are considered for BGPsec implementations on general-purpose CPUs. In [V_Sriram], software optimizations at the level of update processing and path selection are proposed and quantified for BGPsec implementations.
注：最近有详细的研究考虑了BGPsec的软件优化。在[Mehmet1]和[Mehmet2]中，针对通用CPU上的BGPsec实现，考虑了加密处理的计算优化（即ECDSA加速）。在[V_Sriram]中，针对BGPsec实现提出并量化了更新处理和路径选择级别的软件优化。
The idea of signed BGP peering registrations (for the purpose of path validation) was rejected.
签名BGP对等注册（用于路径验证）的想法被拒绝。
The idea of using a secure map of AS relationships to "validate" updates was discussed and rejected: such solutions were not pursued because they cannot provide strong guarantees regarding the validity of updates. Using these techniques, one can say only that an update is "plausible"; one cannot say that it is "definitely" valid (based on signed peering relations alone).
讨论了使用AS关系的安全映射来“验证”更新的想法，但遭到拒绝：由于无法提供关于更新有效性的有力保证，因此没有采用此类解决方案。使用这些技术，人们只能说更新是“可信的”；不能说它“绝对”有效（仅基于签名对等关系）。
This document requires no security considerations. See [RFC8205] for security considerations for the BGPsec protocol.
本文档不需要任何安全考虑。有关BGPsec协议的安全注意事项，请参阅[RFC8205]。
This document has no IANA actions.
本文档没有IANA操作。
[ASset] Sriram, K. and D. Montgomery, "Measurement Data on AS_SET and AGGREGATOR: Implications for {Prefix, Origin} Validation Algorithms", IETF SIDR WG presentation, IETF 78, July 2010, <http://www.nist.gov/itl/antd/upload/ AS_SET_Aggregator_Stats.pdf>.
[资产]Sriram，K.和D.Montgomery，“AS_集和聚合器的测量数据：对{前缀，原点}验证算法的影响”，IETF SIDR WG演示，IETF 78，2010年7月<http://www.nist.gov/itl/antd/upload/ AS\u SET\u Aggregator\u Stats.pdf>。
[BGP-Ext-Msg] Bush, R., Patel, K., and D. Ward, "Extended Message support for BGP", Work in Progress, draft-ietf-idr-bgp-extended-messages-24, November 2017.
[BGP Ext Msg]Bush，R.，Patel，K.，和D.Ward，“BGP的扩展消息支持”，正在进行的工作，草稿-ietf-idr-BGP-Extended-messages-242017年11月。
[BGPsec-Initial] Lepinski, M., "BGPSEC Protocol Specification", Work in Progress, draft-lepinski-bgpsec-protocol-00, March 2011.
[BGPsec初始版本]Lepinski，M.，“BGPsec协议规范”，正在进行的工作，草案-Lepinski-BGPsec-Protocol-00，2011年3月。
[BGPsec-Rollover] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", Work in Progress, draft-ietf-sidrops-bgpsec-rollover-04, December 2017.
[BGPsec展期]Weis，B.，Gagliano，R.，和K.Patel，“BGPsec路由器证书展期”，在建工程，草案-ietf-sidrops-BGPsec-展期-042017年12月。
[Borchert] Borchert, O. and M. Baer, "Subject: Modifiation [sic] request: draft-ietf-sidr-bgpsec-protocol-14", message to the IETF SIDR WG Mailing List, 10 February 2016, <https://www.ietf.org/mail-archive/web/sidr/current/ msg07509.html>.
[Borchert]Borchert，O.和M.Baer，“主题：修改[sic]请求：草案-ietf-sidr-bgpsec-protocol-14”，发送给ietf sidr WG邮件列表的信息，2016年2月10日<https://www.ietf.org/mail-archive/web/sidr/current/ msg07509.html>。
[CiscoIOS] "Cisco IOS: Configuring Route Dampening", February 2014, <https://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/ configuration/guide/fipr_c/1cfbgp.html>.
[CiscoIOS]“Cisco IOS:配置路由阻尼”，2014年2月<https://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/ 配置/guide/fipr_c/1cfbgp.html>。
[CPUworkload] Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on a Router", Presented at RIPE-63; also at IETF 83 SIDR WG Meeting, March 2012, <https://www.ietf.org/proceedings/ 83/slides/slides-83-sidr-7.pdf>.
[CPUworkload]Sriram，K.和R.Bush，“估算路由器上BGPSEC的CPU成本”，在RIME-63上发表；也在IETF 83 SIDR工作组会议上，2012年3月<https://www.ietf.org/proceedings/ 83/slides/slides-83-sidr-7.pdf>。
[Dynamics] Sriram, K., Montgomery, D., Borchert, O., Kim, O., and P. Gleichmann, "Potential Impact of BGPSEC Mechanisms on Global BGP Dynamics", Presentation to the BGPsec authors/designers team, October 2009, <https://www.nist.gov/file/448631>.
[Dynamics]Sriram，K.，Montgomery，D.，Borchert，O.，Kim，O.，和P.Gleichmann，“BGPSEC机制对全球BGP动力学的潜在影响”，提交给BGPSEC作者/设计师团队，2009年10月<https://www.nist.gov/file/448631>.
[Gueron] Gueron, S. and V. Krasnov, "Fast and side channel protected implementation of the NIST P-256 Elliptic Curve for x86-64 platforms", OpenSSL patch ID 3149, October 2013, <https://rt.openssl.org/Ticket/ Display.html?id=3149&user=guest&pass=guest>.
[Gueron]Gueron，S.和V.Krasnov，“用于x86-64平台的NIST P-256椭圆曲线的快速和侧通道保护实施”，OpenSSL补丁ID 3149，2013年10月<https://rt.openssl.org/Ticket/ Display.html？id=3149&user=guest&pass=guest>。
[JunOS] "Juniper JunOS: Using Routing Policies to Damp BGP Route Flapping", November 2010, <http://www.juniper.net/ techpubs/en_US/junos10.4/topics/usage-guidelines/ policy-using-routing-policies-to-damp-bgp-route-flapping.html>.
[JunOS]“Juniper JunOS：使用路由策略抑制BGP路由抖动”，2010年11月<http://www.juniper.net/ techpubs/en_US/junos10.4/topics/usage-guidelines/policy使用路由策略抑制bgp路由抖动。html>。
[Mandelberg1] Mandelberg, D., "Subject: wglc for draft-ietf-sidr-bgpsec-protocol-11 (Specific topic: Include Address Family Identifier in the data protected under signature -- to alleviate a security concern)", message to the IETF SIDR WG Mailing List, 10 February 2015, <https://www.ietf.org/ mail-archive/web/sidr/current/msg06930.html>.
[Mandelberg1]Mandelberg，D.，“主题：草案-ietf-sidr-bgpsec-protocol-11的wglc（具体主题：在受签名保护的数据中包括地址族标识符——以缓解安全问题）”，致ietf-sidr工作组邮件列表的信息，2015年2月10日<https://www.ietf.org/ 邮件存档/web/sidr/current/msg06930.html>。
[Mandelberg2] Mandelberg, D., "Subject: draft-ietf-sidr-bgpsec-protocol-13's security guarantees (Specific topic: Sign all of the preceding signed data (rather than just the immediate, previous signature) -- to alleviate a security concern)", message to the IETF SIDR WG Mailing List, 26 August 2015, <https://www.ietf.org/mail-archive/ web/sidr/current/msg07241.html>.
[Mandelberg2]Mandelberg，D.，“主题：草案-ietf-sidr-bgpsec-protocol-13的安全保证（具体主题：签署所有先前签署的数据（而不仅仅是即时、先前的签名）——以缓解安全问题）”，致ietf sidr WG邮件列表的信息，2015年8月26日， <https://www.ietf.org/mail-archive/ web/sidr/current/msg07241.html>。
[Mao02] Mao, Z., et al., "Route Flap Damping Exacerbates Internet Routing Convergence", August 2002, <http://www.eecs.umich.edu/~zmao/Papers/sig02.pdf>.
[Mao02]Mao，Z.等人，“路由衰减加剧互联网路由收敛”，2002年8月<http://www.eecs.umich.edu/~zmao/Papers/sig02.pdf>。
[Mehmet1] Adalier, M., "Efficient and Secure Elliptic Curve Cryptography Implementation of Curve P-256", NIST Workshop on ECC Standards, June 2015, <http://csrc.nist.gov/groups/ST/ecc-workshop-2015/papers/ session6-adalier-Mehmet.pdf>.
[Mehmet1]Adalier，M.“曲线P-256的高效安全椭圆曲线加密实现”，NIST ECC标准研讨会，2015年6月<http://csrc.nist.gov/groups/ST/ecc-workshop-2015/papers/ 会话6 adalier Mehmet.pdf>。
[Mehmet2] Adalier, M., Sriram, K., Borchert, O., Lee, K., and D. Montgomery, "High Performance BGP Security: Algorithms and Architectures", North American Network Operators Group Meeting NANOG69, February 2017, <https://www.nanog.org/meetings/abstract?id=3043>.
[Mehmet2]Adalier，M.，Sriram，K.，Borchert，O.，Lee，K.，和D.Montgomery，“高性能BGP安全：算法和架构”，北美网络运营商集团会议NANOG69，2017年2月<https://www.nanog.org/meetings/abstract?id=3043>.
[MsgSize] Sriram, K., "Decoupling BGPsec Documents and Extended Messages draft", Presented at the IETF SIDROPS WG Meeting, IETF 98, March 2017, <https://www.ietf.org/proceedings/98/slides/ slides-98-sidrops-decoupling-bgpsec-documents-and-extended-messages-draft-00.pdf>.
[MsgSize]Sriram，K.，“解耦BGPsec文件和扩展消息草案”，在IETF SIDROPS工作组会议上介绍，IETF 98，2017年3月<https://www.ietf.org/proceedings/98/slides/ slides-98-sidrops-decoupling-bgpsec-documents-and-extended-messages-draft-00.pdf>。
[Replay-Protection] Sriram, K. and D. Montgomery, "Design Discussion and Comparison of Protection Mechanisms for Replay Attack and Withdrawal Suppression in BGPsec", Work in Progress, draft-sriram-replay-protection-design-discussion-10, April 2018.
[重放保护]Sriram，K.和D.Montgomery，“BGPsec中重放攻击和撤回抑制保护机制的设计讨论和比较”，正在进行的工作，草稿-Sriram-Replay-Protection-Design-Discussion-10，2018年4月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November 1998, <https://www.rfc-editor.org/info/rfc2439>.
[RFC2439]Villamizar，C.，Chandra，R.和R.Govindan，“BGP路线襟翼阻尼”，RFC 2439，DOI 10.17487/RFC2439，1998年11月<https://www.rfc-editor.org/info/rfc2439>.
[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>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/info/rfc6090>.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 6090，DOI 10.17487/RFC6090，2011年2月<https://www.rfc-editor.org/info/rfc6090>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security Requirements for BGP Path Validation", RFC 7353, DOI 10.17487/RFC7353, August 2014, <https://www.rfc-editor.org/info/rfc7353>.
[RFC7353]Bellovin，S.，Bush，R.，和D.Ward，“BGP路径验证的安全要求”，RFC 7353，DOI 10.17487/RFC7353，2014年8月<https://www.rfc-editor.org/info/rfc7353>.
[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>.
[RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. Bush, "BGP Prefix Origin Validation State Extended Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, <https://www.rfc-editor.org/info/rfc8097>.
[RFC8097]Mohapatra，P.，Patel，K.，Scudder，J.，Ward，D.，和R.Bush，“BGP前缀来源验证州扩展社区”，RFC 8097，DOI 10.17487/RFC8097，2017年3月<https://www.rfc-editor.org/info/rfc8097>.
[RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205]Lepinski，M.，Ed.，和K.Sriram，Ed.，“BGPsec协议规范”，RFC 8205，DOI 10.17487/RFC8205，2017年9月<https://www.rfc-editor.org/info/rfc8205>.
[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>.
[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>.
[RIB_size] Sriram, K., et al., "RIB Size Estimation for BGPSEC", May 2011, <http://www.nist.gov/itl/antd/upload/ BGPSEC_RIB_Estimation.pdf>.
[肋骨尺寸]Sriram，K.等人，“BGPSEC肋骨尺寸估算”，2011年5月<http://www.nist.gov/itl/antd/upload/ BGPSEC_RIB_Estimation.pdf>。
[RIPE580] Bush, R., et al., "RIPE-580: RIPE Routing Working Group Recommendations on Route Flap Damping", January 2013, <http://www.ripe.net/ripe/docs/ripe-580>.
[RIPE580]Bush，R.等人，“RIME-580：RIME路由工作组关于路由襟翼阻尼的建议”，2013年1月<http://www.ripe.net/ripe/docs/ripe-580>.
[Secure-BGP] Lynn, C., Mikkelson, J., and K. Seo, "Secure BGP (S-BGP)", Work in Progress, draft-clynn-s-bgp-protocol-01, June 2003.
[安全BGP]Lynn，C.，Mikkelson，J.，和K.Seo，“安全BGP（S-BGP）”，正在进行的工作，草稿-clynn-S-BGP-protocol-01，2003年6月。
[V_Sriram] Sriram, V. and D. Montgomery, "Design and analysis of optimization algorithms to minimize cryptographic processing in BGP security protocols", Computer Communications, Vol. 106, pp. 75-85, DOI 10.1016/j.comcom.2017.03.007, July 2017, <https://www.sciencedirect.com/science/article/pii/ S0140366417303365>.
[V_Sriram]Sriram，V.和D.Montgomery，“优化算法的设计和分析，以最小化BGP安全协议中的密码处理”，计算机通信，第106卷，第75-85页，DOI 10.1016/j.comcom.2017.03.007，2017年7月<https://www.sciencedirect.com/science/article/pii/ S0140366417303365>。
Acknowledgements
致谢
The author would like to thank Jeff Haas and Wes George for serving as reviewers for this document for the Independent Submissions stream. The author is grateful to Nevil Brownlee for shepherding this document through the Independent Submissions review process. Many thanks are also due to Michael Baer, Oliver Borchert, David Mandelberg, Sean Turner, Alvaro Retana, Matthias Waehlisch, Tim Polk, Russ Mundy, Wes Hardaker, Sharon Goldberg, Ed Kern, Chris Hall, Shane Amante, Luke Berndt, 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.
作者要感谢Jeff Haas和Wes George担任独立提交流文件的审阅者。作者感谢Nevil Brownlee在独立提交审查过程中指导本文件。还要感谢迈克尔·贝尔、奥利弗·博尔切特、大卫·曼德尔伯格、肖恩·特纳、阿尔瓦罗·雷塔纳、马蒂亚斯·韦利希、蒂姆·波尔克、罗斯·蒙迪、韦斯·哈达克、沙龙·戈德伯格、埃德·克恩、克里斯·霍尔、肖恩·阿曼特、卢克·伯恩特、道格·莫汉、普拉多什·莫哈普拉、马克·雷诺兹、希瑟·席勒、杰森·席勒、鲁迪格·沃尔克、，以及David Ward在这项工作过程中的审查、评论和建议。
Contributors
贡献者
The following people 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, LLC Email: housley@vigilsec.com
Russ Housley Vigil Security，LLC电子邮件：housley@vigilsec.com
Stephen Kent Independent Email: kent@alum.mit.edu
Stephen Kent独立电子邮件：kent@alum.mit.edu
Warren Kumari Google Email: warren@kumari.net
Warren Kumari谷歌电子邮件：warren@kumari.net
Matt Lepinski New College of Florida Email: mlepinski@ncf.edu
Matt Lepinski佛罗里达新学院电子邮件：mlepinski@ncf.edu
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 Parsons, Inc. Email: sandy@tislabs.com
Sandy Murphy Parsons，Inc.电子邮件：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
Author's Address
作者地址
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: ksriram@nist.gov
Email: ksriram@nist.gov