[要約] RFC 8374は、BGPsecの設計選択肢と関連する議論の要約を提供するものであり、BGPセキュリティの向上を目的としています。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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のセキュリティを強化することです。 Resource PKI（RPKI）に基づくルート起点検証に関する標準は、IETF SIDR WG [RFC6480] [RFC6482] [RFC6483] [RFC6487] [RFC6811]ですでに完了しているか、ほぼ完了しています。 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-Initial]の設計正当性を提供します。設計者は多くの競合する要因のバランスをとる必要があり、このドキュメントでは、各設計の選択に賛成または反対の決定がリストされています。また、このドキュメントでは、賛否両論を検討し、決定プロセスを支援した議論の概要を示します。このドキュメントでは、必要に応じて、BGPsecプロトコル仕様の初期ドラフトバージョンで採用されたアプローチから変更された設計決定に関する簡単なメモ（「注：」で始まる）を提供します。仕様はIETF SIDR WGによってレビューおよび更新されました。 （これらの設計上の決定は、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):
設計の選択とディスカッションは、次のセクションで説明されています（次の8つの広範なカテゴリの下に、各カテゴリ内に多くのサブトピックがあります）。
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.
Route Origin Authorizations（ROA）[RFC6482] [RFC6811]を使用したルートオリジン検証が必要であり、署名された更新に基づいてASパス認証を補完します。したがって、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（パス署名）は、BGPセキュリティのためのSIDR WGソリューションの2つの重要な要素です。
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アップデートの署名のExpire Timeフィールドについての記述はありません。さらに、RFC 8205 [RFC8205]のセクション4.2の図8にある、発信元ASによって署名された属性に関する追加の詳細があります。特に、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を参照）。 （アップストリームASがそれぞれの署名の有効期限を挿入しない理由については、セクション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-Rollover] [Replay-Protection]。
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プレフィックスが1つだけ含まれることが決定されました。複数のNLRIプレフィックスが含まれていて、上流のASがプレフィックスのサブセットのアドバタイズを伝播するように選択されている場合、更新のシグネチャは壊れます（セクション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.
ドロップされたプレフィクス。これにより、通常のBGP動作では明らかにされない情報が後続のASに明らかにされます。したがって、各更新を1つのプレフィックスのみを伝送するように制限することによって暗黙的に示されるパフォーマンスヒットに対して、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_PATH属性が含まれている場合（RFC 8205のセクション3を参照））、そのルーターが更新をに転送することは望ましくありません。すべてのネイバー、特にBGPsecを理解しておらず、大きなオプションのBGP属性を持つ多くのアップデートを受信すると窒息する可能性があります。 BGPsecが段階的に展開されている間、BGPsecと従来のBGPが共存することが想定されています。
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、および有効期限を含む結合された情報にデジタル署名します。次のように、アップストリームASによって署名されるものに関して複数の選択肢があります。
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：署名は、前の署名（つまり、更新を転送したネイバーASの署名）と次の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].
注：最終的なBGPsecプロトコル仕様[RFC8205]のExpire Timeフィールドの削除については、セクション2.2.1および2.2.2の注意を参照してください。
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を使用します（有効期限を除く）。アップストリームASによって署名された属性に関する追加の詳細は、RFC 8205 [RFC8205]のセクション4.2の図8にあります。方法3（署名されたデータへの適切な追加を伴う）を採用する決定は、方法2に関連するセキュリティ上の懸念によって動機付けられました。 [Mandelberg2]（SIDR WGメーリングリストへの投稿）と、このトピックに続くディスカッションスレッドを参照してください。また、ハッシュされるオクテットのシーケンスには強力な根拠があります（RFC 8205のセクション4.2の図8に示されています）。このデータの順序付けは、実装効率を考慮して行われます。説明は[Borchert]（SIDR WGメーリングリストへの投稿）を参照してください。
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）は次のとおりです。署名はハッシュブロックに対して実行されます。署名するバイト数が1つのハッシュブロックを超えると、残りのバイトが2番目のハッシュブロックにオーバーフローし、パフォーマンスが低下します。したがって、ハッシュされるバイト数を最小限に抑えると有利です。また、上記の3つのオプションの分析では、このアプローチに関連する脆弱性は特定されませんでした。
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で特定された属性以外の属性は署名されません。このような属性の例には、コミュニティ属性、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.
次の例は、署名付き更新の受信時に予期されるルーターのアクションを示しています。 AS1がNLRI接頭辞pを付けて発信し、ASiに到達する前にASパス[AS（i-1）AS（i-2）... AS2 AS1]を通過した更新を考えます。この更新の署名の有効期限（AS1によって挿入）をTeと表記します。 AlgIDが、使用中の署名アルゴリズムスイートのIDを表すようにします。更新はASiで処理され、AS（i + 1）に転送される可能性があります。 ASパスの各ルーターによって挿入された構成証明（署名）を、AS1、AS2、...、ASに対応するSig1、Sig2、...、Sig（i-2）、およびSig（i-1）で示します。 （i-2）、およびAS（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.
付加は許可されます。 Prependingは、更新に署名しているルーターの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に署名を関連付ける必要があります。複数の先頭に追加されたASの署名を1つだけにする最適化は、後で追求されました。現在、pCountフィールドはASプリペンドを表すために使用されています。 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）、リプレイアタックと撤回抑制の緩和に対するExpire Timeアプローチは、その後、ルーターキーロールオーバー[BGPsec-Rollover] [Replay-Protection]に基づくアプローチに変更されました。
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は、それが発信するルートのExpire Time値をずらす必要があります。再オリジネーションは、たとえば、オリジネーション後の時間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時間を使用できます。したがって、異なるASは、悪意のあるルートのリプレイから保護するための認識されたニーズに基づいて異なる値を選択する場合があります。 （有効期限が短いと、ASが悪意を持ってルートを再生できる時間帯が短くなります。ただし、有効期限の値が短いと、ルートが頻繁に更新されるため、より多くのBGPチャターが発生します。4時間の期間でさえ、管理可能な再構成ワークロード。たとえば、500Kルートが4時間ごとに再発信されると、BGP更新の負荷が1秒あたり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セッション障害からの自身の回復中に、発生する更新のExpire Time値をずらす必要があります。これを行うことにより、ルーターでの再発信（つまり、ビーコン）ワークロードが分散されます。
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.
新しい署名のExpire Timeを（署名付きの更新全体を再送信するのではなく）特別なメッセージで送信するという考えが検討されました。ただし、これを行わないように決定されました。新しい署名の有効期限を伝えるための再発信は、通常の更新メッセージを伝達することによって行われます。特別なタイプのメッセージは必要ありません。
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.
署名の有効期限の再ビーコンが別の特別なメッセージで行われる場合、更新に関連する処理負荷が軽減される可能性があることが示唆されました。しかし、そのような再ビーコンメッセージは必然的にASパスとプレフィックス情報を必要とするため、更新から分離できないことが認識されました。
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.
インターネットのエッジでは、BGPセッションが1つのインターフェイスから別のインターフェイスに（たとえば、プライマリからバックアップに）切り替えられている2つのピアリングAS（たとえば、顧客とプロバイダー）。従来のBGPでは、これらの更新は関連する2つのASを超えて伝播しません。しかし、BGPsecでは、顧客のASは、そのようなイベントが発生するたびに新しい署名Expire Timeを入れます。したがって、更新はインターネット全体に伝播する必要があります（ベストパス選択のプロセスによってのみ制限されます）。この追加された解約のコストは避けられないことが受け入れられました。
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]に関しては、Expire-Time-triggered（re-beaconed）BGPsec updateに差分処理は必要ありません。
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. Expire-Timeでトリガーされる更新の前には、通常、引き出しがあります。したがって、経路探索と関連する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番目の観察についてさらに詳しく説明すると、特定のピアからの特定のアドレスプレフィックスのルートの再アドバタイズメント（つまり、ビーコン）が数時間の間隔で受信されることに注意してください（セクション3.2を参照）。その期間中、Expire-Timeトリガー更新による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 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.
特定のピアからの特定のプレフィックスに対してRFDペナルティ増分がトリガーされる頻度は、その発信元ASからのそのプレフィックスの再ビーコン頻度と同じです。再ビーコンの頻度は、数時間に1回程度です（セクション3.2を参照）。再ビーコンされた更新によりプレフィックスに割り当てられる増分RFDペナルティは、実装によって異なります。たとえば、JunOS実装[JunOS]は、再ビーコンされた更新が再アドバタイズメントと見なされるか、属性変更と見なされるかに応じて、それぞれ1000または500のペナルティを割り当てるようです。通常、再ビーコンされた更新は、属性の変更として扱われます。一方、シスコの実装[CiscoIOS]は、実際のフラップが発生した場合にのみRFDペナルティを割り当てます（つまり、ルートが利用可能であるが利用不可能になる、またはその逆）。したがって、RFDのシスコの実装では、再ビーコンされた更新にペナルティは割り当てられないようです（つまり、ルートはすでにアドバタイズされており、撤回されておらず、再ビーコンされた更新はExpire Time属性を更新しているだけです）。 500のRFDペナルティが割り当てられていると仮定したとしても（JunOS RFD実装による属性の変更に対応）、問題のプレフィックスを減衰させることによる増分効果は無視できることを示すことができます。 RFDペナルティ減衰の時間は通常15分に設定されていますが、再ビーコンの頻度は数時間に1回程度です。 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実装の機能を確認するには、2番目の署名アルゴリズムを使用する必要があります。
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_size]。
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.
2つの異なる署名アルゴリズム（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.) 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].
楕円曲線暗号（ECC）アルゴリズムに基づいて構築された最適化と特殊化アルゴリズム（高速化など）には、アクティブなIPR（知的財産権）があるかもしれませんが、このドキュメントの公開時点では、基本（最適化されていない）アルゴリズム。 （これをよりよく理解するには、[RFC6090]が出発点として役立ちます。）注：最近、オープンソースの実装でさえ、特定の暗号化最適化が組み込まれ、大幅なパフォーマンスの高速化が示されました[Gueron]。研究者たちは、BGPsec実装の一部としてECDSAの大幅な高速化を実証するために、多大な努力を続けています[Mehmet1] [Mehmet2]。
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.
1つのアルゴリズム（つまり、現在のアルゴリズム）から次の（新しい）アルゴリズムへの移行期間中、更新は、各アルゴリズムに対応する2セットの署名（つまり、2つのSignature_Blocks）を伝送します。各Signature_Blockの前には、type-lengthフィールドとアルゴリズムスイート識別子が付きます。新しいアルゴリズムを処理するようにアップグレードされたBGPsecスピーカーは、両方のSignature_Blockを検証し、対応する署名を各Signature_Blockに追加して、更新を次のASに転送する必要があります。新しいアルゴリズムを処理するようにアップグレードされていないBGPsecスピーカーは、新しいアルゴリズムのSignature_Blockを取り除き、現在のアルゴリズムのSignature_Blockに独自の署名を追加した後、更新を転送します。
It was decided that there will be at most two Signature_Blocks per update.
更新ごとに最大2つのSignature_Blockが存在することが決定されました。
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パス署名は、BGPsec_PATH属性に含まれる属性であるSignature_Blockで伝達されます（[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.
Signature_Blockの長さフィールドを使用すると、2つの署名ブロックを区別できます。したがって、特定のアルゴリズムスイートを知らない（したがって、そのアルゴリズムスイートの署名がどれだけ長いかわからない）BGPsecルーターは、メッセージを解析するときに対応するSignature_Blockをスキップする可能性があります。
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つのアルゴリズムのオーバーラップ期間は2〜4年続くと予想されます。 RIBメモリと暗号処理容量は、更新に2セットのシグネチャ[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.
署名アルゴリズムの寿命は、現在のアルゴリズムから新しいアルゴリズムへの移行期間の持続時間よりもはるかに長いと予想されます。すべてのASが、後続の新しいアルゴリズムを調査してBGPsec用に標準化できる間隔よりもはるかに短い特定の時間内に、必要な新しいアルゴリズムに変換されることが十分に期待されます。したがって、更新ごとに3つ以上のSignature_Blockが必要になることは想定されていません。
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.
現在、Sequential Aggregate Signature（SAS）アプローチに対するサポートは弱いか、サポートされていません。 SASとは何か、そのSASの長所と短所は何かについての簡単な説明については、セクション4.3.2を参照してください。
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ホップの数に関係なく、シグニチャブロックごとに1つの（集約された）シグニチャしかありません。たとえば、ASn（n番目のAS）は、以前のすべてのAS [AS1、...、AS（n-1）]の署名を入力として取り、単一の複合署名を生成します。この複合署名には、AS1、...、ASnの公開鍵を持つ受信者が（単一の複合署名のみを使用して）すべてのASが実際にメッセージに署名したことを確認できるという特性があります。 SASは、帯域幅とプロトコルデータユニット（PDU）サイズ、そしておそらくRIBサイズを節約できる可能性がありますが、署名の生成と検証のコストは、ASホップごとに1つの署名と比較すると高くなります。
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の利点が損なわれます。これは、ルートの平均ホップカウント、つまりASの数が約3.8であるためです。結局のところ、SASの方が複雑であり、PDUサイズまたはRIBサイズを十分に節約できないため、その使用に値しない場合があります。 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ごとの1つの署名に対応していない可能性がある署名アルゴリズムの採用（たとえば、総署名）が含まれます。
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で説明したアルゴリズム移行に類似しています。 1つのプロトコルバージョン（つまり、現在のバージョン）から次の（新しい）バージョンへの移行期間中、更新には2つの署名セット（つまり、2つのSignature_Block）が含まれ、1つは各バージョンに対応します。プロトコルバージョン識別子は、各Signature_Blockに関連付けられています。したがって、各Signature_Blockの前には、type-lengthフィールドとプロトコルバージョン識別子が付きます。新しいバージョンを処理するようにアップグレードされたBGPsecスピーカーは、両方のSignature_Blockを検証してから、対応する署名を各Signature_Blockに追加して、更新を次のASに転送する必要があります。新しいプロトコルバージョンを処理するようにアップグレードされていないBGPsecスピーカーは、新しいバージョンのSignature_Blockを取り除き、独自の署名を添付した更新を現在のバージョンのSignature_Blockに転送します。
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 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の後続のバージョンが作成され、このバージョンのBGPsecが、新しいBGPパス属性（「BGPsec_PATH_TWO」と呼びましょう）を指定することが予想されます。 BGPsecへの必要な変更。この時点で、セクション4.2で説明したアルゴリズム遷移に類似した遷移が始まります。移行期間中、すべてのBGPsecスピーカーには、BGPsec_PATH（現在）属性（RFC 8205のセクション3を参照）と新しいBGPsec_PATH_TWO属性の両方が同時に含まれます。移行が完了すると、BGPsec_PATHの使用が廃止される可能性があります。この時点で、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の10進表記が続き、その後にルーター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ルーターは複数のプレフィックスアナウンスを1つの更新にパックします。アップストリームBGPルーターがeBGP更新をピアに転送するとき、（共有ASパスと属性に基づく）複数のプレフィックスを1つの更新にパックすることもできます。アップストリームの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.
各更新には、プレフィックスが1つだけ含まれています。これにより、更新でオリジンが複数のプレフィックスをパックして署名し、アップストリームASがその更新でプレフィックスのサブセットのみを含む更新を伝播することを決定した場合に避けられない複雑さのレベルを回避できます。パックと再パックに関する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では、更新ごとに発表されるプレフィックスは平均して約4つです[RIB_size]。したがって、BGPアップデート（アナウンスを伝送）の数は、アナウンスされたプレフィックスの数と比較して、平均で約4分の1です。
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.
現在の決定では、セキュリティで保護された更新ごとに1つのプレフィックスのみを含めることです（セクション2.2.2を参照）。将来最適化を検討する場合、複数のプレフィックスを更新にパックする可能性も検討できます。 （プレフィックスごとの署名と更新ごとの署名の説明については、セクション5.2を参照してください。）署名がプレフィックスごとに生成された場合は、再パッキングを実行できます。ただし、このアプローチに関する1つの問題（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).
最初の設計では、更新ごとに1つの接頭辞を含める必要があります。したがって、セキュリティで保護された各更新（モジュロアルゴリズム遷移条件）にはシグネチャが1つしかありません。
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.
更新ごとに1つの署名がある一般的なケースでは、複数のプレフィックスが、共有のASパス、次のASN、および有効期限と共に1つの署名で署名される場合があります。 「シグニチャごとのシグニチャ」技術が使用される場合、アップデートPDUサイズとRIBメモリサイズが節約される可能性があります。ただし、ASパスに沿ってアナウンスされたプレフィックスセットに変更が加えられた場合、変更が発生したASは、明示的パス属性（EPA）[Secure-BGP]を挿入する必要があります。 EPAは、変更前のプレフィックスセットの内容に関する情報を伝えます。そのような変更を行ったASごとに1つのEPAがあり、各EPAを対応するASに関連付ける方法があります。これにより、アップストリームASは、（途中でアナウンスされたプレフィックスセットに変更が加えられても）ASパス内の以前のASによってアナウンスおよび署名されたものを認識および検証できます。 EPAは処理（署名の生成と検証）を複雑にします。更新のサイズ、したがってRIBのサイズをさらに増やします。そして、他の方法では公開されないダウンストリームASにデータを公開します。プレフィックスごとのシグネチャと更新ごとのシグネチャ（パッキングあり）のコンテキストでのパッキングと再パッキングのメリットとデメリットのすべてが評価されているわけではありません。ただし、現在の推奨事項は、更新ごとにプレフィックスを1つだけにすること（パッキングなし）であるため、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]に増やして、2つのSignature_Block（つまり、現在のアルゴリズムを持つブロックと新しい署名アルゴリズムを持つ別のブロック）に対応する十分なスペースを確保する必要があります。将来の移行期間）長いASパス。
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 UPDATEメッセージは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ルーターが署名や検証を実行するワークロードに対応できないことがあります。これは、たとえば、ルーターがルーティングテーブル全体を隣接するAS内の回復中のルーターに送信する必要があるBGPセッションの回復中に発生する可能性があります（[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ルーターが、ピアのASが発信したプレフィックスを除いて、署名された更新のみを送信するようにBGPsec対応のeBGPピアに要求することはできません。
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_PATH属性に対応するAS_PATH属性を生成することにより、これを行います。上記の一時停止が適用される場合は、同じAS_PATH再構築手順を使用する必要があります。
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プロトコルに組み込もうとすると、矛盾します。署名されたピアリング登録に基づいて、ダウングレード攻撃を検出するための1つの提案された方法が検討されました（セクション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の2つのアドレスファミリが含まれます。他のアドレスファミリで使用するBGPsecは、将来指定される可能性があります。同じBGPsecセッションで2つの（つまり、IPv4とIPv6）アドレスファミリを同時に使用するには、BGPsec機能のネゴシエーション中に、BGPsecスピーカーにこの機能の2つのインスタンス（各アドレスファミリに1つ）を含める必要があります。
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は、エッジサイト（スタブAS）が発信元の更新に署名する方法を説明しますが、署名されていない更新のみを受信できます。これにより、リソースが制限されたスタブASでの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 ASに署名します。
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スピーカーの障害、誤設定、または破壊（有効なオリジンASを挿入することによって）必要な未署名の更新を製造し、それに署名を追加して、その更新が優先される可能性を高めることができます。
6.5. Consideration of Stub ASes with Resource Constraints: Encouraging Early Adoption
6.5. リソースに制約のあるスタブASの検討：早期採用を推奨
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対応ASの各ペアがBGPsecの使用を非対称的にネゴシエートできるようになります。したがって、スタブAS（またはダウンストリームカスタマーAS）は、送信方向でのみBGPsecを実行し、受信方向で従来のBGPを話すことに同意できます。この配置では、ISP（上流）のASは、署名された更新をこのスタブまたは顧客のASに送信しません。したがって、スタブASは、BGPsec更新検証をサポートするためにルートプロセッサとRIBメモリをハードウェアアップグレードする必要を回避できます。
Various other options were also considered for accommodating a resource-constrained stub AS, as discussed below:
以下で説明するように、リソースに制約のあるスタブASに対応するために、他にもさまざまなオプションが検討されました。
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（つまり、2番目のホップの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. プレフィックスの発信元としてスタブAS、セカンドホップASとしてアップストリームプロバイダーを含む拡張ROAが作成され、部分的な署名が許可されます（つまり、スタブ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が顧客ASに代わって署名することを承認します[動的]。この方法では、完全に署名された更新が可能です（拡張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を実行するスタブASの利点は、BGPsecに最小限アップグレードするだけでよいので、アップストリームASへの更新に署名しながら、未署名の更新のみを受信できることです。したがって、更新の検証を実行したり、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 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.
顧客のASがRPKI（CA）証明書を取得し、そのCA証明書に基づいてルーター証明書を発行し、秘密鍵を渡す場合、ISPのAS（または上流のAS）は、顧客（下流）のASのBGPアナウンスにプロキシ署名できます。その証明書を上流のプロバイダーに送信します。そのISP（つまり、2番目のホップのAS）は、顧客ASから提供された秘密キーを使用して、顧客ASに代わって署名を挿入します。これは2つのAS間のプライベートな配置であり、他のASからは見えません。したがって、この配置は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）が2つのISP、つまり、それぞれISP-1とISP-2のAS1とAS2を持つAS8ピアにマルチホーム化されているシナリオを考えます。この場合、AS8にはRPKI（CA）証明書があります。そのCA証明書の下で2つの個別のルーター証明書（AS1とAS2に対応）を発行し、それら2つの証明書のそれぞれの秘密キーを上流のプロバイダーAS1とAS2に渡します。したがって、AS8には、両方の上流ASからのプロキシ署名サービスがあります。将来、AS8がISP-2から切断すると、AS2に対応するルーター証明書が取り消されます。
No problems are anticipated when BGPsec-capable ASes have multiple peering sessions between them (between distinct routers).
BGPsec対応のASがそれらの間（異なるルーター間）に複数のピアリングセッションを持っている場合、問題は予期されません。
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では、（2つの隣接AS間の）ルーターの異なるペア間の複数のピアリングセッションを同時に負荷分散に使用できます。同様に、BGPsec対応のASは、それらの間に複数のピアリングセッションを持つこともできます。 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.
ロードバランシングに関するこの決定（1つのピアリングセッションをプライマリデータとして使用し、別のピアリングセッションをバックアップとして使用するかどうか）は完全にローカルであり、2つの隣接ASに依存します。
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ルーターで使用され、更新を生成および送信する際の処理を節約します。同じポリシーが適用される複数のピアをピアグループに編成できます。ピアグループには通常、数十（場合によっては300）のASを含めることができます。
It was decided that BGPsec updates are generated to target unique AS peers, so there is no support for peer groups in BGPsec.
一意のASピアを対象とするBGPsec更新が生成されることが決定されたため、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で行われているように、更新ごとに1回だけ実行できます。更新を転送する前に、BGPsecスピーカーはピアのASNを署名が必要なデータに追加し、グループ内の各ピアASの更新に個別に署名します。
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クラウドであり、複数のメンバーASが含まれています。 Member-ASは、同じコンフェデレーション内の別のMember-ASに送信された更新に署名する必要はありません。ただし、コンフェデレーション内のeBGPでBGPsec署名が適用されている場合、つまり各メンバーASがコンフェデレーション内のパス内の次のメンバーASに署名している場合、コンフェデレーションからの出力時に、境界のメンバーASは連合内で適用されるすべての署名。コンフェデレーションの境界にあるMember-ASは、コンフェデレーションの公開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では、更新が連合内のシグニチャーで伝搬される場合、連合内のMember-AS間のBGPsec更新に署名する必要があります。 Confed_Segmentフラグは各Secure_Pathセグメントに存在し、設定されている場合、対応する署名がMember-ASに属していることを示します。コンフェデレーション境界では、Confed_Segmentフラグが設定されているすべてのシグネチャが更新から削除されます。 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（ASプリペンドカウント）フィールドはゼロに設定されます（[RFC8205]のセクション4.2を参照）。 pCount = 0の誤用を防ぐための運用ガイダンスは、RFC 8205のセクション7.2に記載されています。また、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がルートを伝播するために使用できる方法は基本的に3つあります。（A）IXPを介した直接双方向ピアリング、（B）IXPのルートサーバーとのピアリングによるクライアント間のBGPピアリング（パスにAXPを挿入するIXPなし） ）、および（C）IXPルートサーバーとのBGPピアリング、ここでIXPはパスにASNを挿入します。 （注：IXPのルートサーバーは、パスにASNを挿入してもNEXT_HOP属性を変更しません。）IXPがメソッドCを使用することは非常にまれです。 1つはIXPによるものです。方法Aと方法Bの使用範囲の測定値は、対応するIPトラフィックの負荷の割合で示されます。例として、主要なヨーロッパのIXPでは、これらの割合はメソッドAとBでそれぞれ約80％と20％です（このデータは、2011年頃のIXPとのプライベート通信に基づいています）。ただし、IXPが（クライアント数の観点から）大きくなると、メソッドAではn個のピア間の最大n x（n-1）/ 2個の直接相互接続を管理することが困難になるため、メソッドBに移行する傾向があります。
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).
プロキシ集約（つまり、ASパスでのAS_SETの使用）は、BGPsecではサポートされません。 AS_SETがASパスの一部である場合、BGPsecには更新に署名するためのプロビジョニングがありません。 BGPsec対応のルーターがAS_SETを含む更新を受信し、更新が署名されていることを検出した場合、ルーターは更新の形式が正しくないと見なします（つまり、プロトコルエラー）。
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]で定義されている「treat-as-withdraw」アプローチを使用して、BGPsec_PATH属性の構文エラーまたはプロトコルエラーを処理する必要がある」と規定しています。
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_SETを含みます。従来のBGPは現在、ASパスにAS_SETを含めることでプロキシ集約を許可しているため、このような更新を認証で受信した場合に受信側ルーターが実行する必要があるアクションをBGPsecで指定する必要があります。 BCP 172 [RFC6472]は、アップデートでのAS_SETの使用を推奨していません。そのため、AS_SETの使用は時間とともに減少することが予想されます。
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）に変換する必要があります。 ASN変換はルート変更攻撃と同等であり、変換された4バイトASNに対応する署名が検証に失敗するため、このメカニズムはBGPsecの使用と互換性がありません。
BGP speakers that are BGPsec capable are required to process 4-byte ASNs.
4バイトのASNを処理するには、BGPsec対応のBGPスピーカーが必要です。
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-Initial]には次の手順が含まれています。ただし、これらの検証処理手順の順序は、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パス内のASの数と一致しているかどうかを確認します（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と一致することを確認します。 target-ASNチェックも非暗号化操作であり、高速であることに注意してください。
5. Validate the signature data starting from the most recent AS to the origin.
5. 最新のASから起点までの署名データを検証します。
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. 署名アルゴリズムの対象となるデータをハッシュします。ローカルで計算されたハッシュ、受信した署名、公開鍵の3つの入力で署名検証アルゴリズムを呼び出します。有効または無効の1つの出力があります。
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. （a）オリジンASの署名データが検出されて処理されるか、または（b）これらのステップのいずれかが失敗するまで、Signature_Block内の先行する各署名について手順5と6を繰り返します。
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で提示および説明されています。また、Signature_Blocksの検証で従うべき論理的な手順のシーケンスは、[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.
暗号化操作に関連する計算コストを最小化することが目的である場合、上記で提案された一連の受信者操作は適切と見なされます。もう1つの興味深い提案は、更新に2つのSignature_Blockがある場合、検証ルーターは最初に2つのアルゴリズムのどちらが安価であるかを確認して、処理を節約することです。そのSignature_Blockが検証すると、ルーターは他の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.
異なるルーター（同じASまたは異なるAS内）でのRPKIデータの可用性は、RPKIデータの取得に使用されるソースに応じて異なる場合があります。したがって、更新は1つのASでの検証に失敗し、同じ更新が別のASでの検証に合格する場合があります。また、更新はAS内の1つのルーターでの検証に失敗し、同じ更新が同じ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は後で公開される可能性があり、更新を拒否する明確なケースを提示する可能性があるいくつかの更新失敗条件を特定します（この場合、ルーターは更新で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パス内のASの数と一致しない（ASの先頭に追加した後）、（B）受信した更新にAS_SETがあり、更新に署名がある、または（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更新として）届く場合があります。後者の場合、ルートは問題のAS内から発信されています。
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.
注：プライベートASNのコンテキストにおけるBGPsecの運用上の考慮事項については、[RFC8205]のセクション7.5を参照してください。
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_SETとBGPsec_PATHの両方のような構文エラー条件が更新に含まれている場合、（B）シグネチャの数がASの数と一致しない（ASの先頭に追加した後）、または（C）解析の問題BGPsec_PATH属性を使用して発生した場合、更新は（シグネチャが除去された状態で）ベストパス選択アルゴリズムで引き続き考慮されます。 （**注：これは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.
更新に2つのSignature_Blockがあり、1つ以上の構文エラーがそれらの1つ内で発生していることが検出されたが、もう1つには構文エラーがない場合、更新は引き続き最良パスで考慮されます。構文的に不良なSignature_Blockの後の選択アルゴリズムが削除されました。 （**注：これはRFC 8205 **では当てはまりません。）更新が最適なパスとして選択されている場合、更新は1つだけ（つまり、エラーのない）Signature_Blockで伝播されます。エラー状態はローカルに記録されます。
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検証結果は、次の2つの検証状態のいずれかにマッピングされることが決定されました：（1）有効-すべての検証チェックに合格（つまり、有効期限チェック、ルートの起点とSignature_Block検証）および（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. 署名チェックが実行され、そのうちの1つ以上が失敗しました。
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:
最初は、4つの検証状態が検討されました。
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検証の結果は2つの検証状態のいずれかにマッピングされることが後で決定されました。更新は、さまざまな理由で無効になる可能性があることが確認されました。これらの多数の理由を区別し始め、無効な状態のさまざまなフレーバーを列挙しようとすることは、ルート選択の決定において建設的になる可能性は低く、システムに新しい脆弱性をもたらすことさえあります。ただし、次のようないくつかの質問は残っています。
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?
残りのもう1つの質問：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などのメトリック値の変更など、さまざまな既存のメカニズムを使用して、検証ステータスが内部的に伝達される方法を決定します。検証できない署名付き更新（構文エラーのあるものを除く）は、署名と共に入力ルーターから出力ルーターに転送する必要があります。ここで、隣接AS内の他のeBGPsecスピーカーに向けて伝達されるときに署名されます。完全にローカルポリシー設定に基づいて、出力ルーターは入力ルーターによって伝達された検証ステータスを信頼するか、独自の検証を実行します。後者のアプローチは、RPKIスキューがAS内の異なるルーターで発生することがわかっている状況下で、オペレーターの裁量で使用できます。
Note: An extended community for carrying the origin validation state in iBGP has been specified in RFC 8097 [RFC8097].
注：iBGPで発信元検証状態を伝達するための拡張コミュニティは、RFC 8097 [RFC8097]で指定されています。
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.
必要に応じて、検証状態を表すために使用される属性をAS間で伝達できます。 ISPは、自身のAS（兄弟ASなど）間のeBGPリンクを介してそれを実行したい場合があります。ピア（または顧客）は、プロバイダーからeBGPリンクを介してそれを受信し、それを使用して独自の検証チェックをショートカットすることができます。ただし、ピア（または顧客）は、このvalidation-state属性がネイバーの検証のプレビューにすぎず、更新の検証の実際の状態を確認するために独自の検証チェックを実行する必要があることを認識する必要があります。質問：検証目的の伝播が診断目的で役立つ場合、検証によって伝播を保護する必要がありますか？署名を使用して検証状態情報を保護しないように決定されました。
The following validation states may be needed for propagation via iBGP between edge routers in an AS:
ASのエッジルータ間でiBGPを介して伝播するには、次の検証状態が必要になる場合があります。
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）NotFound（[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.
* 更新は、次の2つの理由のいずれかで署名されていない可能性がありますが、それらを区別する必要はありません：（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-Initial]の作成後は、運用と管理の考慮事項にかなりの注意が払われています。詳細については、[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セッションが再起動されている）がデータプレーンが機能しているときに、ノンストップパケット転送を容易にするために現在使用されているメカニズムです。 2つの質問が提起されました。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-Initial]が書かれた時点）。
Note: See Section 7.7 of [RFC8205] for comments concerning the operation of BGP-GR with BGPsec. They are consistent with the discussion below.
注：BGPsecを使用したBGP-GRの操作に関するコメントについては、[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は、従来のBGPで現在実装されているのと同じように、BGPsecで実装できます。 Restart Stateビット、Forwarding Stateビット、End-of-RIBマーカー、stalenessマーカー（Adj-RIB-In内）、およびSelection_Deferral_Timerは、BGP-GR [RFC4724]に関連する主要なパラメーターです。これらのパラメーターは、従来のBGPに適用されるのと同じように、BGPsecに適用されます。
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 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.
BGPルーターが従来のBGPからBGP-GR、BGPsecに移行するとどうなるかについては、答えは次のようになります。 BGP-GR中にBGPsecへのソフトウェアアップグレードがある場合（アップグレードがライブBGPスピーカーで行われていると想定）、BGPsecセッションが開始される前にBGP-GRセッションを終了する必要があります。 eBGPsecピアリングセッションが確立されると、受信側のeBGPsecスピーカーには、送信側（新しくアップグレードされた）eBGPsecスピーカーからの署名付き更新が表示されます。新しいBGPsecルートに置き換えられるまで、受信スピーカーが送信スピーカーから以前に学習した未署名のBGPルートを引き続き使用する場合は、明らかな害はありません（実際には望ましいかもしれません）。ただし、BGPsecセッションネゴシエーション中に送信側スピーカー（つまり、新しくアップグレードされたスピーカー）によってForwarding Stateビットがゼロに設定されている場合、受信側スピーカーは、その送信側スピーカーから以前に学習したすべての未署名BGPルートをその「古い」としてマークします。 Adj-RIB-In。次に、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.
BGPsecでのチャーンを最小限に抑えるためのBCPの推奨事項について説明しました。証明書の有効期限/失効や署名の有効期限切れなど、ルーターがイベントにどのように反応するかについては、さまざまな潜在的な戦略があります[動的]。詳細は、追加作業が完了した後、近い将来に文書化されます。
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:
おそらく、パス検証を実行するオフルーターボックス（ASごとに1つ以上）を使用できます。たとえば、これらの機能をルートリフレクタに組み込むことができます。入力ルータでは、検証された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とハードウェア暗号化支援のためのより多くのメモリを必要とすると想定されています。ただし、スタブASは、アップストリームASと非対称BGPsec機能をネゴシエートできるため、そのようなアップグレードを行う必要はありません。つまり、アップストリームASへの更新に署名しますが、署名されていない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対応のASの外部に送信されないため、最初の導入時に追加の（RIB）メモリがどれだけ必要になるかは明確ではありません。 BGPsec RIBサイズとその予測される成長のモデリングと推定に関する予備的な結果については、[RIB_size]を参照してください。ハードウェア暗号化サポートにより、ルートプロセッサの計算負荷が軽減され、ルータの秘密鍵に優れたセキュリティが提供されます。ただし、増分展開モデルを考えると、展開の初期段階で暗号処理の負荷がどの程度発生するかも明確ではありません。
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]では、暗号化処理の計算最適化（つまり、ECDSAの高速化）が、汎用CPUでのBGPsec実装に対して考慮されています。 [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>.
[ASset] Sriram、K.およびD. Montgomery、「AS_SETおよびAGGREGATORの測定データ：{Prefix、Origin}検証アルゴリズムの影響」、IETF SIDR WGプレゼンテーション、IETF 78、2010年7月、<http：//www.nist .gov / itl / antd / upload / AS_SET_Aggregator_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の拡張メッセージサポート」、作業中、draft-ietf-idr-bgp-extended-messages-24、2017年11月。
[BGPsec-Initial] Lepinski, M., "BGPSEC Protocol Specification", Work in Progress, draft-lepinski-bgpsec-protocol-00, March 2011.
[BGPsec-Initial] Lepinski、M。、「BGPSEC Protocol Specification」、Work in Progress、draft-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-Rollover] Weis、B.、Gagliano、R。、およびK. Patel、「BGPsecルーター証明書のロールオーバー」、作業中、draft-ietf-sidrops-bgpsec-rollover-04、2017年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、「Subject：Modifiation [sic] request：draft-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：Configuring Route Dampening」、2014年2月、<https://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/ configuration / 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、「Estimating CPU Cost of BGPSEC on a Router」、RIPE-63で発表。また、2012年3月のIETF 83 SIDR WG会議<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作成者/デザイナーチームへのプレゼンテーション、10月2009、<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、「高速およびサイドチャネルで保護されたNIST P-256楕円曲線のx86-64プラットフォーム用の実装」、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-using-routing -policies-to-damp-bgp-route-flapping.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.、「件名：wglc for draft-ietf-sidr-bgpsec-protocol-11（特定のトピック：署名の下で保護されたデータにアドレスファミリ識別子を含める-セキュリティ上の懸念を軽減するため）」、メッセージIETF SIDR WGメーリングリスト、2015年2月10日、<https://www.ietf.org/ mail-archive / 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。、「件名：draft-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の効率的で安全な楕円曲線暗号化の実装」、ECC標準に関するNISTワークショップ、2015年6月、<http://csrc.nist.gov/groups/ST/ecc-workshop -2015 / papers / session6-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、「High Performance BGP Security：Algorithms and Architectures」、北米ネットワークオペレーターグループミーティング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。、「Decoupling BGPsec Documents and Extended Messages draft」、IETF SIDROPS WGミーティング、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.
[リプレイ保護]スリラム、K。、およびD.モンゴメリー、「BGPsecでのリプレイ攻撃および離脱抑制の設計メカニズムと保護メカニズムの比較」、Work in Progress、draft-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 Route Flap Damping」、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。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 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]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「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、「Fundamental Elliptic Curve Cryptography Algorithms」、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_SETおよびAS_CONFED_SETを使用しない場合の推奨事項」、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、「An Secure Infrastructure to Support Internet Routing」、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、「A Route for Route Origin Authorizations（ROAs）」、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、「Validation of Route Origination Using the Resource Certificate Public Key Infrastructure（PKI）and Route Origin Authorizations（ROAs）」、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 Support for Four-Octet Autonomous System（AS）Number Space」、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 Prefix Origin Validation」、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。、編、Scudder、J。、編、Mohapatra、P。、およびK. Patel、「BGP UPDATEメッセージのエラー処理の改訂版」、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 Prefix Origin Validation State Extended Community」、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。、編、およびK. Sriram、編、「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] Bush、R。、「BGPsec Operational Considerations」、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]ターナー、S。およびO.ボーチャート、「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]レイノルズ、M。、ターナー、S。、およびS.ケント、「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>.
[RIB_size] Sriram、K.、et al。、 "RIB Size Estimation for BGPSEC"、May 2011、<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.、et al。、 "RIPE-580：RIPE Routing Working Group Recommendations on Route Flap Damping"、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.
[Secure-BGP] Lynn、C.、Mikkelson、J。、およびK. Seo、「Secure BGP（S-BGP）」、Work in Progress、draft-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セキュリティプロトコルでの暗号処理を最小限に抑えるための最適化アルゴリズムの設計と分析」、Computer Communications、Vol。 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.
著者は、Independent Submissionsストリームのこのドキュメントのレビュー担当者を務めてくれたJeff HaasとWes Georgeに感謝します。著者は、独立した提出のレビュープロセスを通じてこのドキュメントを提出してくれたNevil Brownleeに感謝します。 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にも感謝します。 、プラドシュモハパトラ、マークレイノルズ、ヘザーシラー、ジェイソンシラー、ルーディガーボルク、デビッドウォードのレビュー、コメント、およびこの作業の過程での提案について。
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 Research Labsメール：sra@hactrn.net
Steven Bellovin Columbia University Email: smb@cs.columbia.edu
スティーブンベロビンコロンビア大学Eメール：smb@cs.columbia.edu
Russ Housley Vigil Security, LLC Email: housley@vigilsec.com Stephen Kent Independent Email: kent@alum.mit.edu
Russ Housley Vigil Security、LLCメール：housley@vigilsec.comスティーブンケント独立メール：kent@alum.mit.edu
Warren Kumari Google Email: warren@kumari.net
Warren Kumari Googleメール：warren@kumari.net
Matt Lepinski New College of Florida Email: mlepinski@ncf.edu
マットレピンスキーフロリダ大学（ニューカレッジ）メール：mlepinski@ncf.edu
Doug Montgomery USA National Institute of Standards and Technology Email: dougm@nist.gov
Doug Montgomery USA National Institute of Standards and Technologyメール：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
Keur Patel Rerkus Eメール：KeurRerkus.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
サミュエルワイラー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ゲーサーズバーグ、MD 20899アメリカ合衆国
Email: ksriram@nist.gov