[要約] RFC 8205は、BGPセキュリティ（BGPsec）プロトコルの仕様を定義しています。このRFCの目的は、BGPルーティングプロトコルのセキュリティを向上させ、偽装や改ざんなどの攻撃からネットワークを保護することです。
Internet Engineering Task Force (IETF) M. Lepinski, Ed.
Request for Comments: 8205 NCF
Category: Standards Track K. Sriram, Ed.
ISSN: 2070-1721 NIST
September 2017
BGPsec Protocol Specification
BGPsecプロトコル仕様
Abstract
概要
This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.
このドキュメントでは、BGP UPDATEメッセージが通過する自律システム（AS）のパスにセキュリティを提供するボーダーゲートウェイプロトコル（BGP）の拡張機能であるBGPsecについて説明します。 BGPsecは、UPDATEメッセージを伝播する各ASによって生成されたデジタル署名を運ぶオプションの非推移的BGPパス属性を介して実装されます。デジタル署名は、UPDATEメッセージにリストされたASのパス上のすべてのASがルートのアドバタイズを明示的に承認したことを確信させます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8205.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8205で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . 3
2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 4
2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . 5
3. The BGPsec_PATH Attribute . . . . . . . . . . . . . . . . . . 6
3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 10
4. BGPsec UPDATE Messages . . . . . . . . . . . . . . . . . . . 11
4.1. General Guidance . . . . . . . . . . . . . . . . . . . . 11
4.2. Constructing the BGPsec_PATH Attribute . . . . . . . . . 14
4.3. Processing Instructions for Confederation Members . . . . 18
4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . 19
5. Processing a Received BGPsec UPDATE Message . . . . . . . . . 21
5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 23
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . 27
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . 27
6.2. Considerations for the SKI Size . . . . . . . . . . . . . 28
6.3. Extensibility Considerations . . . . . . . . . . . . . . 28
7. Operations and Management Considerations . . . . . . . . . . 29
7.1. Capability Negotiation Failure . . . . . . . . . . . . . 29
7.2. Preventing Misuse of pCount=0 . . . . . . . . . . . . . . 29
7.3. Early Termination of Signature Verification . . . . . . . 30
7.4. Non-deterministic Signature Algorithms . . . . . . . . . 30
7.5. Private AS Numbers . . . . . . . . . . . . . . . . . . . 30
7.6. Robustness Considerations for Accessing RPKI Data . . . . 32
7.7. Graceful Restart . . . . . . . . . . . . . . . . . . . . 32
7.8. Robustness of Secret Random Number in ECDSA . . . . . . . 32
7.9. Incremental/Partial Deployment Considerations . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 33
8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 34
8.3. Mitigation of Denial-of-Service Attacks . . . . . . . . . 36
8.4. Additional Security Considerations . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
This document describes BGPsec, a mechanism for providing path security for Border Gateway Protocol (BGP) [RFC4271] route advertisements. That is, a BGP speaker who receives a valid BGPsec UPDATE message has cryptographic assurance that the advertised route has the following property: every Autonomous System (AS) on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route to the subsequent AS in the path.
このドキュメントでは、ボーダーゲートウェイプロトコル（BGP）[RFC4271]ルートアドバタイズメントにパスセキュリティを提供するメカニズムであるBGPsecについて説明します。つまり、有効なBGPsec UPDATEメッセージを受信するBGPスピーカーは、アドバタイズされたルートに次のプロパティがあることを暗号で保証します。UPDATEメッセージにリストされているASのパス上のすべての自律システム（AS）は、ルートのアドバタイズを明示的に承認していますパス内の後続のAS。
This document specifies an optional (non-transitive) BGP path attribute, BGPsec_PATH. It also describes how a BGPsec-compliant BGP speaker (referred to hereafter as a BGPsec speaker) can generate, propagate, and validate BGP UPDATE messages containing this attribute to obtain the above assurances.
このドキュメントでは、オプションの（非推移的な）BGPパス属性BGPsec_PATHを指定しています。また、BGPsec準拠のBGPスピーカー（以降、BGPsecスピーカーと呼びます）が、この属性を含むBGP UPDATEメッセージを生成、伝播、および検証して、上記の保証を取得する方法についても説明します。
BGPsec is intended to be used to supplement BGP origin validation [RFC6483] [RFC6811], and when used in conjunction with origin validation, it is possible to prevent a wide variety of route hijacking attacks against BGP.
BGPsecは、BGPオリジン検証[RFC6483] [RFC6811]を補足するために使用することを目的としており、オリジン検証と組み合わせて使用すると、BGPに対するさまざまなルートハイジャック攻撃を防ぐことができます。
BGPsec relies on the Resource Public Key Infrastructure (RPKI) certificates that attest to the allocation of AS number and IP address resources. (For more information on the RPKI, see RFC 6480 [RFC6480] and the documents referenced therein.) Any BGPsec speaker who wishes to send, to external (eBGP) peers, BGP UPDATE messages containing the BGPsec_PATH needs to possess a private key associated with an RPKI router certificate [RFC8209] that corresponds to the BGPsec speaker's AS number. Note, however, that a BGPsec speaker does not need such a certificate in order to validate received UPDATE messages containing the BGPsec_PATH attribute (see Section 5.2).
BGPsecは、AS番号とIPアドレスリソースの割り当てを証明するResource Public Key Infrastructure（RPKI）証明書に依存しています。 （RPKIの詳細については、RFC 6480 [RFC6480]とその中で参照されているドキュメントを参照してください。）外部（eBGP）ピアに、BGPsec_PATHを含むBGP UPDATEメッセージを送信したいすべてのBGPsecスピーカーは、 BGPsecスピーカーのAS番号に対応するRPKIルーター証明書[RFC8209]。ただし、BGPsec_PATH属性を含む受信したUPDATEメッセージを検証するために、BGPsecスピーカーがそのような証明書を必要としないことに注意してください（セクション5.2を参照）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document defines a BGP capability [RFC5492] that allows a BGP speaker to advertise to a neighbor the ability to send or to receive BGPsec UPDATE messages (i.e., UPDATE messages containing the BGPsec_PATH attribute).
このドキュメントでは、BGPスピーカーがBGPsec UPDATEメッセージ（つまり、BGPsec_PATH属性を含むUPDATEメッセージ）を送信または受信する機能をネイバーにアドバタイズできるようにするBGP機能[RFC5492]を定義しています。
This capability has capability code 7.
この機能には、機能コード7があります。
The capability length for this capability MUST be set to 3.
この機能の機能長は3に設定する必要があります。
The 3 octets of the capability format are specified in Figure 1.
機能フォーマットの3オクテットを図1に示します。
0 1 2 3 4 5 6 7
+---------------------------------------+
| Version | Dir | Unassigned |
+---------------------------------------+
| |
+------ AFI -----+
| |
+---------------------------------------+
Figure 1: BGPsec Capability Format
図1：BGPsec機能の形式
The first 4 bits of the first octet indicate the version of BGPsec for which the BGP speaker is advertising support. This document defines only BGPsec version 0 (all 4 bits set to 0). Other versions of BGPsec may be defined in future documents. A BGPsec speaker MAY advertise support for multiple versions of BGPsec by including multiple versions of the BGPsec capability in its BGP OPEN message.
最初のオクテットの最初の4ビットは、BGPスピーカーがサポートをアドバタイズしているBGPsecのバージョンを示します。このドキュメントでは、BGPsecバージョン0（4ビットすべてを0に設定）のみを定義しています。 BGPsecの他のバージョンは、将来のドキュメントで定義される可能性があります。 BGPsecスピーカーは、BGP OPENメッセージに複数のバージョンのBGPsec機能を含めることにより、複数のバージョンのBGPsecのサポートを通知できます（MAY）。
The fifth bit of the first octet is a Direction bit, which indicates whether the BGP speaker is advertising the capability to send BGPsec UPDATE messages or receive BGPsec UPDATE messages. The BGP speaker sets this bit to 0 to indicate the capability to receive BGPsec UPDATE messages. The BGP speaker sets this bit to 1 to indicate the capability to send BGPsec UPDATE messages.
最初のオクテットの5番目のビットは方向ビットです。これは、BGPスピーカーがBGPsec UPDATEメッセージを送信する機能をアドバタイズするか、BGPsec UPDATEメッセージを受信する機能をアドバタイズするかどうかを示します。 BGPスピーカーはこのビットを0に設定して、BGPsec UPDATEメッセージを受信する機能を示します。 BGPスピーカーは、このビットを1に設定して、BGPsec UPDATEメッセージを送信する機能を示します。
The remaining 3 bits of the first octet are unassigned and for future use. These bits are set to 0 by the sender of the capability and ignored by the receiver of the capability.
最初のオクテットの残りの3ビットは割り当てられておらず、将来の使用に備えています。これらのビットは、機能の送信側によって0に設定され、機能の受信側によって無視されます。
The second and third octets contain the 16-bit Address Family Identifier (AFI), which indicates the address family for which the BGPsec speaker is advertising support for BGPsec. This document only specifies BGPsec for use with two address families, IPv4 and IPv6, with AFI values 1 and 2, respectively [IANA-AF]. BGPsec for use with other address families may be specified in future documents.
2番目と3番目のオクテットには、BGPsecスピーカーがBGPsecのサポートをアドバタイズしているアドレスファミリを示す16ビットのアドレスファミリ識別子（AFI）が含まれています。このドキュメントでは、IPv4とIPv6の2つのアドレスファミリで使用するBGPsecのみを指定し、AFI値はそれぞれ1と2です[IANA-AF]。他のアドレスファミリで使用するBGPsecは、将来のドキュメントで指定される可能性があります。
In order to indicate that a BGP speaker is willing to send BGPsec UPDATE messages (for a particular address family), a BGP speaker sends the BGPsec capability (see Section 2.1) with the Direction bit (the fifth bit of the first octet) set to 1. In order to indicate that the speaker is willing to receive BGP UPDATE messages containing the BGPsec_PATH attribute (for a particular address family), a BGP speaker sends the BGPsec capability with the Direction bit set to 0. In order to advertise the capability to both send and receive BGPsec UPDATE messages, the BGP speaker sends two copies of the BGPsec capability (one with the Direction bit set to 0 and one with the Direction bit set to 1).
BGPスピーカーが（特定のアドレスファミリの）BGPsec UPDATEメッセージを送信する意思があることを示すために、BGPスピーカーは方向ビット（最初のオクテットの5番目のビット）を設定してBGPsec機能（セクション2.1を参照）を送信します1.スピーカーがBGPsec_PATH属性（特定のアドレスファミリ用）を含むBGP UPDATEメッセージを受信する意思があることを示すために、BGPスピーカーは方向ビットが0に設定されたBGPsec機能を送信します。機能をアドバタイズするには、 BGPsec UPDATEメッセージの送受信の両方で、BGPスピーカーはBGPsec機能の2つのコピーを送信します（1つは方向ビットが0に設定され、もう1つは方向ビットが1に設定されています）。
Similarly, if a BGP speaker wishes to use BGPsec with two different address families (i.e., IPv4 and IPv6) over the same BGP session, then the speaker includes two instances of this capability (one for each address family) in the BGP OPEN message. A BGP speaker MUST NOT announce BGPsec capability if it does not support the BGP multiprotocol extension [RFC4760]. Additionally, a BGP speaker MUST NOT advertise the capability of BGPsec support for a particular AFI unless it has also advertised the multiprotocol extension capability for the same AFI [RFC4760].
同様に、BGPスピーカーが同じBGPセッションで2つの異なるアドレスファミリ（IPv4とIPv6）でBGPsecを使用する場合、スピーカーはこの機能の2つのインスタンス（各アドレスファミリに1つ）をBGP OPENメッセージに含めます。 BGPスピーカーは、BGPマルチプロトコル拡張[RFC4760]をサポートしていない場合、BGPsec機能をアナウンスしてはなりません（MUST NOT）。さらに、BGPスピーカーは、同じAFIのマルチプロトコル拡張機能もアドバタイズしていない限り、特定のAFIのBGPsecサポートの機能をアドバタイズしてはなりません[RFC4760]。
In a BGPsec peering session, a peer is permitted to send UPDATE messages containing the BGPsec_PATH attribute if and only if:
BGPsecピアリングセッションでは、次の場合に限り、ピアはBGPsec_PATH属性を含むUPDATEメッセージを送信できます。
o The given peer sent the BGPsec capability for a particular version of BGPsec and a particular address family with the Direction bit set to 1, and
o 指定されたピアが、BGPsecの特定のバージョンのBGPsec機能と、方向ビットが1に設定された特定のアドレスファミリを送信しました。
o The other (receiving) peer sent the BGPsec capability for the same version of BGPsec and the same address family with the Direction bit set to 0.
o もう一方の（受信）ピアは、方向ビットが0に設定された、同じバージョンのBGPsecと同じアドレスファミリのBGPsec機能を送信しました。
In such a session, it can be said that the use of the particular version of BGPsec has been negotiated for a particular address family. Traditional BGP UPDATE messages (i.e., unsigned, containing the AS_PATH attribute) MAY be sent within a session regardless of whether or not the use of BGPsec is successfully negotiated. However, if BGPsec is not successfully negotiated, then BGP UPDATE messages containing the BGPsec_PATH attribute MUST NOT be sent.
このようなセッションでは、特定のバージョンのBGPsecの使用が特定のアドレスファミリに対してネゴシエートされたと言えます。従来のBGP UPDATEメッセージ（つまり、署名なし、AS_PATH属性を含む）は、BGPsecの使用が正常にネゴシエートされたかどうかに関係なく、セッション内で送信できます（MAY）。ただし、BGPsecが正常にネゴシエートされない場合、BGPsec_PATH属性を含むBGP UPDATEメッセージを送信してはなりません（MUST NOT）。
This document defines the behavior of implementations in the case where BGPsec version 0 is the only version that has been successfully negotiated. Any future document that specifies additional versions of BGPsec will need to specify behavior in the case that support for multiple versions is negotiated.
このドキュメントでは、BGPsecバージョン0がネゴシエーションに成功した唯一のバージョンである場合の実装の動作を定義しています。 BGPsecの追加バージョンを指定する今後のドキュメントでは、複数のバージョンのサポートがネゴシエートされる場合の動作を指定する必要があります。
BGPsec cannot provide meaningful security guarantees without support for 4-byte AS numbers. Therefore, any BGP speaker that announces the BGPsec capability, MUST also announce the capability for 4-byte AS support [RFC6793]. If a BGP speaker sends the BGPsec capability but not the 4-byte AS support capability, then BGPsec has not been successfully negotiated, and UPDATE messages containing the BGPsec_PATH attribute MUST NOT be sent within such a session.
BGPsecは、4バイトのAS番号をサポートしないと、意味のあるセキュリティを保証できません。したがって、BGPsec機能を発表するすべてのBGPスピーカーは、4バイトASサポートの機能も発表する必要があります[RFC6793]。 BGPスピーカーがBGPsec機能を送信し、4バイトのASサポート機能を送信しない場合、BGPsecは正常にネゴシエートされていないため、BGPsec_PATH属性を含むUPDATEメッセージをそのようなセッション内で送信してはなりません（MUST NOT）。
The BGPsec_PATH attribute is an optional non-transitive BGP path attribute.
BGPsec_PATH属性は、オプションの非推移的なBGPパス属性です。
This document registers an attribute type code for this attribute: BGPsec_PATH (see Section 9).
このドキュメントでは、この属性の属性タイプコードBGPsec_PATHを登録します（セクション9を参照）。
The BGPsec_PATH attribute carries the secured information regarding the path of ASes through which an UPDATE message passes. This includes the digital signatures used to protect the path information. The UPDATE messages that contain the BGPsec_PATH attribute are referred to as "BGPsec UPDATE messages". The BGPsec_PATH attribute replaces the AS_PATH attribute in a BGPsec UPDATE message. That is, UPDATE messages that contain the BGPsec_PATH attribute MUST NOT contain the AS_PATH attribute, and vice versa.
BGPsec_PATH属性は、UPDATEメッセージが通過するASのパスに関する保護された情報を伝達します。これには、パス情報を保護するために使用されるデジタル署名が含まれます。 BGPsec_PATH属性を含むUPDATEメッセージは、「BGPsec UPDATEメッセージ」と呼ばれます。 BGPsec_PATH属性は、BGPsec UPDATEメッセージのAS_PATH属性を置き換えます。つまり、BGPsec_PATH属性を含むUPDATEメッセージにAS_PATH属性を含めることはできません（逆も同様）。
The BGPsec_PATH attribute is made up of several parts. The high-level diagram in Figure 2 provides an overview of the structure of the BGPsec_PATH attribute. ("SKI" as used in Figure 2 means "Subject Key Identifier".)
BGPsec_PATH属性は、いくつかの部分で構成されています。図2の概要図は、BGPsec_PATH属性の構造の概要を示しています。 （図2で使用されている「SKI」は「サブジェクトキー識別子」を意味します。）
+---------------------------------------------------------+
| +-----------------+ |
| | Secure_Path | |
| +-----------------+ |
| | pCount X | |
| | Flags X | |
| | AS X | |
| | pCount Y | |
| | Flags Y | |
| | AS Y | |
| | ... | |
| +-----------------+ |
| |
| +---------------------+ +---------------------+ |
| | Signature_Block 1 | | Signature_Block 2 | |
| +---------------------+ +---------------------+ |
| | Algorithm Suite 1 | | Algorithm Suite 2 | |
| | SKI X1 | | SKI X2 | |
| | Signature X1 | | Signature X2 | |
| | SKI Y1 | | SKI Y2 | |
| | Signature Y1 | | Signature Y2 | |
| | ... | | .... | |
| +---------------------+ +---------------------+ |
| |
+---------------------------------------------------------+
Figure 2: High-Level Diagram of the BGPsec_PATH Attribute
図2：BGPsec_PATH属性の概要図
Figure 3 provides the specification of the format for the BGPsec_PATH attribute.
図3は、BGPsec_PATH属性の形式の仕様を示しています。
+-------------------------------------------------------+
| Secure_Path (variable) |
+-------------------------------------------------------+
| Sequence of one or two Signature_Blocks (variable) |
+-------------------------------------------------------+
Figure 3: BGPsec_PATH Attribute Format
図3：BGPsec_PATH属性の形式
The Secure_Path contains AS path information for the BGPsec UPDATE message. This is logically equivalent to the information that is contained in a non-BGPsec AS_PATH attribute. The information in the Secure_Path is used by BGPsec speakers in the same way that information from the AS_PATH is used by non-BGPsec speakers. The format of the Secure_Path is described below in Section 3.1.
Secure_Pathには、BGPsec UPDATEメッセージのASパス情報が含まれています。これは、非BGPsec AS_PATH属性に含まれる情報と論理的に同等です。 Secure_Path内の情報は、AS_PATHからの情報が非BGPsecスピーカーによって使用されるのと同じ方法でBGPsecスピーカーによって使用されます。 Secure_Pathの形式については、セクション3.1で説明します。
The BGPsec_PATH attribute will contain one or two Signature_Blocks, each of which corresponds to a different algorithm suite. Each of the Signature_Blocks will contain a Signature Segment for each AS number (i.e., Secure_Path Segment) in the Secure_Path. In the most common case, the BGPsec_PATH attribute will contain only a single Signature_Block. However, in order to enable a transition from an old algorithm suite to a new algorithm suite (without a flag day), it will be necessary to include two Signature_Blocks (one for the old algorithm suite and one for the new algorithm suite) during the transition period. (See Section 6.1 for more discussion of algorithm transitions.) The format of the Signature_Blocks is described below in Section 3.2.
BGPsec_PATH属性には、1つまたは2つのSignature_Blocksが含まれ、それぞれが異なるアルゴリズムスイートに対応します。各Signature_Blocksには、Secure_Path内の各AS番号（つまり、Secure_Pathセグメント）の署名セグメントが含まれます。最も一般的なケースでは、BGPsec_PATH属性には単一のSignature_Blockのみが含まれます。ただし、古いアルゴリズムスイートから新しいアルゴリズムスイートへの移行を有効にするには（フラグ日なし）、2つのSignature_Blocks（古いアルゴリズムスイート用と新しいアルゴリズムスイート用）を含める必要があります。移行期間。 （アルゴリズム遷移の詳細については、セクション6.1を参照してください。）Signature_Blocksの形式については、セクション3.2で説明します。
A detailed description of the Secure_Path information in the BGPsec_PATH attribute is provided here. The specification for the Secure_Path field is provided in Figures 4 and 5.
ここでは、BGPsec_PATH属性のSecure_Path情報の詳細について説明します。 Secure_Pathフィールドの仕様を図4および5に示します。
+-----------------------------------------------+
| Secure_Path Length (2 octets) |
+-----------------------------------------------+
| One or more Secure_Path Segments (variable) |
+-----------------------------------------------+
Figure 4: Secure_Path Format
図4：Secure_Path形式
The Secure_Path Length contains the length (in octets) of the entire Secure_Path (including the 2 octets used to express this length field). As explained below, each Secure_Path Segment is 6 octets long. Note that this means the Secure_Path Length is two greater than six times the number of Secure_Path Segments (i.e., the number of AS numbers in the path).
Secure_Path Lengthには、Secure_Path全体の長さ（オクテット単位）が含まれます（この長さフィールドを表すために使用される2オクテットを含む）。以下で説明するように、各Secure_Pathセグメントは6オクテット長です。これは、Secure_Pathの長さがSecure_Pathセグメントの数の6倍（つまり、パス内のAS番号の数）の2倍であることを意味することに注意してください。
The Secure_Path contains one Secure_Path Segment (see Figure 5) for each AS in the path to the originating AS of the prefix specified in the UPDATE message. (Note: Repeated ASes are "compressed out" using the pCount field, as discussed below.)
Secure_Pathには、UPDATEメッセージで指定されたプレフィックスの発信元ASへのパス内のASごとに、1つのSecure_Pathセグメント（図5を参照）が含まれています。 （注：繰り返しASは、以下で説明するように、pCountフィールドを使用して「圧縮」されます。）
+------------------------------------------------------+
| pCount (1 octet) |
+------------------------------------------------------+
| Confed_Segment flag (1 bit) | Unassigned (7 bits) | (Flags)
+------------------------------------------------------+
| AS Number (4 octets) |
+------------------------------------------------------+
Figure 5: Secure_Path Segment Format
図5：Secure_Pathセグメントの形式
The AS Number (in Figure 5) is the AS number of the BGP speaker that added this Secure_Path Segment to the BGPsec_PATH attribute. (See Section 4 for more information on populating this field.)
AS番号（図5）は、このSecure_PathセグメントをBGPsec_PATH属性に追加したBGPスピーカーのAS番号です。 （このフィールドへの入力の詳細については、セクション4を参照してください。）
The pCount field contains the number of repetitions of the associated AS number that the signature covers. This field enables a BGPsec speaker to mimic the semantics of prepending multiple copies of their AS to the AS_PATH without requiring the speaker to generate multiple signatures. Note that Section 9.1.2.2 ("Breaking Ties (Phase 2)") in [RFC4271] mentions the "number of AS numbers" in the AS_PATH attribute that is used in the route selection process. This metric (number of AS numbers) is the same as the AS path length obtained in BGPsec by summing the pCount values in the BGPsec_PATH attribute. The pCount field is also useful in managing route servers (see Section 4.2), AS confederations (see Section 4.3), and AS Number migrations (see [RFC8206] for details).
pCountフィールドには、シグニチャがカバーする、関連付けられたAS番号の繰り返し数が含まれています。このフィールドにより、BGPsecスピーカーは、複数の署名を生成する必要なく、ASのASの複数のコピーをAS_PATHに付加するセマンティクスを模倣できます。 [RFC4271]のセクション9.1.2.2（「ブレイキングタイ（フェーズ2）」）は、ルート選択プロセスで使用されるAS_PATH属性の「AS番号の数」について言及していることに注意してください。このメトリック（AS番号の数）は、BGPsec_PATH属性のpCount値を合計することにより、BGPsecで取得されたASパス長と同じです。 pCountフィールドは、ルートサーバー（セクション4.2を参照）、AS連合（セクション4.3を参照）、AS番号の移行（詳細については[RFC8206]を参照）の管理にも役立ちます。
The leftmost (i.e., the most significant) bit of the Flags field in Figure 5 is the Confed_Segment flag. The Confed_Segment flag is set to 1 to indicate that the BGPsec speaker that constructed this Secure_Path Segment is sending the UPDATE message to a peer AS within the same AS confederation [RFC5065]. (That is, a sequence of consecutive Confed_Segment flags are set in a BGPsec UPDATE message whenever, in a non-BGPsec UPDATE message, an AS_PATH segment of type AS_CONFED_SEQUENCE occurs.) In all other cases, the Confed_Segment flag is set to 0.
図5のフラグフィールドの左端（つまり、最上位）ビットは、Confed_Segmentフラグです。 Confed_Segmentフラグは1に設定され、このSecure_Pathセグメントを構築したBGPsecスピーカーが、同じAS連合[RFC5065]内のピアASにUPDATEメッセージを送信していることを示します。 （つまり、非BGPsec UPDATEメッセージで、タイプAS_CONFED_SEQUENCEのAS_PATHセグメントが発生するたびに、連続するConfed_SegmentフラグのシーケンスがBGPsec UPDATEメッセージで設定されます。）他のすべての場合、Confed_Segmentフラグは0に設定されます。
The remaining 7 bits of the Flags field are unassigned. They MUST be set to 0 by the sender and ignored by the receiver. Note, however, that the signature is computed over all 8 bits of the Flags field.
Flagsフィールドの残りの7ビットは割り当てられていません。それらは送信者によって0に設定されなければならず、受信者によって無視されなければなりません。ただし、署名はFlagsフィールドの8ビットすべてにわたって計算されることに注意してください。
As stated earlier in Section 2.2, BGPsec peering requires that the peering ASes MUST each support 4-byte AS numbers. Currently assigned 2-byte AS numbers are converted into 4-byte AS numbers by setting the two high-order octets of the 4-octet field to 0 [RFC6793].
セクション2.2で前述したように、BGPsecピアリングでは、ピアリングASがそれぞれ4バイトのAS番号をサポートする必要があります。現在割り当てられている2バイトのAS番号は、4オクテットフィールドの2つの上位オクテットを0に設定することで4バイトのAS番号に変換されます[RFC6793]。
A detailed description of the Signature_Blocks in the BGPsec_PATH attribute is provided here using Figures 6 and 7.
BGPsec_PATH属性のSignature_Blocksの詳細な説明は、図6および7を使用してここで提供されます。
+---------------------------------------------+
| Signature_Block Length (2 octets) |
+---------------------------------------------+
| Algorithm Suite Identifier (1 octet) |
+---------------------------------------------+
| Sequence of Signature Segments (variable) |
+---------------------------------------------+
Figure 6: Signature_Block Format
図6：Signature_Blockの形式
The Signature_Block Length in Figure 6 is the total number of octets in the Signature_Block (including the 2 octets used to express this length field).
図6のSignature_Block Lengthは、Signature_Block内のオクテットの総数です（この長さフィールドを表すために使用される2オクテットを含む）。
The Algorithm Suite Identifier is a 1-octet identifier specifying the digest algorithm and digital signature algorithm used to produce the digital signature in each Signature Segment. An IANA registry of algorithm suite identifiers for use in BGPsec is specified in the BGPsec algorithms document [RFC8208].
Algorithm Suite Identifierは、各署名セグメントでデジタル署名を生成するために使用されるダイジェストアルゴリズムとデジタル署名アルゴリズムを指定する1オクテットの識別子です。 BGPsecで使用されるアルゴリズムスイート識別子のIANAレジストリは、BGPsecアルゴリズムドキュメント[RFC8208]で指定されています。
A Signature_Block in Figure 6 has exactly one Signature Segment (see Figure 7) for each Secure_Path Segment in the Secure_Path portion of the BGPsec_PATH attribute (that is, one Signature Segment for each distinct AS on the path for the prefix in the UPDATE message).
図6のSignature_Blockには、BGPsec_PATH属性のSecure_Path部分のSecure_Pathセグメントごとに1つの署名セグメント（図7を参照）があります（つまり、UPDATEメッセージのプレフィックスのパス上の異なるASごとに1つの署名セグメント）。
+---------------------------------------------+
| Subject Key Identifier (SKI) (20 octets) |
+---------------------------------------------+
| Signature Length (2 octets) |
+---------------------------------------------+
| Signature (variable) |
+---------------------------------------------+
Figure 7: Signature Segment Format
図7：署名セグメントの形式
The Subject Key Identifier (SKI) field in Figure 7 contains the value in the Subject Key Identifier extension of the RPKI router certificate [RFC6487] that is used to verify the signature (see Section 5 for details on the validity of BGPsec UPDATE messages). The SKI field has a fixed size of 20 octets. See Section 6.2 for considerations for the SKI size.
図7のサブジェクトキー識別子（SKI）フィールドには、署名の検証に使用されるRPKIルーター証明書[RFC6487]のサブジェクトキー識別子拡張の値が含まれています（BGPsec UPDATEメッセージの有効性の詳細については、セクション5を参照）。 SKIフィールドのサイズは20オクテットに固定されています。 SKIサイズの考慮事項については、セクション6.2を参照してください。
The Signature Length field contains the size (in octets) of the value in the Signature field of the Signature Segment.
署名の長さフィールドには、署名セグメントの署名フィールドの値のサイズ（オクテット単位）が含まれています。
The Signature field in Figure 7 contains a digital signature that protects the prefix and the BGPsec_PATH attribute (see Sections 4 and 5 for details on signature generation and validation, respectively).
図7の署名フィールドには、プレフィックスとBGPsec_PATH属性を保護するデジタル署名が含まれています（署名の生成と検証の詳細については、それぞれセクション4と5を参照してください）。
Section 4.1 provides general guidance on the creation of BGPsec UPDATE messages -- that is, UPDATE messages containing the BGPsec_PATH attribute.
セクション4.1では、BGPsec UPDATEメッセージ、つまりBGPsec_PATH属性を含むUPDATEメッセージの作成に関する一般的なガイダンスを提供します。
Section 4.2 specifies how a BGPsec speaker generates the BGPsec_PATH attribute to include in a BGPsec UPDATE message.
セクション4.2では、BGPsecスピーカーがBGPsec_PATH属性を生成してBGPsec UPDATEメッセージに含める方法を指定します。
Section 4.3 contains special processing instructions for members of an AS confederation [RFC5065]. A BGPsec speaker that is not a member of such a confederation MUST NOT set the Confed_Segment flag in its Secure_Path Segment (i.e., leave the Confed_Segment flag at the default value of 0) in all BGPsec UPDATE messages it sends.
セクション4.3には、ASコンフェデレーション[RFC5065]のメンバー向けの特別な処理手順が含まれています。そのようなコンフェデレーションのメンバーではないBGPsecスピーカーは、送信するすべてのBGPsec UPDATEメッセージのSecure_PathセグメントにConfed_Segmentフラグを設定してはなりません（つまり、Confed_Segmentフラグをデフォルト値の0のままにします）。
Section 4.4 contains instructions for reconstructing the AS_PATH attribute in cases where a BGPsec speaker receives an UPDATE message with a BGPsec_PATH attribute and wishes to propagate the UPDATE message to a peer who does not support BGPsec.
セクション4.4には、BGPsecスピーカーがBGPsec_PATH属性を持つUPDATEメッセージを受信し、BGPsecをサポートしていないピアにUPDATEメッセージを伝播したい場合に、AS_PATH属性を再構築する手順が含まれています。
The information protected by the signature on a BGPsec UPDATE message includes the AS number of the peer to whom the UPDATE message is being sent. Therefore, if a BGPsec speaker wishes to send a BGPsec UPDATE message to multiple BGP peers, it MUST generate a separate BGPsec UPDATE message for each unique peer AS to whom the UPDATE message is sent.
BGPsec UPDATEメッセージの署名によって保護される情報には、UPDATEメッセージの送信先のピアのAS番号が含まれます。したがって、BGPsecスピーカーが複数のBGPピアにBGPsec UPDATEメッセージを送信したい場合、UPDATEメッセージが送信される一意のピアASごとに個別のBGPsec UPDATEメッセージを生成する必要があります。
A BGPsec UPDATE message MUST advertise a route to only a single prefix. This is because a BGPsec speaker receiving an UPDATE message with multiple prefixes would be unable to construct a valid BGPsec UPDATE message (i.e., valid path signatures) containing a subset of the prefixes in the received update. If a BGPsec speaker wishes to advertise routes to multiple prefixes, then it MUST generate a separate BGPsec UPDATE message for each prefix. Additionally, a BGPsec UPDATE message MUST use the MP_REACH_NLRI attribute [RFC4760] to encode the prefix.
BGPsec UPDATEメッセージは、ルートを単一のプレフィックスにのみアドバタイズする必要があります。これは、複数のプレフィックスを含むUPDATEメッセージを受信するBGPsecスピーカーが、受信した更新のプレフィックスのサブセットを含む有効なBGPsec UPDATEメッセージ（つまり、有効なパス署名）を構築できないためです。 BGPsecスピーカーが複数のプレフィックスへのルートをアドバタイズする場合は、プレフィックスごとに個別のBGPsec UPDATEメッセージを生成する必要があります。さらに、BGPsec UPDATEメッセージはMP_REACH_NLRI属性[RFC4760]を使用してプレフィックスをエンコードする必要があります。
The BGPsec_PATH attribute and the AS_PATH attribute are mutually exclusive. That is, any UPDATE message containing the BGPsec_PATH attribute MUST NOT contain the AS_PATH attribute. The information that would be contained in the AS_PATH attribute is instead conveyed in the Secure_Path portion of the BGPsec_PATH attribute.
BGPsec_PATH属性とAS_PATH属性は相互に排他的です。つまり、BGPsec_PATH属性を含むUPDATEメッセージには、AS_PATH属性を含めてはなりません（MUST NOT）。 AS_PATH属性に含まれる情報は、代わりにBGPsec_PATH属性のSecure_Path部分で伝達されます。
In order to create or add a new signature to a BGPsec UPDATE message with a given algorithm suite, the BGPsec speaker MUST possess a private key suitable for generating signatures for this algorithm suite. Additionally, this private key must correspond to the public key in a valid RPKI end entity certificate whose AS number resource extension includes the BGPsec speaker's AS number [RFC8209]. Note also that new signatures are only added to a BGPsec UPDATE message when a BGPsec speaker is generating an UPDATE message to send to an external peer (i.e., when the AS number of the peer is not equal to the BGPsec speaker's own AS number).
特定のアルゴリズムスイートを使用してBGPsec UPDATEメッセージに新しい署名を作成または追加するには、BGPsecスピーカーが、このアルゴリズムスイートの署名を生成するのに適した秘密鍵を所有している必要があります。さらに、この秘密鍵は、AS番号リソース拡張にBGPsecスピーカーのAS番号が含まれる有効なRPKIエンドエンティティ証明書の公開鍵に対応している必要があります[RFC8209]。また、新しい署名は、BGPsecスピーカーが外部ピアに送信するUPDATEメッセージを生成している場合（つまり、ピアのAS番号がBGPsecスピーカー自身のAS番号と等しくない場合）にのみBGPsec UPDATEメッセージに追加されることに注意してください。
The RPKI enables the legitimate holder of IP address prefix(es) to issue a signed object, called a Route Origin Authorization (ROA), that authorizes a given AS to originate routes to a given set of prefixes (see RFC 6482 [RFC6482]). It is expected that most Relying Parties (RPs) will utilize BGPsec in tandem with origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]). Therefore, it is RECOMMENDED that a BGPsec speaker only originate a BGPsec UPDATE message advertising a route for a given prefix if there exists a valid ROA authorizing the BGPsec speaker's AS to originate routes to this prefix.
RPKIを使用すると、IPアドレスプレフィックスの正当な所有者が、特定のASから特定のプレフィックスのセットへのルートを発信することを承認する、Route Origin Authorization（ROA）と呼ばれる署名付きオブジェクトを発行できます（RFC 6482 [RFC6482]を参照） 。ほとんどの依拠当事者（RP）は、起点検証と並行してBGPsecを利用することが期待されています（RFC 6483 [RFC6483]およびRFC 6811 [RFC6811]を参照）。したがって、BGPsecスピーカーのASがこのプレフィックスへのルートを発信することを承認する有効なROAが存在する場合、BGPsecスピーカーは、特定のプレフィックスのルートをアドバタイズするBGPsec UPDATEメッセージのみを発信することが推奨されます。
If a BGPsec router has received only a non-BGPsec UPDATE message containing the AS_PATH attribute (instead of the BGPsec_PATH attribute) from a peer for a given prefix, then it MUST NOT attach a BGPsec_PATH attribute when it propagates the UPDATE message. (Note that a BGPsec router may also receive a non-BGPsec UPDATE message from an internal peer without the AS_PATH attribute, i.e., with just the Network Layer Reachability Information (NLRI) in it. In that case, the prefix is originating from that AS, and if it is selected for advertisement, the BGPsec speaker SHOULD attach a BGPsec_PATH attribute and send a signed route (for that prefix) to its external BGPsec-speaking peers.)
BGPsecルーターが、特定のプレフィックスのピアから（BGPsec_PATH属性ではなく）AS_PATH属性を含む非BGPsec UPDATEメッセージのみを受信した場合、UPDATEメッセージを伝達するときにBGPsec_PATH属性をアタッチしてはなりません（MUST NOT）。 （BGPsecルーターは、AS_PATH属性のない、つまりネットワーク層到達可能性情報（NLRI）のみを含む内部ピアから非BGPsec UPDATEメッセージを受信することもあります。その場合、プレフィックスはそのASから発信されます。 、およびそれがアドバタイズのために選択されている場合、BGPsecスピーカーはBGPsec_PATH属性を付加し（そのプレフィックスの）署名されたルートを外部のBGPsecを話すピアに送信する必要があります。
Conversely, if a BGPsec router has received a BGPsec UPDATE message (with the BGPsec_PATH attribute) from a peer for a given prefix and it chooses to propagate that peer's route for the prefix, then it SHOULD propagate the route as a BGPsec UPDATE message containing the BGPsec_PATH attribute.
逆に、BGPsecルーターが特定のプレフィックスのピアからBGPsec UPDATEメッセージ（BGPsec_PATH属性を含む）を受信し、そのピアのルートをプレフィックスに伝搬することを選択した場合、ルートを含むBGPsec UPDATEメッセージとしてルートを伝搬する必要があります（SHOULD）。 BGPsec_PATH属性。
Note that removing BGPsec signatures (i.e., propagating a route advertisement without the BGPsec_PATH attribute) has significant security ramifications. (See Section 8 for a discussion of the security ramifications of removing BGPsec signatures.) Therefore, when a route advertisement is received via a BGPsec UPDATE message, propagating the route advertisement without the BGPsec_PATH attribute is NOT RECOMMENDED, unless the message is sent to a peer that did not advertise the capability to receive BGPsec UPDATE messages (see Section 4.4).
BGPsecシグネチャを削除する（つまり、BGPsec_PATH属性なしでルートアドバタイズを伝播する）と、セキュリティに重大な影響が生じることに注意してください。 （BGPsecシグネチャを削除することによるセキュリティ上の影響については、セクション8を参照してください。）したがって、BGPsec UPDATEメッセージを介してルートアドバタイズを受信した場合、メッセージがに送信されない限り、BGPsec_PATH属性なしでルートアドバタイズを伝播することは推奨されません。 BGPsec UPDATEメッセージを受信する機能を通知しなかったピア（セクション4.4を参照）。
Furthermore, note that when a BGPsec speaker propagates a route advertisement with the BGPsec_PATH attribute, it is not attesting to the validation state of the UPDATE message it received. (See Section 8 for more discussion of the security semantics of BGPsec signatures.)
さらに、BGPsecスピーカーがBGPsec_PATH属性を使用してルートアドバタイズを伝達する場合、受信したUPDATEメッセージの検証状態を証明しないことに注意してください。 （BGPsecシグネチャのセキュリティセマンティクスの詳細については、セクション8を参照してください。）
If the BGPsec speaker is producing an UPDATE message that would, in the absence of BGPsec, contain an AS_SET (e.g., the BGPsec speaker is performing proxy aggregation), then the BGPsec speaker MUST NOT include the BGPsec_PATH attribute. In such a case, the BGPsec speaker MUST remove any existing BGPsec_PATH in the received advertisement(s) for this prefix and produce a traditional (non-BGPsec) UPDATE message. It should be noted that BCP 172 [RFC6472] recommends against the use of AS_SET and AS_CONFED_SET in the AS_PATH of BGP UPDATE messages.
BGPsecスピーカーが、BGPsecがない場合にAS_SETを含むUPDATEメッセージを生成する場合（たとえば、BGPsecスピーカーがプロキシ集約を実行している場合）、BGPsecスピーカーはBGPsec_PATH属性を含めてはなりません（MUST NOT）。このような場合、BGPsecスピーカーは、このプレフィックスの受信したアドバタイズメントの既存のBGPsec_PATHを削除して、従来の（非BGPsec）UPDATEメッセージを生成する必要があります。 BCP 172 [RFC6472]は、BGP UPDATEメッセージのAS_PATHでAS_SETおよびAS_CONFED_SETを使用しないことを推奨していることに注意してください。
The case where the BGPsec speaker sends a BGPsec UPDATE message to an iBGP (internal BGP) peer is quite simple. When originating a new route advertisement and sending it to a BGPsec-capable iBGP peer, the BGPsec speaker omits the BGPsec_PATH attribute. When originating a new route advertisement and sending it to a non-BGPsec iBGP peer, the BGPsec speaker includes an empty AS_PATH attribute in the UPDATE message. (An empty AS_PATH attribute is one whose length field contains the value 0 [RFC4271].) When a BGPsec speaker chooses to forward a BGPsec UPDATE message to an iBGP peer, the BGPsec_PATH attribute SHOULD NOT be removed, unless the peer doesn't support BGPsec. In the case when an iBGP peer doesn't support BGPsec, then a BGP UPDATE message with AS_PATH is reconstructed from the BGPsec UPDATE message and then forwarded (see Section 4.4). In particular, when forwarding to a BGPsec-capable iBGP (or eBGP) peer, the BGPsec_PATH attribute SHOULD NOT be removed even in the case where the BGPsec UPDATE message has not been successfully validated. (See Section 5 for more information on validation and Section 8 for the security ramifications of removing BGPsec signatures.) All BGPsec UPDATE messages MUST conform to BGP's maximum message size. If the resulting message exceeds the maximum message size, then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be followed.
BGPsecスピーカーがBGPsec UPDATEメッセージをiBGP（内部BGP）ピアに送信するケースは非常に簡単です。新しいルートアドバタイズメントを発信してBGPsec対応のiBGPピアに送信する場合、BGPsecスピーカーはBGPsec_PATH属性を省略します。新しいルートアドバタイズメントを発信し、それを非BGPsec iBGPピアに送信すると、BGPsecスピーカーはUPDATEメッセージに空のAS_PATH属性を含めます。 （空のAS_PATH属性は、長さフィールドに値0 [RFC4271]が含まれるものです。）BGPsecスピーカーがBGPsec UPDATEメッセージをiBGPピアに転送することを選択した場合、ピアがサポートしていない場合を除き、BGPsec_PATH属性は削除しないでください（SHOULD NOT）。 BGPsec。 iBGPピアがBGPsecをサポートしていない場合は、AS_PATHを含むBGP UPDATEメッセージがBGPsec UPDATEメッセージから再構築されて転送されます（セクション4.4を参照）。特に、BGPsec対応のiBGP（またはeBGP）ピアに転送する場合、BGPsec UPDATEメッセージが正常に検証されなかった場合でも、BGPsec_PATH属性を削除してはなりません（SHOULD NOT）。 （検証の詳細についてはセクション5を、BGPsec署名を削除することによるセキュリティ上の影響についてはセクション8を参照してください。）すべてのBGPsec UPDATEメッセージは、BGPの最大メッセージサイズに準拠する必要があります。結果のメッセージが最大メッセージサイズを超える場合は、RFC 4271 [RFC4271]のセクション9.2のガイドラインに従う必要があります。
When a BGPsec speaker receives a BGPsec UPDATE message containing a BGPsec_PATH attribute (with one or more signatures) from an (internal or external) peer, it may choose to propagate the route advertisement by sending it to its other (internal or external) peers. When sending the route advertisement to an internal BGPsec-speaking peer, the BGPsec_PATH attribute SHALL NOT be modified. When sending the route advertisement to an external BGPsec-speaking peer, the following procedures are used to form or update the BGPsec_PATH attribute.
BGPsecスピーカーは、（内部または外部）ピアからBGPsec_PATH属性（1つ以上のシグネチャを含む）を含むBGPsec UPDATEメッセージを受信すると、他の（内部または外部）ピアに送信することにより、ルートアドバタイズを伝播することを選択できます。ルートアドバタイズメントを内部BGPsec-speakingピアに送信するとき、BGPsec_PATH属性は変更されるべきではありません（SHALL NOT）。ルートアドバタイズメントを外部BGPsecを話すピアに送信する場合、次の手順を使用してBGPsec_PATH属性を形成または更新します。
To generate the BGPsec_PATH attribute on the outgoing UPDATE message, the BGPsec speaker first generates a new Secure_Path Segment. Note that if the BGPsec speaker is not the origin AS and there is an existing BGPsec_PATH attribute, then the BGPsec speaker prepends its new Secure_Path Segment (places in first position) onto the existing Secure_Path.
発信UPDATEメッセージのBGPsec_PATH属性を生成するために、BGPsecスピーカーは最初に新しいSecure_Pathセグメントを生成します。 BGPsecスピーカーが元のASではなく、既存のBGPsec_PATH属性がある場合、BGPsecスピーカーは新しいSecure_Pathセグメントを（最初の位置に配置して）既存のSecure_Pathに追加します。
The AS number in this Secure_Path Segment MUST match the AS number in the Subject field of the RPKI router certificate that will be used to verify the digital signature constructed by this BGPsec speaker (see Section 3.1.1 in [RFC8209] and RFC 6487 [RFC6487]).
このSecure_PathセグメントのAS番号は、このBGPsecスピーカーによって構築されたデジタル署名の検証に使用されるRPKIルーター証明書の[Subject]フィールドのAS番号と一致する必要があります（[RFC8209]のセクション3.1.1およびRFC 6487 [RFC6487 ]）。
The pCount field of the Secure_Path Segment is typically set to the value 1. However, a BGPsec speaker may set the pCount field to a value greater than 1. Setting the pCount field to a value greater than 1 has the same semantics as repeating an AS number multiple times in the AS_PATH of a non-BGPsec UPDATE message (e.g., for traffic engineering purposes).
Secure_PathセグメントのpCountフィールドは、通常、値1に設定されます。ただし、BGPsecスピーカーは、pCountフィールドを1より大きい値に設定する場合があります。pCountフィールドを1より大きい値に設定すると、ASを繰り返すのと同じ意味になります。 BGPsec以外のUPDATEメッセージのAS_PATHで複数回（たとえば、トラフィックエンジニアリングの目的で）。
To prevent unnecessary processing load in the validation of BGPsec signatures, a BGPsec speaker SHOULD NOT produce multiple consecutive Secure_Path Segments with the same AS number. This means that to achieve the semantics of prepending the same AS number k times, a BGPsec speaker SHOULD produce a single Secure_Path Segment -- with a pCount of k -- and a single corresponding Signature Segment.
BGPsec署名の検証における不要な処理負荷を防ぐために、BGPsecスピーカーは、同じAS番号を持つ複数の連続するSecure_Pathセグメントを生成してはなりません（SHOULD NOT）。つまり、同じAS番号をk回付加するセマンティクスを実現するために、BGPsecスピーカーは、pCountがkの単一のSecure_Pathセグメントと、対応する単一の署名セグメントを生成する必要があります（SHOULD）。
A route server that participates in the BGP control plane but does not act as a transit AS in the data plane may choose to set pCount to 0. This option enables the route server to participate in BGPsec and obtain the associated security guarantees without increasing the length of the AS path. (Note that BGPsec speakers compute the length of the AS path by summing the pCount values in the BGPsec_PATH attribute; see Section 5.) However, when a route server sets the pCount value to 0, it still inserts its AS number into the Secure_Path Segment, as this information is needed to validate the signature added by the route server. See [RFC8206] for a discussion of setting pCount to 0 to facilitate AS Number migration. Also, see Section 4.3 for the use of pCount=0 in the context of an AS confederation. See Section 7.2 for operational guidance for configuring a BGPsec router for setting pCount=0 and/or accepting pCount=0 from a peer.
BGPコントロールプレーンに参加するが、データプレーンで中継ASとして機能しないルートサーバーは、pCountを0に設定することを選択できます。このオプションにより、ルートサーバーはBGPsecに参加し、長さを増やすことなく関連するセキュリティ保証を取得できます。 ASパスの。 （BGPsecスピーカーは、BGPsec_PATH属性のpCount値を合計することでASパスの長さを計算することに注意してください。ただし、ルートサーバーがpCount値を0に設定しても、そのAS番号はSecure_Pathセグメントに挿入されますこの情報は、ルートサーバーによって追加された署名を検証するために必要です。 AS番号の移行を容易にするためにpCountを0に設定する方法については、[RFC8206]を参照してください。また、AS連合のコンテキストでのpCount = 0の使用については、セクション4.3を参照してください。 pCount = 0を設定したり、ピアからpCount = 0を受け入れたりするためのBGPsecルーターの構成に関する操作ガイダンスについては、セクション7.2を参照してください。
Next, the BGPsec speaker generates one or two Signature_Blocks. Typically, a BGPsec speaker will use only a single algorithm suite and thus create only a single Signature_Block in the BGPsec_PATH attribute. However, to ensure backwards compatibility during a period of transition from a 'current' algorithm suite to a 'new' algorithm suite, it will be necessary to originate UPDATE messages that contain a Signature_Block for both the 'current' and the 'new' algorithm suites (see Section 6.1).
次に、BGPsecスピーカーは1つまたは2つのSignature_Blocksを生成します。通常、BGPsecスピーカーは単一のアルゴリズムスイートのみを使用するため、BGPsec_PATH属性に単一のSignature_Blockのみを作成します。ただし、「現在」のアルゴリズムスイートから「新しい」アルゴリズムスイートへの移行期間中に下位互換性を確保するには、「現在」と「新しい」アルゴリズムの両方のSignature_Blockを含むUPDATEメッセージを生成する必要があります。スイート（セクション6.1を参照）。
If the received BGPsec UPDATE message contains two Signature_Blocks and the BGPsec speaker supports both of the corresponding algorithm suites, then the new UPDATE message generated by the BGPsec speaker MUST include both of the Signature_Blocks. If the received BGPsec UPDATE message contains two Signature_Blocks and the BGPsec speaker only supports one of the two corresponding algorithm suites, then the BGPsec speaker MUST remove the Signature_Block corresponding to the algorithm suite that it does not understand. If the BGPsec speaker does not support the algorithm suites in any of the Signature_Blocks contained in the received UPDATE message, then the BGPsec speaker MUST NOT propagate the route advertisement with the BGPsec_PATH attribute. (That is, if it chooses to propagate this route advertisement at all, it MUST do so as an unsigned BGP UPDATE message. See Section 4.4 for more information on converting to an unsigned BGP UPDATE message.)
受信したBGPsec UPDATEメッセージに2つのSignature_Blockが含まれていて、BGPsecスピーカーが対応するアルゴリズムスイートの両方をサポートしている場合、BGPsecスピーカーによって生成される新しいUPDATEメッセージには両方のSignature_Blockが含まれている必要があります。受信したBGPsec UPDATEメッセージに2つのSignature_Blocksが含まれ、BGPsecスピーカーが対応する2つのアルゴリズムスイートの1つのみをサポートする場合、BGPsecスピーカーは、理解できないアルゴリズムスイートに対応するSignature_Blockを削除する必要があります。 BGPsecスピーカーが、受信したUPDATEメッセージに含まれるいずれかのSignature_Blocksのアルゴリズムスイートをサポートしていない場合、BGPsecスピーカーは、BGPsec_PATH属性を使用してルートアドバタイズを伝播してはなりません（MUST NOT）。 （つまり、このルートアドバタイズを伝播することを選択する場合は、署名されていないBGP UPDATEメッセージとして伝播する必要があります。署名されていないBGP UPDATEメッセージへの変換の詳細については、セクション4.4を参照してください。）
Note that in the case where the BGPsec_PATH has two Signature_Blocks (corresponding to different algorithm suites), the validation algorithm (see Section 5.2) deems a BGPsec UPDATE message to be 'Valid' if there is at least one supported algorithm suite (and corresponding Signature_Block) that is deemed 'Valid'. This means that a 'Valid' BGPsec UPDATE message may contain a Signature_Block that is not deemed 'Valid' (e.g., contains signatures that BGPsec does not successfully verify). Nonetheless, such Signature_Blocks MUST NOT be removed. (See Section 8 for a discussion of the security ramifications of this design choice.) For each Signature_Block corresponding to an algorithm suite that the BGPsec speaker does support, the BGPsec speaker MUST add a new Signature Segment to the Signature_Block. This Signature Segment is prepended to the list of Signature Segments (placed in the first position) so that the list of Signature Segments appears in the same order as the corresponding Secure_Path Segments. The BGPsec speaker populates the fields of this new Signature Segment as follows.
BGPsec_PATHに2つのSignature_Blocks（異なるアルゴリズムスイートに対応）がある場合、検証アルゴリズム（セクション5.2を参照）は、サポートされるアルゴリズムスイート（および対応するSignature_Block）が少なくとも1つある場合、BGPsec UPDATEメッセージを「有効」と見なします。 ）「有効」と見なされます。これは、「有効な」BGPsec UPDATEメッセージに、「有効」とは見なされないSignature_Blockが含まれている可能性があることを意味します（たとえば、BGPsecが正常に検証できない署名が含まれています）。それにもかかわらず、そのようなSignature_Blocksは削除してはなりません（MUST NOT）。 （この設計選択のセキュリティの影響については、セクション8を参照してください。）BGPsecスピーカーがサポートするアルゴリズムスイートに対応する各Signature_Blockについて、BGPsecスピーカーは新しい署名セグメントをSignature_Blockに追加する必要があります。このシグネチャセグメントは、シグネチャセグメントのリスト（最初の位置に配置）の先頭に追加されるため、シグネチャセグメントのリストは、対応するSecure_Pathセグメントと同じ順序で表示されます。 BGPsecスピーカーは、この新しい署名セグメントのフィールドに次のように入力します。
The Subject Key Identifier field in the new segment is populated with the identifier contained in the Subject Key Identifier extension of the RPKI router certificate corresponding to the BGPsec speaker [RFC8209]. This Subject Key Identifier will be used by recipients of the route advertisement to identify the proper certificate to use in verifying the signature.
新しいセグメントのSubject Key Identifierフィールドには、BGPsecスピーカー[RFC8209]に対応するRPKIルーター証明書のSubject Key Identifier拡張に含まれる識別子が入力されます。このサブジェクトキー識別子は、ルートアドバタイズメントの受信者が署名の検証に使用する適切な証明書を識別するために使用されます。
The Signature field in the new segment contains a digital signature that binds the prefix and BGPsec_PATH attribute to the RPKI router certificate corresponding to the BGPsec speaker. The digital signature is computed as follows:
新しいセグメントの署名フィールドには、プレフィックスとBGPsec_PATH属性をBGPsecスピーカーに対応するRPKIルーター証明書にバインドするデジタル署名が含まれています。デジタル署名は次のように計算されます。
o For clarity, let us number the Secure_Path and corresponding Signature Segments from 1 to N, as follows. Let Secure_Path Segment 1 and Signature Segment 1 be the segments produced by the origin AS. Let Secure_Path Segment 2 and Signature Segment 2 be the segments added by the next AS after the origin. Continue this method of numbering, and ultimately let Secure_Path Segment N and Signature Segment N be those that are being added by the current AS. The current AS (Nth AS) is signing and forwarding the UPDATE message to the next AS (i.e., the (N+1)th AS) in the chain of ASes that form the AS path.
o わかりやすくするために、Secure_Pathおよび対応する署名セグメントに1からNまでの番号を付けます。 Secure_Pathセグメント1と署名セグメント1を、オリジンASによって生成されたセグメントとします。 Secure_Pathセグメント2と署名セグメント2を、オリジンの後に次のASによって追加されたセグメントとします。この番号付けの方法を続け、最終的に、Secure_PathセグメントNと署名セグメントNを現在のASによって追加されているものにします。現在のAS（N番目のAS）は、UPDATEメッセージに署名し、ASパスを形成するASのチェーン内の次のAS（つまり、（N + 1）番目のAS）に転送します。
o In order to construct the digital signature for Signature Segment N (the Signature Segment being produced by the current AS), first construct the sequence of octets to be hashed as shown in Figure 8. This sequence of octets includes all the data that the Nth AS attests to by adding its digital signature in the UPDATE message that is being forwarded to a BGPsec speaker in the (N+1)th AS. (For the design rationale for choosing the specific structure in Figure 8, please see [Borchert].)
o 署名セグメントN（現在のASによって生成されている署名セグメント）のデジタル署名を作成するには、図8に示すように、ハッシュするオクテットのシーケンスを最初に作成します。このオクテットのシーケンスには、N番目のAS （N + 1）番目のASのBGPsecスピーカーに転送されているUPDATEメッセージにデジタル署名を追加することによって証明します。 （図8の特定の構造を選択するための設計根拠については、[Borchert]を参照してください。）
+------------------------------------+
| Target AS Number |
+------------------------------------+----\
| Signature Segment : N-1 | \
+------------------------------------+ |
| Secure_Path Segment : N | |
+------------------------------------+ \
... > Data from
+------------------------------------+ / N Segments
| Signature Segment : 1 | |
+------------------------------------+ |
| Secure_Path Segment : 2 | |
+------------------------------------+ /
| Secure_Path Segment : 1 | /
+------------------------------------+---/
| Algorithm Suite Identifier |
+------------------------------------+
| AFI |
+------------------------------------+
| SAFI |
+------------------------------------+
| NLRI |
+------------------------------------+
Figure 8: Sequence of Octets to Be Hashed
図8：ハッシュされるオクテットのシーケンス
The elements in this sequence (Figure 8) MUST be ordered exactly as shown. The 'Target AS Number' is the AS to whom the BGPsec speaker intends to send the UPDATE message. (Note that the 'Target AS Number' is the AS number announced by the peer in the OPEN message of the BGP session within which the UPDATE message is sent.) The Secure_Path and Signature Segments (1 through N-1) are obtained from the BGPsec_PATH attribute. Finally, the Address Family Identifier (AFI), Subsequent Address Family Identifier (SAFI), and NLRI fields are obtained from the MP_REACH_NLRI attribute [RFC4760]. Additionally, in the Prefix field within the NLRI field (see Section 5 in RFC 4760 [RFC4760]), all of the trailing bits MUST be set to 0 when constructing this sequence.
このシーケンスの要素（図8）は、示されているとおりに順序付けする必要があります。 「ターゲットAS番号」は、BGPsecスピーカーがUPDATEメッセージを送信する予定のASです。 （「ターゲットAS番号」は、UPDATEメッセージが送信されるBGPセッションのOPENメッセージでピアがアナウンスしたAS番号であることに注意してください。）Secure_Pathおよび署名セグメント（1〜N-1）は、 BGPsec_PATH属性。最後に、Address Family Identifier（AFI）、Subsequent Address Family Identifier（SAFI）、およびNLRIフィールドは、MP_REACH_NLRI属性[RFC4760]から取得されます。さらに、NLRIフィールド内のプレフィックスフィールド（RFC 4760 [RFC4760]のセクション5を参照）では、このシーケンスを構築するときに、すべての後続ビットを0に設定する必要があります。
o Apply to this octet sequence (in Figure 8) the digest algorithm (for the algorithm suite of this Signature_Block) to obtain a digest value.
o このオクテットシーケンス（図8）にダイジェストアルゴリズム（このSignature_Blockのアルゴリズムスイート用）を適用して、ダイジェスト値を取得します。
o Apply to this digest value the signature algorithm (for the algorithm suite of this Signature_Block) to obtain the digital signature. Then populate the Signature field (in Figure 7) with this digital signature.
o このダイジェスト値に署名アルゴリズム（このSignature_Blockのアルゴリズムスイート用）を適用して、デジタル署名を取得します。次に、署名フィールド（図7）にこのデジタル署名を入力します。
The Signature Length field (in Figure 7) is populated with the length (in octets) of the value in the Signature field.
[署名の長さ]フィールド（図7）には、[署名]フィールドの値の長さ（オクテット）が入力されます。
Members of AS confederations [RFC5065] MUST additionally follow the instructions in this section for processing BGPsec UPDATE messages.
ASコンフェデレーション[RFC5065]のメンバーは、BGPsec UPDATEメッセージを処理するために、このセクションの指示に追加に従う必要があります。
When a BGPsec speaker in an AS confederation receives a BGPsec UPDATE message from a peer that is external to the confederation and chooses to propagate the UPDATE message within the confederation, it first adds a signature signed to its own Member-AS (i.e., the 'Target AS Number' is the BGPsec speaker's Member-AS Number). In this internally modified UPDATE message, the newly added Secure_Path Segment contains the public AS number (i.e., Confederation Identifier), the segment's pCount value is set to 0, and Confed_Segment flag is set to 1. Setting pCount=0 in this case helps ensure that the AS path length is not unnecessarily incremented. The newly added signature is generated using a private key corresponding to the public AS number of the confederation. The BGPsec speaker propagates the modified UPDATE message to its peers within the confederation.
AS連合のBGPsecスピーカーは、連合の外部にあるピアからBGPsec UPDATEメッセージを受信し、連合内でUPDATEメッセージを伝播することを選択すると、まず独自のメンバーASに署名された署名（つまり、「ターゲットAS番号は、BGPsecスピーカーのメンバーAS番号です）。この内部的に変更されたUPDATEメッセージでは、新しく追加されたSecure_PathセグメントにパブリックAS番号（つまり、コンフェデレーションID）が含まれ、セグメントのpCount値が0に設定され、Confed_Segmentフラグが1に設定されます。 ASパス長が不必要に増加しないこと。新しく追加された署名は、連合のパブリックAS番号に対応する秘密鍵を使用して生成されます。 BGPsecスピーカーは、変更されたUPDATEメッセージを連合内のピアに伝播します。
Any BGPsec_PATH modifications mentioned below in the context of propagation of the UPDATE message within the confederation are in addition to the modification described above (i.e., with pCount=0).
コンフェデレーション内でのUPDATEメッセージの伝播のコンテキストで以下に説明するBGPsec_PATHの変更は、上記の変更に追加されます（つまり、pCount = 0を使用）。
When a BGPsec speaker sends a BGPsec UPDATE message to a peer that belongs within its own Member-AS, the confederation member SHALL NOT modify the BGPsec_PATH attribute. When a BGPsec speaker sends a BGPsec UPDATE message to a peer that is within the same confederation but in a different Member-AS, the BGPsec speaker puts its Member-AS Number in the AS Number field of the Secure_Path Segment that it adds to the BGPsec UPDATE message. Additionally, in this case, the Member-AS that generates the Secure_Path Segment sets the Confed_Segment flag to 1. Further, the signature is generated with a private key corresponding to the BGPsec speaker's Member-AS Number. (Note: In this document, intra-Member-AS peering is regarded as iBGP, and inter-Member-AS peering is regarded as eBGP. The latter is also known as confederation-eBGP.)
BGPsecスピーカーが自身のMember-AS内に属するピアにBGPsec UPDATEメッセージを送信する場合、コンフェデレーションメンバーはBGPsec_PATH属性を変更してはなりません（SHALL NOT）。 BGPsecスピーカーが、同じコンフェデレーション内にあるが別のMember-ASにあるピアにBGPsec UPDATEメッセージを送信すると、BGPsecスピーカーは、BGPsecに追加するSecure_PathセグメントのAS番号フィールドにそのMember-AS番号を入れます。 UPDATEメッセージ。さらに、この場合、Secure_Pathセグメントを生成するMember-ASはConfed_Segmentフラグを1に設定します。さらに、署名は、BGPsecスピーカーのMember-AS番号に対応する秘密鍵で生成されます。 （注：このドキュメントでは、メンバーAS内ピアリングはiBGPと見なされ、メンバーAS間ピアリングはeBGPと見なされます。後者はコンフェデレーションeBGPとも呼ばれます。）
Within a confederation, the verification of BGPsec signatures added by other members of the confederation is optional. Note that if a confederation chooses not to verify digital signatures within the confederation, then BGPsec is not able to provide any assurances about the integrity of the Member-AS Numbers placed in Secure_Path Segments where the Confed_Segment flag is set to 1.
コンフェデレーション内では、コンフェデレーションの他のメンバーによって追加されたBGPsec署名の検証はオプションです。コンフェデレーションがコンフェデレーション内のデジタル署名を検証しないことを選択した場合、BGPsecは、Confed_Segmentフラグが1に設定されているSecure_Pathセグメントに配置されたMember-AS番号の整合性に関する保証を提供できないことに注意してください。
When a confederation member receives a BGPsec UPDATE message from a peer within the confederation and propagates it to a peer outside the confederation, it needs to remove all of the Secure_Path Segments added by confederation members as well as the corresponding Signature Segments. To do this, the confederation member propagating the route outside the confederation does the following:
コンフェデレーションメンバーは、コンフェデレーション内のピアからBGPsec UPDATEメッセージを受信し、コンフェデレーション外のピアに伝達する場合、コンフェデレーションメンバーによって追加されたすべてのSecure_Pathセグメントと、対応する署名セグメントを削除する必要があります。これを行うには、コンフェデレーションメンバーがコンフェデレーションの外部にルートを伝播することにより、次のことが行われます。
o First, starting with the most recently added Secure_Path Segment, remove all of the consecutive Secure_Path Segments that have the Confed_Segment flag set to 1. Stop this process once a Secure_Path Segment that has its Confed_Segment flag set to 0 is reached. Keep a count of the number of segments removed in this fashion.
o 最初に、最後に追加されたSecure_Pathセグメントから始めて、Confed_Segmentフラグが1に設定されているすべての連続するSecure_Pathセグメントを削除します。この方法で削除されたセグメントの数をカウントします。
o Second, starting with the most recently added Signature Segment, remove a number of Signature Segments equal to the number of Secure_Path Segments removed in the previous step. (That is, remove the K most recently added Signature Segments, where K is the number of Secure_Path Segments removed in the previous step.)
o 次に、最後に追加した署名セグメントから始めて、前の手順で削除したSecure_Pathセグメントの数と同じ数の署名セグメントを削除します。 （つまり、最後に追加されたK個の署名セグメントを削除します。ここで、Kは前のステップで削除されたSecure_Pathセグメントの数です。）
o Finally, add a Secure_Path Segment containing, in the AS field, the AS Confederation Identifier (the public AS number of the confederation) as well as a corresponding Signature Segment. Note that all fields other than the AS field are populated as per Section 4.2.
o 最後に、ASフィールドにASコンフェデレーション識別子（コンフェデレーションのパブリックAS番号）および対応する署名セグメントを含むSecure_Pathセグメントを追加します。 ASフィールド以外のすべてのフィールドは、セクション4.2に従って入力されることに注意してください。
Finally, as discussed above, an AS confederation MAY optionally decide that its members will not verify digital signatures added by members. In such a confederation, when a BGPsec speaker runs the algorithm in Section 5.2, the BGPsec speaker, during the process of signature verifications, first checks whether the Confed_Segment flag in a Secure_Path Segment is set to 1. If the flag is set to 1, the BGPsec speaker skips the verification for the corresponding signature and immediately moves on to the next Secure_Path Segment. Note that as specified in Section 5.2, it is an error when a BGPsec speaker receives, from a peer who is not in the same AS confederation, a BGPsec UPDATE message containing a Confed_Segment flag set to 1.
最後に、上で説明したように、AS連合はオプションで、そのメンバーがメンバーによって追加されたデジタル署名を検証しないことを決定してもよい（MAY）。このようなコンフェデレーションでは、BGPsecスピーカーがセクション5.2のアルゴリズムを実行すると、署名検証のプロセス中に、BGPsecスピーカーは最初にSecure_PathセグメントのConfed_Segmentフラグが1に設定されているかどうかを確認します。フラグが1に設定されている場合BGPsecスピーカーは、対応する署名の検証をスキップし、すぐに次のSecure_Pathセグメントに進みます。セクション5.2で指定されているように、BGPsecスピーカーが、同じAS連合に属していないピアから、1に設定されたConfed_Segmentフラグを含むBGPsec UPDATEメッセージを受信すると、エラーになります。
BGPsec UPDATE messages do not contain the AS_PATH attribute. However, the AS_PATH attribute can be reconstructed from the BGPsec_PATH attribute. This is necessary in the case where a route advertisement is received via a BGPsec UPDATE message and then propagated to a peer via a non-BGPsec UPDATE message (e.g., because the latter peer does not support BGPsec). Note that there may be additional cases where an implementation finds it useful to perform this reconstruction. Before attempting to reconstruct an AS_PATH for the purpose of forwarding an unsigned (non-BGPsec) UPDATE message to a peer, a BGPsec speaker MUST perform the basic integrity checks listed in Section 5.2 to ensure that the received BGPsec UPDATE message is properly formed.
BGPsec UPDATEメッセージには、AS_PATH属性が含まれていません。ただし、AS_PATH属性はBGPsec_PATH属性から再構築できます。これは、ルートアドバタイズメントがBGPsec UPDATEメッセージを介して受信され、非BGPsec UPDATEメッセージを介してピアに伝播される場合に必要です（たとえば、後者のピアはBGPsecをサポートしていないため）。実装によっては、この再構成を実行することが有用であると思われる追加のケースがあることに注意してください。署名されていない（非BGPsec）UPDATEメッセージをピアに転送する目的でAS_PATHを再構築する前に、BGPsecスピーカーはセクション5.2にリストされている基本的な整合性チェックを実行して、受信したBGPsec UPDATEメッセージが適切に形成されていることを確認する必要があります。
The AS_PATH attribute can be constructed from the BGPsec_PATH attribute as follows. Starting with a blank AS_PATH attribute, process the Secure_Path Segments in order from least recently added (corresponding to the origin) to most recently added. For each Secure_Path Segment, perform the following steps:
AS_PATH属性は、BGPsec_PATH属性から次のように作成できます。空白のAS_PATH属性から始めて、最後に追加された（起点に対応する）ものから最後に追加されたものの順にSecure_Pathセグメントを処理します。 Secure_Pathセグメントごとに、次の手順を実行します。
1. If the Secure_Path Segment has pCount=0, then do nothing (i.e., move on to process the next Secure_Path Segment).
1. Secure_PathセグメントにpCount = 0がある場合は、何もしません（つまり、次のSecure_Pathセグメントの処理に進みます）。
2. If the Secure_Path Segment has pCount greater than 0 and the Confed_Segment flag is set to 1, then look at the most recently added segment in the AS_PATH.
2. Secure_PathセグメントのpCountが0より大きく、Confed_Segmentフラグが1に設定されている場合は、AS_PATHで最後に追加されたセグメントを調べます。
* In the case where the AS_PATH is blank or in the case where the most recently added segment is of type AS_SEQUENCE, add (prepend to the AS_PATH) a new AS_PATH segment of type AS_CONFED_SEQUENCE. This segment of type AS_CONFED_SEQUENCE shall contain a number of elements equal to the pCount field in the current Secure_Path Segment. Each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then the segment of type AS_CONFED_SEQUENCE contains X copies of the Secure_Path Segment's AS Number field.)
* AS_PATHが空白の場合、または最後に追加されたセグメントのタイプがAS_SEQUENCEの場合は、タイプAS_CONFED_SEQUENCEの新しいAS_PATHセグメントを追加（AS_PATHの前に追加）します。タイプAS_CONFED_SEQUENCEのこのセグメントには、現在のSecure_PathセグメントのpCountフィールドに等しい要素の数が含まれます。これらの各要素は、現在のSecure_Pathセグメントに含まれるAS番号になります。 （つまり、pCountフィールドがXの場合、AS_CONFED_SEQUENCEタイプのセグメントには、Secure_PathセグメントのAS番号フィールドのX個のコピーが含まれます。）
* In the case where the most recently added segment in the AS_PATH is of type AS_CONFED_SEQUENCE, then add (prepend to the segment) a number of elements equal to the pCount field in the current Secure_Path Segment. The value of each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then add X copies of the Secure_Path Segment's AS Number field to the existing AS_CONFED_SEQUENCE.)
* AS_PATHに最後に追加されたセグメントのタイプがAS_CONFED_SEQUENCEである場合は、現在のSecure_PathセグメントのpCountフィールドに等しい数の要素を追加（セグメントの先頭に追加）します。これらの各要素の値は、現在のSecure_Pathセグメントに含まれているAS番号になります。 （つまり、pCountフィールドがXの場合、Secure_PathセグメントのAS番号フィールドのXコピーを既存のAS_CONFED_SEQUENCEに追加します。）
3. If the Secure_Path Segment has pCount greater than 0 and the Confed_Segment flag is set to 0, then look at the most recently added segment in the AS_PATH.
3. Secure_PathセグメントのpCountが0より大きく、Confed_Segmentフラグが0に設定されている場合は、AS_PATHで最後に追加されたセグメントを調べます。
* In the case where the AS_PATH is blank or in the case where the most recently added segment is of type AS_CONFED_SEQUENCE, add (prepend to the AS_PATH) a new AS_PATH segment of type AS_SEQUENCE. This segment of type AS_SEQUENCE shall contain a number of elements equal to the pCount field in the current Secure_Path Segment. Each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then the segment of type AS_SEQUENCE contains X copies of the Secure_Path Segment's AS Number field.)
* AS_PATHが空白の場合、または最後に追加されたセグメントのタイプがAS_CONFED_SEQUENCEの場合は、タイプAS_SEQUENCEの新しいAS_PATHセグメントを追加（AS_PATHの前に追加）します。タイプAS_SEQUENCEのこのセグメントには、現在のSecure_PathセグメントのpCountフィールドと同じ数の要素が含まれます。これらの各要素は、現在のSecure_Pathセグメントに含まれるAS番号になります。 （つまり、pCountフィールドがXの場合、タイプAS_SEQUENCEのセグメントには、Secure_PathセグメントのAS番号フィールドのX個のコピーが含まれます。）
* In the case where the most recently added segment in the AS_PATH is of type AS_SEQUENCE, then add (prepend to the segment) a number of elements equal to the pCount field in the current Secure_Path Segment. The value of each of these elements shall be the AS number contained in the current Secure_Path Segment. (That is, if the pCount field is X, then add X copies of the Secure_Path Segment's AS Number field to the existing AS_SEQUENCE.)
* AS_PATHに最後に追加されたセグメントのタイプがAS_SEQUENCEである場合は、現在のSecure_PathセグメントのpCountフィールドに等しい数の要素を追加（セグメントの先頭に追加）します。これらの各要素の値は、現在のSecure_Pathセグメントに含まれているAS番号になります。 （つまり、pCountフィールドがXの場合、Secure_PathセグメントのAS番号フィールドのXコピーを既存のAS_SEQUENCEに追加します。）
As part of the procedure described above, the following additional actions are performed in order not to exceed the size limitations of AS_SEQUENCE and AS_CONFED_SEQUENCE. While adding the next Secure_Path Segment (with its prepends, if any) to the AS_PATH being assembled, if it would cause the AS_SEQUENCE (or AS_CONFED_SEQUENCE) at hand to exceed the limit of 255 AS numbers per segment [RFC4271] [RFC5065], then the BGPsec speaker would follow the recommendations in RFC 4271 [RFC4271] and RFC 5065 [RFC5065] of creating another segment of the same type (AS_SEQUENCE or AS_CONFED_SEQUENCE) and continue filling that.
上記の手順の一部として、AS_SEQUENCEおよびAS_CONFED_SEQUENCEのサイズ制限を超えないように、次の追加アクションが実行されます。アセンブルされるAS_PATHに次のSecure_Pathセグメント（存在する場合はその先頭に追加）を追加するときに、手元のAS_SEQUENCE（またはAS_CONFED_SEQUENCE）がセグメントあたりのAS番号255の制限を超える場合[RFC4271] [RFC5065]、 BGPsecスピーカーは、RFC 4271 [RFC4271]およびRFC 5065 [RFC5065]の推奨事項に従い、同じタイプ（AS_SEQUENCEまたはAS_CONFED_SEQUENCE）の別のセグメントを作成し、それを満たし続けます。
Finally, one special case of reconstruction of AS_PATH is when the BGPsec_PATH attribute is absent. As explained in Section 4.1, when a BGPsec speaker originates a prefix and sends it to a BGPsec-capable iBGP peer, the BGPsec_PATH is not attached. So, when received from a BGPsec-capable iBGP peer, no BGPsec_PATH attribute in a BGPsec UPDATE message is equivalent to an empty AS_PATH [RFC4271].
最後に、AS_PATHの再構築の特殊なケースの1つは、BGPsec_PATH属性がない場合です。セクション4.1で説明したように、BGPsecスピーカーがプレフィックスを生成してBGPsec対応のiBGPピアに送信する場合、BGPsec_PATHはアタッチされません。したがって、BGPsec対応のiBGPピアから受信した場合、BGPsec UPDATEメッセージのBGPsec_PATH属性は、空のAS_PATH [RFC4271]に相当しません。
Upon receiving a BGPsec UPDATE message from an external (eBGP) peer, a BGPsec speaker SHOULD validate the message to determine the authenticity of the path information contained in the BGPsec_PATH attribute. Typically, a BGPsec speaker will also wish to perform origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]) on an incoming BGPsec UPDATE message, but such validation is independent of the validation described in this section.
外部（eBGP）ピアからBGPsec UPDATEメッセージを受信すると、BGPsecスピーカーはメッセージを検証して、BGPsec_PATH属性に含まれるパス情報の信頼性を判断する必要があります（SHOULD）。通常、BGPsecスピーカーは、着信BGPsec UPDATEメッセージに対して発信元検証（RFC 6483 [RFC6483]およびRFC 6811 [RFC6811]を参照）も実行することを望みますが、この検証はこのセクションで説明する検証とは無関係です。
Section 5.1 provides an overview of BGPsec validation, and Section 5.2 provides a specific algorithm for performing such validation. (Note that an implementation need not follow the specific algorithm in Section 5.2 as long as the input/output behavior of the validation is identical to that of the algorithm in Section 5.2.) During exceptional conditions (e.g., the BGPsec
セクション5.1はBGPsec検証の概要を提供し、セクション5.2はそのような検証を実行するための特定のアルゴリズムを提供します。 （検証の入出力動作がセクション5.2のアルゴリズムの動作と同じである限り、実装はセクション5.2の特定のアルゴリズムに従う必要はないことに注意してください。）例外的な状況（BGPsecなど）
speaker receives an incredibly large number of UPDATE messages at once), a BGPsec speaker MAY temporarily defer validation of incoming BGPsec UPDATE messages. The treatment of such BGPsec UPDATE messages, whose validation has been deferred, is a matter of local policy. However, an implementation SHOULD ensure that deferment of validation and status of deferred messages is visible to the operator.
スピーカーは信じられないほど大量のUPDATEメッセージを一度に受信します）、BGPsecスピーカーは着信BGPsec UPDATEメッセージの検証を一時的に延期できます（MAY）。検証が延期されたこのようなBGPsec UPDATEメッセージの処理は、ローカルポリシーの問題です。ただし、実装では、検証の遅延と遅延メッセージのステータスがオペレーターに表示されるようにする必要があります（SHOULD）。
The validity of BGPsec UPDATE messages is a function of the current RPKI state. When a BGPsec speaker learns that the RPKI state has changed (e.g., from an RPKI validating cache via the RPKI-Router protocol [RFC8210]), the BGPsec speaker MUST rerun validation on all affected UPDATE messages stored in its Adj-RIB-In [RFC4271]. For example, when a given RPKI router certificate ceases to be valid (e.g., it expires or is revoked), all UPDATE messages containing a signature whose SKI matches the SKI in the given certificate MUST be reassessed to determine if they are still valid. If this reassessment determines that the validity state of an UPDATE message has changed, then, depending on local policy, it may be necessary to rerun best path selection.
BGPsec UPDATEメッセージの有効性は、現在のRPKI状態の関数です。 BGPsecスピーカーがRPKI状態が変更されたことを（たとえば、RPKIルータープロトコル[RFC8210]を介したRPKI検証キャッシュから）学習すると、BGPsecスピーカーは、そのAdj-RIB-In [に保存されている影響を受けるすべてのUPDATEメッセージで検証を再実行する必要があります。 RFC4271]。たとえば、特定のRPKIルーター証明書が有効でなくなった（たとえば、有効期限が切れた、または取り消された）場合、そのSKIが特定の証明書のSKIと一致する署名を含むすべてのUPDATEメッセージを再評価して、まだ有効かどうかを判断する必要があります。この再評価でUPDATEメッセージの有効性の状態が変更されたと判断された場合、ローカルポリシーによっては、最適パスの選択を再実行する必要がある場合があります。
BGPsec UPDATE messages do not contain an AS_PATH attribute. The Secure_Path contains AS path information for the BGPsec UPDATE message. Therefore, a BGPsec speaker MUST utilize the AS path information in the Secure_Path in all cases where it would otherwise use the AS path information in the AS_PATH attribute. The only exception to this rule is when AS path information must be updated in order to propagate a route to a peer (in which case the BGPsec speaker follows the instructions in Section 4). Section 4.4 provides an algorithm for constructing an AS_PATH attribute from a BGPsec_PATH attribute. Whenever the use of AS path information is called for (e.g., loop detection or the use of the AS path length in best path selection), the externally visible behavior of the implementation shall be the same as if the implementation had run the algorithm in Section 4.4 and used the resulting AS_PATH attribute as it would for a non-BGPsec UPDATE message.
BGPsec UPDATEメッセージには、AS_PATH属性が含まれていません。 Secure_Pathには、BGPsec UPDATEメッセージのASパス情報が含まれています。したがって、BGPsecスピーカーは、AS_PATH属性のASパス情報を使用するすべてのケースで、Secure_PathのASパス情報を利用する必要があります。このルールの唯一の例外は、ルートをピアに伝播するためにASパス情報を更新する必要がある場合です（この場合、BGPsecスピーカーはセクション4の指示に従います）。セクション4.4は、BGPsec_PATH属性からAS_PATH属性を構築するためのアルゴリズムを提供します。 ASパス情報の使用が要求されるときはいつでも（たとえば、ループ検出またはベストパス選択でのASパス長の使用）、実装の外部から見える動作は、実装がセクションのアルゴリズムを実行した場合と同じになります。 4.4であり、非BGPsec UPDATEメッセージの場合と同様に、結果のAS_PATH属性を使用しました。
Validation of a BGPsec UPDATE message makes use of data from RPKI router certificates. In particular, it is necessary that the recipient have access to the following data obtained from valid RPKI router certificates: the AS Number, Public Key, and Subject Key Identifier from each valid RPKI router certificate.
BGPsec UPDATEメッセージの検証は、RPKIルーター証明書のデータを利用します。特に、受信者は、有効なRPKIルーター証明書から取得した次のデータ（AS番号、公開鍵、および有効な各RPKIルーター証明書からのサブジェクト鍵識別子）にアクセスできる必要があります。
Note that the BGPsec speaker could perform the validation of RPKI router certificates on its own and extract the required data, or it could receive the same data from a trusted cache that performs RPKI validation on behalf of (some set of) BGPsec speakers. (For example, the trusted cache could deliver the necessary validity information to the BGPsec speaker by using the Router Key PDU (Protocol Data Unit) for the RPKI-Router protocol [RFC8210].)
BGPsecスピーカーは、RPKIルーター証明書の検証を独自に実行して必要なデータを抽出することも、BGPsecスピーカー（のセット）に代わってRPKI検証を実行する信頼できるキャッシュから同じデータを受信することもあります。 （たとえば、信頼できるキャッシュは、RPKI-Routerプロトコル[RFC8210]のルーターキーPDU（プロトコルデータユニット）を使用して、必要な有効性情報をBGPsecスピーカーに配信できます。）
To validate a BGPsec UPDATE message containing the BGPsec_PATH attribute, the recipient performs the validation steps specified in Section 5.2. The validation procedure results in one of two states: 'Valid' and 'Not Valid'.
BGPsec_PATH属性を含むBGPsec UPDATEメッセージを検証するために、受信者はセクション5.2で指定された検証手順を実行します。検証手順の結果、「有効」と「無効」の2つの状態のいずれかになります。
It is expected that the output of the validation procedure will be used as an input to BGP route selection. That said, BGP route selection, and thus the handling of the validation states, is a matter of local policy and is handled using local policy mechanisms. Implementations SHOULD enable operators to set such local policy on a per-session basis. (That is, it is expected that some operators will choose to treat BGPsec validation status differently for UPDATE messages received over different BGP sessions.)
検証手順の出力は、BGPルート選択への入力として使用されることが期待されています。とはいえ、BGPルートの選択、つまり検証状態の処理はローカルポリシーの問題であり、ローカルポリシーメカニズムを使用して処理されます。実装は、オペレーターがこのようなローカルポリシーをセッションごとに設定できるようにする必要があります（SHOULD）。 （つまり、一部のオペレーターは、異なるBGPセッションで受信したUPDATEメッセージに対して、BGPsec検証ステータスを異なる方法で処理することを選択することが予想されます。）
BGPsec validation need only be performed at the eBGP edge. The validation status of a BGP signed/unsigned UPDATE message MAY be conveyed via iBGP from an ingress edge router to an egress edge router via some mechanism, according to local policy within an AS. As discussed in Section 4, when a BGPsec speaker chooses to forward a (syntactically correct) BGPsec UPDATE message, it SHOULD be forwarded with its BGPsec_PATH attribute intact (regardless of the validation state of the UPDATE message). Based entirely on local policy, an egress router receiving a BGPsec UPDATE message from within its own AS MAY choose to perform its own validation.
BGPsec検証は、eBGPエッジでのみ実行する必要があります。 AS内のローカルポリシーに従って、BGP署名付き/署名なしUPDATEメッセージの検証ステータスは、何らかのメカニズムを介して、入口エッジルーターから出口エッジルーターにiBGPを介して伝達される場合があります。セクション4で説明したように、BGPsecスピーカーが（構文的に正しい）BGPsec UPDATEメッセージを転送することを選択した場合、（UPDATEメッセージの検証状態に関係なく）BGPsec_PATH属性をそのままにして転送する必要があります（SHOULD）。完全にローカルポリシーに基づいて、自身のAS内からBGPsec UPDATEメッセージを受信する出口ルーターは、独自の検証を実行することを選択できます。
This section specifies an algorithm for validation of BGPsec UPDATE messages. A conformant implementation MUST include a BGPsec update validation algorithm that is functionally equivalent to the externally visible behavior of this algorithm.
このセクションでは、BGPsec UPDATEメッセージの検証アルゴリズムを指定します。適合実装には、このアルゴリズムの外部から見える動作と機能的に同等のBGPsec更新検証アルゴリズムを含める必要があります。
First, the recipient of a BGPsec UPDATE message performs a check to ensure that the message is properly formed. Both syntactical and protocol violation errors are checked. The BGPsec_PATH attribute MUST be present when a BGPsec UPDATE message is received from an external (eBGP) BGPsec peer and also when such an UPDATE message is propagated to an internal (iBGP) BGPsec peer (see Section 4.2). The error checks specified in Section 6.3 of [RFC4271] are performed, except that for BGPsec UPDATE messages the checks on the AS_PATH attribute do not apply and instead the following checks on the BGPsec_PATH attribute are performed: 1. Check to ensure that the entire BGPsec_PATH attribute is syntactically correct (conforms to the specification in this document).
まず、BGPsec UPDATEメッセージの受信者は、メッセージが適切に形成されていることを確認するチェックを実行します。構文エラーとプロトコル違反エラーの両方がチェックされます。 BGPsec_PATH属性は、BGPsec UPDATEメッセージが外部（eBGP）BGPsecピアから受信される場合、およびそのようなUPDATEメッセージが内部（iBGP）BGPsecピアに伝播される場合に存在する必要があります（セクション4.2を参照）。 [RFC4271]のセクション6.3で指定されているエラーチェックが実行されます。ただし、BGPsec UPDATEメッセージの場合、AS_PATH属性のチェックは適用されず、代わりにBGPsec_PATH属性の次のチェックが実行されます。1. BGPsec_PATH全体を確認します。属性は構文的に正しい（このドキュメントの仕様に準拠）。
2. Check that the AS number in the most recently added Secure_Path Segment (i.e., the one corresponding to the eBGP peer from which the UPDATE message was received) matches the AS number of that peer as specified in the BGP OPEN message. (Note: This check is performed only at an ingress BGPsec router where the UPDATE message is first received from a peer AS.)
2. 最後に追加されたSecure_Pathセグメント（つまり、UPDATEメッセージを受信したeBGPピアに対応するセグメント）のAS番号が、BGP OPENメッセージで指定されているそのピアのAS番号と一致することを確認します。 （注：このチェックは、UPDATEメッセージがピアASから最初に受信される入力BGPsecルーターでのみ実行されます。）
3. Check that each Signature_Block contains one Signature Segment for each Secure_Path Segment in the Secure_Path portion of the BGPsec_PATH attribute. (Note that the entirety of each Signature_Block MUST be checked to ensure that it is well formed, even though the validation process may terminate before all signatures are cryptographically verified.)
3. 各Signature_Blockに、BGPsec_PATH属性のSecure_Path部分のSecure_Pathセグメントごとに1つの署名セグメントが含まれていることを確認します。 （すべての署名が暗号化されて検証される前に検証プロセスが終了する場合でも、各Signature_Block全体をチェックして、その形式が正しいことを確認する必要があることに注意してください。）
4. Check that the UPDATE message does not contain an AS_PATH attribute.
4. UPDATEメッセージにAS_PATH属性が含まれていないことを確認してください。
5. If the UPDATE message was received from a BGPsec peer that is not a member of the BGPsec speaker's AS confederation, check to ensure that none of the Secure_Path Segments contain a Flags field with the Confed_Segment flag set to 1.
5. BGPsecスピーカーのASコンフェデレーションのメンバーではないBGPsecピアからUPDATEメッセージを受信した場合は、Secure_PathセグメントにConfed_Segmentフラグが1に設定されたFlagsフィールドが含まれていないことを確認してください。
6. If the UPDATE message was received from a BGPsec peer that is a member of the BGPsec speaker's AS confederation, check to ensure that the Secure_Path Segment corresponding to that peer contains a Flags field with the Confed_Segment flag set to 1.
6. BGPsecスピーカーのAS連合のメンバーであるBGPsecピアからUPDATEメッセージを受信した場合は、そのピアに対応するSecure_Pathセグメントに、Confed_Segmentフラグが1に設定されたFlagsフィールドが含まれていることを確認してください。
7. If the UPDATE message was received from a peer that is not expected to set pCount=0 (see Sections 4.2 and 4.3), then check to ensure that the pCount field in the most recently added Secure_Path Segment is not equal to 0. (Note: See Section 7.2 for router configuration guidance related to this item.)
7. pCount = 0を設定することが予期されていないピアからUPDATEメッセージを受信した場合（セクション4.2および4.3を参照）、最後に追加されたSecure_PathセグメントのpCountフィールドが0に等しくないことを確認してください（注：このアイテムに関連するルーター構成のガイダンスについては、セクション7.2を参照してください。）
8. Using the equivalent of AS_PATH corresponding to the Secure_Path in the UPDATE message (see Section 4.4), check that the local AS number is not present in the AS path (i.e., rule out an AS loop).
8. UPDATEメッセージのSecure_Pathに対応するAS_PATHと同等のものを使用して（セクション4.4を参照）、ローカルAS番号がASパスに存在しないことを確認します（つまり、ASループを除外します）。
If any of these checks fail, it is an error in the BGPsec_PATH attribute. BGPsec speakers MUST handle any syntactical or protocol errors in the BGPsec_PATH attribute by using the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606]. (Note: Since the AS number of a transparent route server does appear in the Secure_Path with pCount=0, the route server MAY check to see if its local AS is listed in the Secure_Path, and this check MAY be included in the loop-detection check listed above.)
これらのチェックのいずれかが失敗した場合は、BGPsec_PATH属性のエラーです。 BGPsecスピーカーは、RFC 7606 [RFC7606]で定義されている "treat-as-withdraw"アプローチを使用して、BGPsec_PATH属性の構文エラーまたはプロトコルエラーを処理する必要があります。 （注：透過ルートサーバーのAS番号はpCount = 0のSecure_Pathに表示されるため、ルートサーバーはローカルASがSecure_Pathにリストされているかどうかを確認することができます。このチェックはループ検出に含まれる場合があります（MAY）上記を確認してください。）
Next, the BGPsec speaker examines the Signature_Blocks in the BGPsec_PATH attribute. A Signature_Block corresponding to an algorithm suite that the BGPsec speaker does not support is not considered in the validation process. If there is no Signature_Block corresponding to an algorithm suite that the BGPsec speaker supports, then in order to consider the UPDATE message in the route selection process, the BGPsec speaker MUST strip the Signature_Block(s), reconstruct the AS_PATH from the Secure_Path (see Section 4.4), and treat the UPDATE message as if it were received as an unsigned BGP UPDATE message.
次に、BGPsecスピーカーは、BGPsec_PATH属性のSignature_Blocksを調べます。 BGPsecスピーカーがサポートしていないアルゴリズムスイートに対応するSignature_Blockは、検証プロセスでは考慮されません。 BGPsecスピーカーがサポートするアルゴリズムスイートに対応するSignature_Blockがない場合、ルート選択プロセスでUPDATEメッセージを考慮するために、BGPsecスピーカーは、Signature_Blockを削除し、Secure_PathからAS_PATHを再構築する必要があります（セクションを参照）。 4.4）、UPDATEメッセージを、署名されていないBGP UPDATEメッセージとして受信されたかのように扱います。
For each remaining Signature_Block (corresponding to an algorithm suite supported by the BGPsec speaker), the BGPsec speaker iterates through the Signature Segments in the Signature_Block, starting with the most recently added segment (and concluding with the least recently added segment). Note that there is a one-to-one correspondence between Signature Segments and Secure_Path Segments within the BGPsec_PATH attribute. The following steps make use of this correspondence:
残りの各Signature_Block（BGPsecスピーカーでサポートされているアルゴリズムスイートに対応）について、BGPsecスピーカーは、最後に追加されたセグメントから始まり（最後に追加されていないセグメントで終了する）、Signature_Blockの署名セグメントを反復処理します。 BGPsec_PATH属性内の署名セグメントとSecure_Pathセグメントは1対1で対応していることに注意してください。次の手順では、この対応を利用します。
o Step 1: Let there be K AS hops in a received BGPsec_PATH attribute that is to be validated. Let AS(1), AS(2), ..., AS(K+1) denote the sequence of AS numbers from the origin AS to the validating AS. Let Secure_Path Segment N and Signature Segment N in the BGPsec_PATH attribute refer to those corresponding to AS(N) (where N = 1, 2, ..., K). The BGPsec speaker that is processing and validating the BGPsec_PATH attribute resides in AS(K+1). Let Signature Segment N be the Signature Segment that is currently being verified.
o 手順1：検証される受信したBGPsec_PATH属性にK ASホップが存在するようにします。 AS（1）、AS（2）、...、AS（K + 1）が、起点ASから検証ASへのAS番号のシーケンスを表すとしましょう。 BGPsec_PATH属性のSecure_PathセグメントNおよび署名セグメントNがAS（N）に対応するものを参照するようにします（N = 1、2、...、K）。 BGPsec_PATH属性を処理および検証しているBGPsecスピーカーは、AS（K + 1）に常駐します。署名セグメントNを現在検証中の署名セグメントとします。
o Step 2: Locate the public key needed to verify the signature (in the current Signature Segment). To do this, consult the valid RPKI router certificate data and look up all valid (AS Number, Public Key, Subject Key Identifier) triples in which the AS matches the AS number in the corresponding Secure_Path Segment. Of these triples that match the AS number, check whether there is an SKI that matches the value in the Subject Key Identifier field of the Signature Segment. If this check finds no such matching SKI value, then mark the entire Signature_Block as 'Not Valid' and proceed to the next Signature_Block.
o ステップ2：署名の検証に必要な公開鍵を見つけます（現在の署名セグメント内）。これを行うには、有効なRPKIルーター証明書データを調べ、ASが対応するSecure_PathセグメントのAS番号と一致するすべての有効な（AS番号、公開キー、サブジェクトキー識別子）トリプルを検索します。 AS番号と一致するこれらのトリプルのうち、署名セグメントの[サブジェクトキー識別子]フィールドの値と一致するSKIがあるかどうかを確認します。このチェックで一致するSKI値が見つからない場合は、Signature_Block全体を「無効」としてマークし、次のSignature_Blockに進みます。
o Step 3: Compute the digest function (for the given algorithm suite) on the appropriate data.
o ステップ3：適切なデータに対して（特定のアルゴリズムスイートの）ダイジェスト関数を計算します。
In order to verify the digital signature in Signature Segment N, construct the sequence of octets to be hashed as shown in Figure 9 (using the notations defined in Step 1). (Note that this sequence is the same sequence that was used by AS(N) that created the Signature Segment N (see Section 4.2 and Figure 8).)
署名セグメントNのデジタル署名を検証するには、図9に示すように、ハッシュするオクテットのシーケンスを作成します（手順1で定義した表記を使用）。 （このシーケンスは、署名セグメントNを作成したAS（N）が使用したシーケンスと同じであることに注意してください（セクション4.2および図8を参照））。
+------------------------------------+
| Target AS Number |
+------------------------------------+----\
| Signature Segment : N-1 | \
+------------------------------------+ |
| Secure_Path Segment : N | |
+------------------------------------+ \
... > Data from
+------------------------------------+ / N Segments
| Signature Segment : 1 | |
+------------------------------------+ |
| Secure_Path Segment : 2 | |
+------------------------------------+ /
| Secure_Path Segment : 1 | /
+------------------------------------+---/
| Algorithm Suite Identifier |
+------------------------------------+
| AFI |
+------------------------------------+
| SAFI |
+------------------------------------+
| NLRI |
+------------------------------------+
Figure 9: Sequence of Octets to Be Hashed for Signature Verification of Signature Segment N; N = 1,2, ..., K, Where K Is the Number of AS Hops in the BGPsec_PATH Attribute
図9：署名セグメントNの署名検証のためにハッシュされるオクテットのシーケンス。 N = 1,2、...、K、ここでKはBGPsec_PATH属性のASホップの数
The elements in this sequence (Figure 9) MUST be ordered exactly as shown. For the first segment to be processed (the most recently added segment (i.e., N = K) given that there are K hops in the Secure_Path), the 'Target AS Number' is AS(K+1), the AS number of the BGPsec speaker validating the UPDATE message. Note that if a BGPsec speaker uses multiple AS Numbers (e.g., the BGPsec speaker is a member of a confederation), the AS number used here MUST be the AS number announced in the OPEN message for the BGP session over which the BGPsec UPDATE message was received.
このシーケンスの要素（図9）は、示されているとおりに順序付けする必要があります。処理される最初のセグメント（Secure_PathにKホップある場合、最後に追加されたセグメント（つまり、N = K））の場合、「ターゲットAS番号」はAS（K + 1）であり、 UPDATEメッセージを検証するBGPsecスピーカー。 BGPsecスピーカーが複数のAS番号を使用する場合（たとえば、BGPsecスピーカーが連合のメンバーである場合）、ここで使用されるAS番号は、BGPsec UPDATEメッセージがあったBGPセッションのOPENメッセージでアナウンスされたAS番号である必要があります。受け取った。
For each other Signature Segment (N smaller than K), the 'Target AS Number' is AS(N+1), the AS number in the Secure_Path Segment that corresponds to the Signature Segment added immediately after the one being processed (that is, in the Secure_Path Segment that corresponds to the Signature Segment that the validator just finished processing).
他の各署名セグメント（Kより小さいN）の場合、「ターゲットAS番号」はAS（N + 1）です。これは、処理中の署名セグメントの直後に追加された署名セグメントに対応するSecure_PathセグメントのAS番号です（つまり、バリデーターが処理を終了した署名セグメントに対応するSecure_Pathセグメント内）。
The Secure_Path and Signature Segment are obtained from the BGPsec_PATH attribute. The AFI, SAFI, and NLRI fields are obtained from the MP_REACH_NLRI attribute [RFC4760]. Additionally, in the Prefix field within the NLRI field (see Section 5 in RFC 4760 [RFC4760]), all of the trailing bits MUST be set to 0 when constructing this sequence.
Secure_Pathおよび署名セグメントは、BGPsec_PATH属性から取得されます。 AFI、SAFI、およびNLRIフィールドは、MP_REACH_NLRI属性[RFC4760]から取得されます。さらに、NLRIフィールド内のプレフィックスフィールド（RFC 4760 [RFC4760]のセクション5を参照）では、このシーケンスを構築するときに、すべての後続ビットを0に設定する必要があります。
o Step 4: Use the signature validation algorithm (for the given algorithm suite) to verify the signature in the current segment. That is, invoke the signature validation algorithm on the following three inputs: the value of the Signature field in the current segment, the digest value computed in Step 3 above, and the public key obtained from the valid RPKI data in Step 2 above. If the signature validation algorithm determines that the signature is invalid, then mark the entire Signature_Block as 'Not Valid' and proceed to the next Signature_Block. If the signature validation algorithm determines that the signature is valid, then continue processing Signature Segments (within the current Signature_Block).
o 手順4：署名検証アルゴリズム（指定されたアルゴリズムスイート用）を使用して、現在のセグメントの署名を検証します。つまり、次の3つの入力で署名検証アルゴリズムを呼び出します。現在のセグメントの署名フィールドの値、上記のステップ3で計算されたダイジェスト値、および上記のステップ2で有効なRPKIデータから取得した公開鍵。署名検証アルゴリズムが署名が無効であると判断した場合は、Signature_Block全体を「無効」としてマークし、次のSignature_Blockに進みます。署名検証アルゴリズムが署名が有効であると判断した場合は、署名セグメントの処理を続行します（現在のSignature_Block内）。
If all Signature Segments within a Signature_Block pass validation (i.e., all segments are processed and the Signature_Block has not yet been marked 'Not Valid'), then the Signature_Block is marked as 'Valid'.
Signature_Block内のすべての署名セグメントが検証に合格した場合（つまり、すべてのセグメントが処理され、Signature_Blockがまだ「無効」とマークされていない場合）、Signature_Blockは「有効」とマークされます。
If at least one Signature_Block is marked as 'Valid', then the validation algorithm terminates and the BGPsec UPDATE message is deemed 'Valid'. (That is, if a BGPsec UPDATE message contains two Signature_Blocks, then the UPDATE message is deemed 'Valid' if the first Signature_Block is marked 'Valid' OR the second Signature_Block is marked 'Valid'.)
少なくとも1つのSignature_Blockが「有効」とマークされている場合、検証アルゴリズムは終了し、BGPsec UPDATEメッセージは「有効」と見なされます。 （つまり、BGPsec UPDATEメッセージに2つのSignature_Blockが含まれている場合、最初のSignature_Blockが「有効」とマークされているか、2番目のSignature_Blockが「有効」とマークされていると、UPDATEメッセージは「有効」と見なされます。
Note that there is currently no support for bilateral negotiation (using BGP capabilities) between BGPsec peers to use a particular (digest and signature) algorithm suite. This is because the algorithm suite used by the sender of a BGPsec UPDATE message MUST be understood not only by the peer to whom it is directly sending the message but also by all BGPsec speakers to whom the route advertisement is eventually propagated. Therefore, selection of an algorithm suite cannot be a local matter negotiated by BGP peers but instead must be coordinated throughout the Internet.
現在、特定の（ダイジェストおよび署名）アルゴリズムスイートを使用するためのBGPsecピア間の双方向ネゴシエーション（BGP機能を使用）はサポートされていないことに注意してください。これは、BGPsec UPDATEメッセージの送信者が使用するアルゴリズムスイートは、メッセージを直接送信しているピアだけでなく、ルートアドバタイズメントが最終的に伝播されるすべてのBGPsecスピーカーも理解する必要があるためです。したがって、アルゴリズムスイートの選択は、BGPピアがネゴシエートするローカルな問題ではなく、インターネット全体で調整する必要があります。
To this end, [RFC8208] specifies a mandatory-to-use 'current' algorithm suite for use by all BGPsec speakers.
この目的のために、[RFC8208]は、すべてのBGPsecスピーカーが使用するために使用が必須の「現在の」アルゴリズムスイートを指定しています。
It is anticipated that, in the future, [RFC8208] or its successor will be updated to specify a transition from the 'current' algorithm suite to a 'new' algorithm suite. During the period of transition, all BGPsec UPDATE messages SHOULD simultaneously use both the 'current' algorithm suite and the 'new' algorithm suite. (Note that Sections 3 and 4 specify how the BGPsec_PATH attribute can contain signatures, in parallel, for two algorithm suites.) Once the transition is complete, the use of the old 'current' algorithm will be deprecated, the use of the 'new' algorithm will be mandatory, and a subsequent 'even newer' algorithm suite may be specified as "recommended to implement". Once the transition has successfully been completed in this manner, BGPsec speakers SHOULD include only a single Signature_Block (corresponding to the 'new' algorithm).
将来的には、[RFC8208]またはその後継版が更新され、「現在の」アルゴリズムスイートから「新しい」アルゴリズムスイートへの移行を指定する予定です。移行期間中、すべてのBGPsec UPDATEメッセージは、「現在の」アルゴリズムスイートと「新しい」アルゴリズムスイートの両方を同時に使用する必要があります（SHOULD）。 （セクション3と4は、2つのアルゴリズムスイートのBGPsec_PATH属性にシグネチャを並行して含める方法を指定していることに注意してください。）移行が完了すると、古い「現在の」アルゴリズムの使用は廃止され、「新しい」の使用が廃止されます。 'アルゴリズムは必須であり、後続の「さらに新しい」アルゴリズムスイートは、「実装が推奨されている」として指定できます。この方法で移行が正常に完了すると、BGPsecスピーカーには、（「新しい」アルゴリズムに対応する）1つのSignature_Blockのみを含める必要があります（SHOULD）。
Depending on the method of generating key identifiers [RFC7093], the size of the SKI in an RPKI router certificate may vary. The SKI field in the BGPsec_PATH attribute has a fixed size of 20 octets (see Figure 7). If the SKI is longer than 20 octets, then use the leftmost 20 octets of the SKI (excluding the tag and length) [RFC7093]. If the SKI value is shorter than 20 octets, then pad the SKI (excluding the tag and length) to the right (least significant octets) with octets having "0" values.
鍵識別子の生成方法[RFC7093]に応じて、RPKIルーター証明書のSKIのサイズは異なる場合があります。 BGPsec_PATH属性のSKIフィールドには、20オクテットの固定サイズがあります（図7を参照）。 SKIが20オクテットより長い場合、SKIの左端の20オクテット（タグと長さを除く）を使用します[RFC7093]。 SKI値が20オクテットより短い場合は、SKI（タグと長さを除く）を「0」の値を持つオクテットで右側（最下位オクテット）に埋め込みます。
This section discusses potential changes to BGPsec that would require substantial changes to the processing of the BGPsec_PATH and thus necessitate a new version of BGPsec. Examples of such changes include:
このセクションでは、BGPsec_PATHの処理を大幅に変更する必要があるため、新しいバージョンのBGPsecが必要になる可能性があるBGPsecの潜在的な変更について説明します。そのような変更の例は次のとおりです。
o A new type of signature algorithm that produces signatures of variable length
o 可変長の署名を生成する新しいタイプの署名アルゴリズム
o A new type of signature algorithm for which the number of signatures in the Signature_Block is not equal to the number of ASes in the Secure_Path (e.g., aggregate signatures)
o Signature_Block内の署名の数がSecure_Path内のASの数と等しくない新しいタイプの署名アルゴリズム（例：集約署名）
o Changes to the data that is protected by the BGPsec signatures (e.g., attributes other than the AS path)
o BGPsecシグネチャによって保護されているデータへの変更（例：ASパス以外の属性）
In the case that such a change to BGPsec were deemed desirable, it is expected that a subsequent version of BGPsec would be created and that this version of BGPsec would specify a new BGP path attribute -- let's call it "BGPsec_PATH_Two" -- that is designed to accommodate the desired changes to BGPsec. In such a case, [RFC8208] or its successor would be updated to specify algorithm suites appropriate for the new version of BGPsec.
BGPsecへのそのような変更が望ましいと見なされた場合、BGPsecの後続バージョンが作成され、このバージョンのBGPsecが新しいBGPパス属性を指定することが予想されます。これを「BGPsec_PATH_Two」と呼びましょう-つまりBGPsecへの必要な変更に対応するように設計されています。そのような場合、[RFC8208]またはその後継は、BGPsecの新しいバージョンに適したアルゴリズムスイートを指定するように更新されます。
At this point, a transition would begin that is analogous to the algorithm transition discussed in Section 6.1. During the transition period, all BGPsec speakers SHOULD simultaneously include both the BGPsec_PATH attribute and the new BGPsec_PATH_Two attribute. Once the transition is complete, the use of BGPsec_PATH could then be deprecated, at which point BGPsec speakers should include only the new BGPsec_PATH_Two attribute. Such a process could facilitate a transition to a new BGPsec semantics in a backwards-compatible fashion.
この時点で、セクション6.1で説明したアルゴリズム遷移に類似した遷移が始まります。移行期間中、すべてのBGPsecスピーカーは、BGPsec_PATH属性と新しいBGPsec_PATH_Two属性の両方を同時に含める必要があります（SHOULD）。移行が完了すると、BGPsec_PATHの使用が廃止される可能性があります。この時点で、BGPsecスピーカーには新しいBGPsec_PATH_Two属性のみを含める必要があります。このようなプロセスにより、下位互換性のある方法で新しいBGPsecセマンティクスへの移行が容易になります。
Some operations and management issues that are closely relevant to BGPsec protocol specification and deployment are highlighted here. The best practices concerning operations and deployment of BGPsec are provided in [RFC8207].
ここでは、BGPsecプロトコルの仕様と展開に密接に関連するいくつかの操作と管理の問題を取り上げます。 BGPsecの運用と展開に関するベストプラクティスは、[RFC8207]で提供されています。
Section 2.2 describes the negotiation required to establish a BGPsec-capable peering session. Not only must the BGPsec capability be exchanged (and agreed on), but the BGP multiprotocol extension [RFC4760] for the same AFI and the 4-byte AS capability [RFC6793] MUST also be exchanged. Failure to properly negotiate a BGPsec session -- due to a missing capability, for example -- may still result in the exchange of BGP (unsigned) UPDATE messages. It is RECOMMENDED that an implementation log the failure to properly negotiate a BGPsec session. Also, an implementation MUST have the ability to prevent a BGP session from being established if configured to only use BGPsec.
セクション2.2では、BGPsec対応のピアリングセッションを確立するために必要なネゴシエーションについて説明します。 BGPsec機能を交換する（そして合意する）だけでなく、同じAFIのBGPマルチプロトコル拡張[RFC4760]と4バイトのAS機能[RFC6793]も交換する必要があります。たとえば、機能の欠落が原因で、BGPsecセッションを適切にネゴシエートできない場合でも、BGP（署名なし）UPDATEメッセージが交換される可能性があります。実装では、BGPsecセッションを適切にネゴシエートするための失敗をログに記録することをお勧めします。また、実装には、BGPsecのみを使用するように構成されている場合、BGPセッションが確立されないようにする機能が必要です。
A peer that is an Internet Exchange Point (IXP) (i.e., route server) with a transparent AS is expected to set pCount=0 in its Secure_Path Segment while forwarding an UPDATE message to a peer (see Section 4.2). Clearly, such an IXP MUST configure its BGPsec router to set pCount=0 in its Secure_Path Segment. This also means that a BGPsec speaker MUST be configured so that it permits pCount=0 from an IXP peer. Two other cases where pCount is set to 0 are in the contexts of an AS confederation (see Section 4.3) and of AS migration [RFC8206]. In these two cases, pCount=0 is set and accepted within the same AS (albeit the AS has two different identities). Note that if a BGPsec speaker does not expect a peer AS to set its pCount=0 and if an UPDATE message received from that peer violates this, then the UPDATE message MUST be considered to be in error (see the list of checks in Section 5.2). See Section 8.4 for a discussion of security considerations concerning pCount=0.
透過ASを備えたインターネットエクスチェンジポイント（IXP）（つまりルートサーバー）であるピアは、UPDATEメッセージをピアに転送するときに、Secure_PathセグメントにpCount = 0を設定することが期待されます（セクション4.2を参照）。明らかに、そのようなIXPは、Secure_PathセグメントでpCount = 0を設定するようにBGPsecルーターを構成する必要があります。これは、BGPsecスピーカーがIXPピアからのpCount = 0を許可するように構成されている必要があることも意味します。 pCountが0に設定されている他の2つのケースは、AS連合（セクション4.3を参照）とAS移行[RFC8206]のコンテキストにあります。これら2つのケースでは、pCount = 0が設定され、同じAS内で受け入れられます（ASには2つの異なるIDがあります）。 BGPsecスピーカーがピアASがそのpCount = 0を設定することを期待しておらず、そのピアから受信したUPDATEメッセージがこれに違反している場合、UPDATEメッセージはエラーであると見なさなければならないことに注意してください（セクション5.2のチェックのリストを参照してください） ）。 pCount = 0に関するセキュリティの考慮事項については、セクション8.4を参照してください。
During the validation of a BGPsec UPDATE message, route processor performance speedup can be achieved by incorporating the following observations. An UPDATE message is deemed 'Valid' if at least one of the Signature_Blocks is marked as 'Valid' (see Section 5.2). Therefore, if an UPDATE message contains two Signature_Blocks and the first one verified is found 'Valid', then the second Signature_Block does not have to be verified. And if the UPDATE message is chosen for best path, then the BGPsec speaker adds its signature (generated with the respective algorithm) to each of the two Signature_Blocks and forwards the UPDATE message. Also, a BGPsec UPDATE message is deemed 'Not Valid' if at least one signature in each of the Signature_Blocks is invalid. This principle can also be used for route processor workload savings, i.e., the verification for a Signature_Block terminates early when the first invalid signature is encountered.
BGPsec UPDATEメッセージの検証中に、次の観察結果を組み込むことにより、ルートプロセッサのパフォーマンスを向上させることができます。少なくとも1つのSignature_Blocksが「有効」とマークされている場合、UPDATEメッセージは「有効」と見なされます（セクション5.2を参照）。したがって、UPDATEメッセージに2つのSignature_Blockが含まれていて、最初に検証されたものが「有効」であることが判明した場合、2番目のSignature_Blockを検証する必要はありません。そして、UPDATEメッセージが最良のパスとして選択された場合、BGPsecスピーカーはその署名（それぞれのアルゴリズムで生成された）を2つのSignature_Blockのそれぞれに追加し、UPDATEメッセージを転送します。また、各Signature_Blocksの少なくとも1つの署名が無効な場合、BGPsec UPDATEメッセージは「無効」と見なされます。この原則は、ルートプロセッサのワークロードを節約するためにも使用できます。つまり、最初の無効な署名が検出されると、Signature_Blockの検証が早期に終了します。
Many signature algorithms are non-deterministic. That is, many signature algorithms will produce different signatures each time they are run (even when they are signing the same data with the same key). Therefore, if a BGPsec router receives a BGPsec UPDATE message from a peer and later receives a second BGPsec UPDATE message from the same peer for the same prefix with the same Secure_Path and SKIs, the second UPDATE message MAY differ from the first UPDATE message in the signature fields (for a non-deterministic signature algorithm). However, the two sets of signature fields will not differ if the sender caches and reuses the previous signature. For a deterministic signature algorithm, the signature fields MUST be identical between the two UPDATE messages. On the basis of these observations, an implementation MAY incorporate optimizations in update validation processing.
多くの署名アルゴリズムは非決定的です。つまり、多くの署名アルゴリズムは、（同じキーで同じデータに署名している場合でも）実行されるたびに異なる署名を生成します。したがって、BGPsecルーターがピアからBGPsec UPDATEメッセージを受信し、後で同じSecure_PathとSKIを持つ同じプレフィックスの同じピアから2番目のBGPsec UPDATEメッセージを受信した場合、2番目のUPDATEメッセージは、最初のUPDATEメッセージとは異なる場合があります。署名フィールド（非決定的署名アルゴリズムの場合）。ただし、送信者が以前の署名をキャッシュして再利用する場合、2つの署名フィールドのセットに違いはありません。確定的署名アルゴリズムの場合、署名フィールドは2つのUPDATEメッセージ間で同一でなければなりません。これらの観察に基づいて、実装は更新検証処理に最適化を組み込むことができます。
It is possible that a stub customer of an ISP employs a private AS number. Such a stub customer cannot publish a ROA in the Global RPKI for the private AS number and the prefixes that they use. Also, the Global RPKI cannot support private AS numbers (i.e., BGPsec speakers in private ASes cannot be issued router certificates in the Global RPKI). For interactions between the stub customer (with the private AS number) and the ISP, the following two scenarios are possible:
ISPのスタブカスタマーがプライベートAS番号を使用している可能性があります。このようなスタブカスタマーは、プライベートAS番号と使用するプレフィックスのグローバルRPKIでROAを公開できません。また、グローバルRPKIはプライベートAS番号をサポートできません（つまり、プライベートASのBGPsecスピーカーはグローバルRPKIでルーター証明書を発行できません）。スタブカスタマー（プライベートAS番号を持つ）とISPの間のやり取りでは、次の2つのシナリオが考えられます。
1. The stub customer sends an unsigned BGP UPDATE message for a prefix to the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose to propagate the prefix to its non-BGPsec and BGPsec peers. If so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the private AS number and then (a) re-originate the prefix without any signatures towards its non-BGPsec peer and (b) re-originate the prefix including its own signature towards its BGPsec peer. In both cases (i.e., (a) and (b)), the prefix MUST have a ROA in the Global RPKI authorizing the ISP's AS to originate it.
1. スタブカスタマーは、ISPのASにプレフィックスの署名されていないBGP UPDATEメッセージを送信します。 ISPのASのエッジBGPsecスピーカーは、プレフィックスを非BGPsecピアとBGPsecピアに伝播することを選択できます。その場合、ISPのエッジBGPsecスピーカーは、プライベートAS番号でAS_PATHを取り除き、（a）非BGPsecピアに対する署名なしでプレフィックスを再生成し、（b）独自の署名を含むプレフィックスを再生成する必要があります。そのBGPsecピア。どちらの場合も（つまり、（a）と（b））、プレフィックスはグローバルRPKIにROAがなければならず、ISPのASがそれを発信することを許可します。
2. The ISP and the stub customer may use a local RPKI repository (using a mechanism such as one of the mechanisms described in [SLURM]). Then, there can be a ROA for the prefix originated by the stub AS, and the eBGP speaker in the stub AS can be a BGPsec speaker having a router certificate, albeit the ROA and router certificate are valid only locally. With this arrangement, the stub AS sends a signed UPDATE message for the prefix to the ISP's AS. An edge BGPsec speaker in the ISP's AS validates the UPDATE message, using RPKI data based on the local RPKI view. Further, it may choose to propagate the prefix to its non-BGPsec and BGPsec peers. If so, the ISP's edge BGPsec speaker MUST strip the Secure_Path and the Signature Segment received from the stub AS with the private AS number and then (a) re-originate the prefix without any signatures towards its non-BGPsec peer and (b) re-originate the prefix including its own signature towards its BGPsec peer. In both cases (i.e., (a) and (b)), the prefix MUST have a ROA in the Global RPKI authorizing the ISP's AS to originate it.
2. ISPとスタブカスタマーは、ローカルRPKIリポジトリを使用できます（[SLURM]で説明されているメカニズムの1つなどのメカニズムを使用）。次に、スタブASによって発信されたプレフィックスのROAがあり、スタブAS内のeBGPスピーカーは、ROAとルーター証明書がローカルでのみ有効であるにもかかわらず、ルーター証明書を持つBGPsecスピーカーになることができます。この配置では、スタブASは、ISPのASにプレフィックスの署名付きUPDATEメッセージを送信します。 ISPのASのエッジBGPsecスピーカーは、ローカルのRPKIビューに基づくRPKIデータを使用して、UPDATEメッセージを検証します。さらに、プレフィックスを非BGPsecおよびBGPsecピアに伝播することを選択できます。その場合、ISPのエッジBGPsecスピーカーは、スタブASから受信したSecure_Pathと署名セグメントをプライベートAS番号で取り除き、（a）署名なしでプレフィックスをその非BGPsecピアに向けて再生成し、（b） -BGPsecピアへの独自の署名を含むプレフィックスを生成します。どちらの場合も（つまり、（a）と（b））、プレフィックスはグローバルRPKIにROAがなければならず、ISPのASがそれを発信することを許可します。
It is possible that private AS numbers are used in an AS confederation [RFC5065]. The BGPsec protocol requires that when a BGPsec UPDATE message propagates through a confederation, each Member-AS that forwards it to a peer Member-AS MUST sign the UPDATE message (see Section 4.3). However, the Global RPKI cannot support private AS numbers. In order for the BGPsec speakers in Member-ASes with private AS numbers to have digital certificates, there MUST be a mechanism in place in the confederation that allows the establishment of a local, customized view of the RPKI, augmenting the Global RPKI repository data as needed. Since this mechanism (for augmenting and maintaining a local image of RPKI data) operates locally within an AS or AS confederation, it need not be standard based. However, a standard-based mechanism can be used (see [SLURM]). Recall that in order to prevent exposure of the internals of AS confederations, a BGPsec speaker exporting to a non-member removes all intra-confederation Secure_Path Segments and Signatures (see Section 4.3).
ASコンフェデレーション[RFC5065]でプライベートAS番号が使用される可能性があります。 BGPsecプロトコルでは、BGPsec UPDATEメッセージが連合を介して伝播する場合、それをピアMember-ASに転送する各Member-ASがUPDATEメッセージに署名する必要があります（セクション4.3を参照）。ただし、グローバルRPKIはプライベートAS番号をサポートできません。プライベートAS番号を持つメンバーASのBGPsecスピーカーがデジタル証明書を持つためには、連合にローカルでカスタマイズされたRPKIのビューを確立し、グローバルRPKIリポジトリデータを拡張できるメカニズムが必要です。必要。このメカニズム（RPKIデータのローカルイメージを拡張および維持するため）は、ASまたはAS連合内でローカルに動作するため、標準ベースである必要はありません。ただし、標準ベースのメカニズムを使用できます（[SLURM]を参照）。 AS連合の内部の露出を防ぐために、非メンバーにエクスポートするBGPsecスピーカーは、連合内のすべてのSecure_Pathセグメントと署名を削除することを思い出してください（セクション4.3を参照）。
The deployment structure, technologies, and best practices concerning Global RPKI data to reach routers (via local RPKI caches) are described in [RFC6810], [RFC8210], [RFC8181], [RFC7115], [RFC8207], and [RFC8182]. For example, Serial-Number-based incremental update mechanisms are used for efficient transfer of just the data records that have changed since the last update [RFC6810] [RFC8210]. The update notification file is used by Relying Parties (RPs) to discover whether any changes exist between the state of the Global RPKI repository and the RP's cache [RFC8182]. The notification describes the location of (1) the files containing the snapshot and (2) incremental deltas, which can be used by the RP to synchronize with the repository. Making use of these technologies and best practices results in enabling robustness, efficiency, and better security for the BGPsec routers and RPKI caches in terms of the flow of RPKI data from repositories to RPKI caches to routers. With these mechanisms, it is believed that an attacker wouldn't be able to meaningfully correlate RPKI data flows with BGPsec RP (or router) actions, thus avoiding attacks that may attempt to determine the set of ASes interacting with an RP via the interactions between the RP and RPKI servers.
（ローカルRPKIキャッシュ経由で）ルーターに到達するためのグローバルRPKIデータに関する展開構造、テクノロジ、およびベストプラクティスは、[RFC6810]、[RFC8210]、[RFC8181]、[RFC7115]、[RFC8207]、および[RFC8182]で説明されています。たとえば、シリアル番号ベースの増分更新メカニズムは、最後の更新[RFC6810] [RFC8210]以降に変更されたデータレコードのみを効率的に転送するために使用されます。更新通知ファイルは、証明書利用者（RP）がグローバルRPKIリポジトリの状態とRPのキャッシュ[RFC8182]の状態との間に変更が存在するかどうかを検出するために使用されます。通知には、（1）スナップショットを含むファイルと（2）RPがリポジトリと同期するために使用できる増分デルタの場所が記述されています。これらのテクノロジーとベストプラクティスを利用することで、BGPsecルーターとRPKIキャッシュの堅牢性、効率性、セキュリティが向上し、リポジトリからRPKIキャッシュ、ルーターへのRPKIデータのフローが向上します。これらのメカニズムでは、攻撃者はRPKIデータフローをBGPsec RP（またはルーター）アクションと有意に相関させることができず、RPと相互作用する一連のASを決定しようとする攻撃を回避できると考えられています。 RPおよびRPKIサーバー。
During Graceful Restart (GR), restarting and receiving BGPsec speakers MUST follow the procedures specified in [RFC4724] for restarting and receiving BGP speakers, respectively. In particular, the behavior of retaining the forwarding state for the routes in the Loc-RIB [RFC4271] and marking them as stale, as well as not differentiating between stale routing information and other information during forwarding, will be the same as the behavior specified in [RFC4724].
グレースフルリスタート（GR）中、BGPsecスピーカーの再起動と受信は、BGPスピーカーの再起動と受信についてそれぞれ[RFC4724]で指定された手順に従う必要があります。特に、Loc-RIB [RFC4271]内のルートの転送状態を保持し、それらを失効としてマークする動作、および転送中に失効したルーティング情報と他の情報を区別しない動作は、指定された動作と同じになります。 [RFC4724]。
The Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 is used for signing UPDATE messages in BGPsec [RFC8208]. For ECDSA, it is stated in Section 6.3 of [FIPS186-4] that a new secret random number "k" shall be generated prior to the generation of each digital signature. A high-entropy random bit generator (RBG) must be used for generating "k", and any potential bias in the "k" generation algorithm must be mitigated (see the methods described in [FIPS186-4] and [SP800-90A]).
曲線P-256を使用した楕円曲線デジタル署名アルゴリズム（ECDSA）は、BGPsec [RFC8208]でのUPDATEメッセージの署名に使用されます。 ECDSAの場合、[FIPS186-4]のセクション6.3に、各デジタル署名の生成前に新しい秘密の乱数「k」が生成されることが記載されています。 「k」の生成には高エントロピーランダムビットジェネレーター（RBG）を使用する必要があり、「k」生成アルゴリズムの潜在的なバイアスを軽減する必要があります（[FIPS186-4]および[SP800-90A]で説明されている方法を参照してください） ）。
What will migration from BGP to BGPsec look like? What are the benefits for the first adopters? Initially, small groups of contiguous ASes would be doing BGPsec. There would possibly be one or more such groups in different geographic regions of the global Internet. Only the routes originated within each group and propagated within its borders would get the benefits of cryptographic AS path protection. As BGPsec adoption grows, each group grows in size, and eventually they join together to form even larger BGPsec-capable groups of contiguous ASes. The benefit for early adopters starts with AS path security within the regions of contiguous ASes spanned by their respective groups. Over time, they would see those regions of contiguous ASes grow much larger.
BGPからBGPsecへの移行はどのようになりますか？最初の採用者にとってのメリットは何ですか？最初は、隣接するASの小さなグループがBGPsecを実行します。グローバルインターネットのさまざまな地理的領域に、このようなグループが1つ以上存在する可能性があります。各グループ内で発信され、その境界内で伝播されたルートだけが、暗号化ASパス保護のメリットを享受します。 BGPsecの採用が拡大するにつれ、各グループのサイズが拡大し、最終的にはそれらが結合して、さらに大きなBGPsec対応の隣接するASのグループを形成します。アーリーアダプターのメリットは、それぞれのグループがまたがる隣接するASの領域内のASパスセキュリティから始まります。時間が経つにつれて、隣接するASのこれらの領域がはるかに大きくなることがわかります。
During partial deployment, if an AS in the path doesn't support BGPsec, then BGP goes back to traditional mode, i.e., BGPsec UPDATE messages are converted to unsigned UPDATE messages before forwarding to that AS (see Section 4.4). At this point, the assurance that the UPDATE message propagated via the sequence of ASes listed is lost. In other words, for the BGPsec routers residing in the ASes starting from the origin AS to the AS before the one not supporting BGPsec, the assurance can still be provided, but not beyond that (for the UPDATE messages in consideration).
部分展開中に、パス内のASがBGPsecをサポートしていない場合、BGPは従来のモードに戻ります。つまり、BGPsec UPDATEメッセージは、そのASに転送する前に、署名されていないUPDATEメッセージに変換されます（セクション4.4を参照）。この時点で、リストされたASのシーケンスを介してUPDATEメッセージが伝搬されたという保証は失われます。つまり、BGPsecをサポートしていないASの前のASからASにあるBGPsecルーターの場合、保証は提供されますが、それを超えることはありません（考慮中のUPDATEメッセージの場合）。
For a discussion of the BGPsec threat model and related security considerations, please see RFC 7132 [RFC7132].
BGPsec脅威モデルおよび関連するセキュリティの考慮事項については、RFC 7132 [RFC7132]を参照してください。
When used in conjunction with origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]), a BGPsec speaker who receives a valid BGPsec UPDATE message containing a route advertisement for a given prefix is provided with the following security guarantees:
オリジン検証と組み合わせて使用すると（RFC 6483 [RFC6483]およびRFC 6811 [RFC6811]を参照）、特定のプレフィックスのルートアドバタイズメントを含む有効なBGPsec UPDATEメッセージを受信するBGPsecスピーカーには、次のセキュリティが保証されます。
o The origin AS number corresponds to an AS that has been authorized, in the RPKI, by the IP address space holder to originate route advertisements for the given prefix.
o 発信元AS番号は、IPアドレススペースホルダーによって、指定されたプレフィックスのルートアドバタイズメントを発信することをRPKIで承認されたASに対応しています。
o For each AS in the path, a BGPsec speaker authorized by the holder of the AS number intentionally chose (in accordance with local policy) to propagate the route advertisement to the subsequent AS in the path.
o パス内の各ASに対して、AS番号の所有者によって承認されたBGPsecスピーカーは、ローカルポリシーに従って意図的に選択し、パス内の後続のASにルートアドバタイズメントを伝達します。
That is, the recipient of a valid BGPsec UPDATE message is assured that the UPDATE message propagated via the sequence of ASes listed in the Secure_Path portion of the BGPsec_PATH attribute. (It should be noted that BGPsec does not offer any guarantee that the data packets would flow along the indicated path; it only guarantees that the BGP UPDATE message conveying the path indeed propagated along the indicated path.) Furthermore, the recipient is assured that this path terminates in an AS that has been authorized by the IP address space holder as a legitimate destination for traffic to the given prefix.
つまり、有効なBGPsec UPDATEメッセージの受信者は、BGPsec_PATH属性のSecure_Path部分にリストされているASのシーケンスを介してUPDATEメッセージが伝播されることが保証されます。 （BGPsecは、データパケットが指定されたパスに沿って流れることを保証するものではないことに注意してください。パスを伝達するBGP UPDATEメッセージが実際に指定されたパスに沿って伝播することを保証するだけです。）さらに、受信者はこれを保証されます。パスは、指定されたプレフィックスへのトラフィックの正当な宛先としてIPアドレススペースホルダーによって承認されたASで終了します。
Note that although BGPsec provides a mechanism for an AS to validate that a received UPDATE message has certain security properties, the use of such a mechanism to influence route selection is completely a matter of local policy. Therefore, a BGPsec speaker can make no assumptions about the validity of a route received from an external (eBGP) BGPsec peer. That is, a compliant BGPsec peer may (depending on the local policy of the peer) send UPDATE messages that fail the validity test in Section 5. Thus, a BGPsec speaker MUST completely validate all BGPsec UPDATE messages received from external peers. (Validation of UPDATE messages received from internal peers is also a matter of local policy; see Section 5.)
BGPsecはASが受信したUPDATEメッセージに特定のセキュリティプロパティがあることを検証するメカニズムを提供しますが、ルート選択に影響を与えるためのそのようなメカニズムの使用はローカルポリシーの問題であることに注意してください。したがって、BGPsecスピーカーは、外部（eBGP）BGPsecピアから受信したルートの有効性について何も想定できません。つまり、準拠するBGPsecピアは、（ピアのローカルポリシーに応じて）セクション5の有効性テストに失敗したUPDATEメッセージを送信できます。したがって、BGPsecスピーカーは、外部ピアから受信したすべてのBGPsec UPDATEメッセージを完全に検証する必要があります。 （内部ピアから受信したUPDATEメッセージの検証もローカルポリシーの問題です。セクション5を参照してください。）
There may be cases where a BGPsec speaker deems 'Valid' (as per the validation algorithm in Section 5.2) a BGPsec UPDATE message that contains both a 'Valid' and a 'Not Valid' Signature_Block. That is, the UPDATE message contains two sets of signatures corresponding to two algorithm suites, and one set of signatures verifies correctly and the other set of signatures fails to verify. In this case, the protocol specifies that a BGPsec speaker choosing to propagate the route advertisement in such an UPDATE message MUST add its signature to each of the Signature_Blocks (see Section 4.2). Thus, the BGPsec speaker creates a signature using both algorithm suites and creates a new UPDATE message that contains both the 'Valid' and the 'Not Valid' set of signatures (from its own vantage point).
BGPsecスピーカーが（セクション5.2の検証アルゴリズムに従って）「有効」と見なす場合があります。「有効」と「無効」の両方のSignature_Blockを含むBGPsec UPDATEメッセージ。つまり、UPDATEメッセージには2つのアルゴリズムスイートに対応する2セットのシグネチャが含まれており、1セットのシグネチャは正しく検証され、もう1セットのシグネチャは検証に失敗します。この場合、プロトコルは、そのようなUPDATEメッセージでルートアドバタイズを伝播することを選択するBGPsecスピーカーがその署名を各Signature_Blocksに追加する必要があることを指定します（セクション4.2を参照）。したがって、BGPsecスピーカーは両方のアルゴリズムスイートを使用して署名を作成し、「有効」と「無効」の両方の署名セット（独自の観点から）を含む新しいUPDATEメッセージを作成します。
To understand the reason for such a design decision, consider the case where the BGPsec speaker receives an UPDATE message with both a set of algorithm A signatures that are 'Valid' and a set of algorithm B signatures that are 'Not Valid'. In such a case, it is possible (perhaps even likely, depending on the state of the algorithm transition) that some of the BGPsec speaker's peers (or other entities further downstream in the BGP topology) do not support algorithm A. Therefore, if the BGPsec speaker were to remove the 'Not Valid' set of signatures corresponding to algorithm B, such entities would treat the message as though it were unsigned. By including the 'Not Valid' set of signatures when propagating a route advertisement, the BGPsec speaker ensures that downstream entities have as much information as possible to make an informed opinion about the validation status of a BGPsec UPDATE message.
このような設計上の決定の理由を理解するために、BGPsecスピーカーが、「有効」なアルゴリズムAシグネチャのセットと「無効」なアルゴリズムBシグネチャのセットの両方を含むUPDATEメッセージを受信する場合を考えてみます。このような場合、一部のBGPsecスピーカーのピア（またはBGPトポロジのさらに下流にある他のエンティティ）がアルゴリズムAをサポートしていない可能性があります（おそらく、アルゴリズムの遷移の状態によっては）。 BGPsecスピーカーは、アルゴリズムBに対応する署名の「無効」セットを削除する必要がありました。そのようなエンティティは、メッセージが署名されていないものとして処理します。 BGPsecスピーカーは、ルートアドバタイズを伝達するときに「無効」のシグネチャセットを含めることで、BGPsec UPDATEメッセージの検証ステータスに関する情報に基づいた意見を行うために、ダウンストリームエンティティにできるだけ多くの情報を提供します。
Note also that during a period of partial BGPsec deployment, a downstream entity might reasonably treat unsigned messages differently from BGPsec UPDATE messages that contain a single set of 'Not Valid' signatures. That is, by removing the set of 'Not Valid' signatures, the BGPsec speaker might actually cause a downstream entity to 'upgrade' the status of a route advertisement from 'Not Valid' to unsigned. Finally, note that in the above scenario, the BGPsec speaker might have deemed algorithm A signatures 'Valid' only because of some issue with the RPKI state local to its AS (for example, its AS might not yet have obtained a Certificate Revocation List (CRL) indicating that a key used to verify an algorithm A signature belongs to a newly revoked certificate). In such a case, it is highly desirable for a downstream entity to treat the UPDATE message as 'Not Valid' (due to the revocation) and not as 'unsigned' (which would happen if the 'Not Valid' Signature_Blocks were removed en route).
また、部分的なBGPsec展開の期間中、ダウンストリームエンティティは、署名されていないメッセージを、 '無効な'署名の単一のセットを含むBGPsec UPDATEメッセージとは異なる方法で適切に処理する場合があります。つまり、「無効」シグネチャのセットを削除することにより、BGPsecスピーカーは実際にダウンストリームエンティティにルートアドバタイズメントのステータスを「無効」から未署名に「アップグレード」させる可能性があります。最後に、上記のシナリオでは、BGPsecスピーカーがアルゴリズムAのシグネチャを「有効」と見なした可能性があることに注意してください。これは、ASにローカルなRPKI状態に関する何らかの問題（たとえば、ASがまだ証明書失効リストを取得していない可能性があるため）（ CRL）は、アルゴリズムを検証するために使用されるキーを示します（署名は新しく取り消された証明書に属します）。そのような場合、ダウンストリームエンティティはUPDATEメッセージを（失効のため）「無効」ではなく「未署名」として扱うことが非常に望ましいです（これは、「無効」Signature_Blocksが途中で削除された場合に発生します）。
A similar argument applies to the case where a BGPsec speaker (for some reason, such as a lack of viable alternatives) selects as its best path (to a given prefix) a route obtained via a 'Not Valid' BGPsec UPDATE message. In such a case, the BGPsec speaker should propagate a signed BGPsec UPDATE message, adding its signature to the 'Not Valid' signatures that already exist. Again, this is to ensure that downstream entities are able to make an informed decision and not erroneously treat the route as unsigned. It should also be noted that due to possible differences in RPKI data observed at different vantage points in the network, a BGPsec UPDATE message deemed 'Not Valid' at an upstream BGPsec speaker may be deemed 'Valid' by another BGP speaker downstream.
BGPsecスピーカー（実行可能な代替の欠如などの何らかの理由で）が（指定されたプレフィックスへの）最適なパスとして、「無効」BGPsec UPDATEメッセージを介して取得したルートを選択する場合にも、同様の議論が当てはまります。このような場合、BGPsecスピーカーは署名済みのBGPsec UPDATEメッセージを伝播し、既存の「無効な」署名に署名を追加する必要があります。繰り返しになりますが、これは、下流のエンティティが情報に基づいた決定を行えるようにし、誤ってルートを署名なしとして処理しないようにするためです。また、ネットワークのさまざまな視点で観測されたRPKIデータの違いにより、上流のBGPsecスピーカーで「無効」と見なされたBGPsec UPDATEメッセージが、下流の別のBGPスピーカーによって「有効」と見なされる場合があることにも注意してください。
Indeed, when a BGPsec speaker signs an outgoing UPDATE message, it is not attesting to a belief that all signatures prior to its own signature are valid. Instead, it is merely asserting that:
実際、BGPsecスピーカーが発信UPDATEメッセージに署名する場合、自身の署名より前のすべての署名が有効であるという信念はありません。代わりに、それは単に次のことを主張しています。
o The BGPsec speaker received the given route advertisement with the indicated prefix, AFI, SAFI, and Secure_Path, and
o BGPsecスピーカーは、指定されたプレフィックス、AFI、SAFI、およびSecure_Pathを使用して、指定されたルートアドバタイズを受信しました。
o The BGPsec speaker chose to propagate an advertisement for this route to the peer (implicitly) indicated by the 'Target AS Number'.
o BGPsecスピーカーは、このルートのアドバタイズを「ターゲットAS番号」で示されるピアに（暗黙的に）伝達することを選択しました。
The BGPsec update validation procedure is a potential target for denial-of-service attacks against a BGPsec speaker. The mitigation of denial-of-service attacks that are specific to the BGPsec protocol is considered here.
BGPsec更新検証手順は、BGPsecスピーカーに対するサービス拒否攻撃の潜在的なターゲットです。ここでは、BGPsecプロトコルに固有のサービス拒否攻撃の緩和について検討します。
To mitigate the effectiveness of such denial-of-service attacks, BGPsec speakers should implement an update validation algorithm that performs expensive checks (e.g., signature verification) after performing checks that are less expensive (e.g., syntax checks). The validation algorithm specified in Section 5.2 was chosen so as to perform checks that are likely to be expensive after checks that are likely to be inexpensive. However, the relative cost of performing required validation steps may vary between implementations, and thus the algorithm specified in Section 5.2 may not provide the best denial-of-service protection for all implementations.
このようなサービス拒否攻撃の有効性を軽減するために、BGPsecスピーカーは、より費用のかからないチェック（例：構文チェック）を実行した後で、費用のかかるチェック（例：署名検証）を実行する更新検証アルゴリズムを実装する必要があります。セクション5.2で指定された検証アルゴリズムは、安価である可能性が高いチェックの後に高額である可能性が高いチェックを実行するために選択されました。ただし、必要な検証手順を実行する相対コストは実装間で異なる可能性があるため、セクション5.2で指定されたアルゴリズムは、すべての実装に対して最良のサービス拒否保護を提供しない場合があります。
Additionally, sending UPDATE messages with very long AS paths (and hence a large number of signatures) is a potential mechanism to conduct denial-of-service attacks. For this reason, it is important that an implementation of the validation algorithm stops attempting to verify signatures as soon as an invalid signature is found. (This ensures that long sequences of invalid signatures cannot be used for denial-of-service attacks.) Furthermore, implementations can mitigate such attacks by only performing validation on UPDATE messages that, if valid, would be selected as the best path. That is, if an UPDATE message contains a route that would lose out in best path selection for other reasons (e.g., a very long AS path), then it is not necessary to determine the BGPsec-validity status of the route.
さらに、非常に長いASパス（したがって多数の署名）を含むUPDATEメッセージを送信することは、サービス拒否攻撃を実行する潜在的なメカニズムです。このため、無効な署名が見つかるとすぐに、検証アルゴリズムの実装が署名の検証を停止することが重要です。 （これにより、無効なシグネチャの長いシーケンスがサービス拒否攻撃に使用されないことが保証されます。）さらに、実装は、有効な場合に最適パスとして選択されるUPDATEメッセージの検証のみを実行することにより、このような攻撃を緩和できます。つまり、UPDATEメッセージに、他の理由（非常に長いASパスなど）のために最適なパスの選択に失敗するルートが含まれている場合、ルートのBGPsec有効性ステータスを判断する必要はありません。
The mechanism of setting the pCount field to 0 is included in this specification to enable route servers in the control path to participate in BGPsec without increasing the length of the AS path. Two other scenarios where pCount=0 is utilized are in the contexts of an AS confederation (see Section 4.3) and of AS migration [RFC8206]. In these two scenarios, pCount=0 is set and also accepted within the same AS (albeit the AS has two different identities). However, entities other than route servers, confederation ASes, or migrating ASes could conceivably use this mechanism (set the pCount to 0) to attract traffic (by reducing the length of the AS path) illegitimately. This risk is largely mitigated if every BGPsec speaker follows the operational guidance in Section 7.2 for configuration for setting pCount=0 and/or accepting pCount=0 from a peer. However, note that a recipient of a BGPsec UPDATE message within which an upstream entity two or more hops away has set pCount to 0 is unable to verify for themselves whether pCount was set to 0 legitimately.
この仕様には、pCountフィールドを0に設定するメカニズムが含まれているため、制御パスのルートサーバーがASパスの長さを増やすことなくBGPsecに参加できます。 pCount = 0が利用される他の2つのシナリオは、AS連合（セクション4.3を参照）とAS移行[RFC8206]のコンテキストにあります。これら2つのシナリオでは、pCount = 0が設定され、同じAS内でも受け入れられます（ASには2つの異なるIDがあります）。ただし、ルートサーバー、コンフェデレーションAS、または移行AS以外のエンティティは、おそらくこのメカニズムを使用して（pCountを0に設定）、（ASパスの長さを短くすることによって）トラフィックを不正に引き寄せることができます。このリスクは、すべてのBGPsecスピーカーがセクション7.2の運用ガイダンスに従って、pCount = 0の設定および/またはピアからのpCount = 0の受け入れの構成に従っている場合、大幅に軽減されます。ただし、2ホップ以上離れた上流エンティティがpCountを0に設定したBGPsec UPDATEメッセージの受信者は、pCountが正当に0に設定されたかどうかを自分で確認できないことに注意してください。
There is a possibility of passing a BGPsec UPDATE message via tunneling between colluding ASes. For example, let's say that AS-X does not peer with AS-Y but colludes with AS-Y, and it signs and sends a BGPsec UPDATE message to AS-Y by tunneling. AS-Y can then further sign and propagate the BGPsec UPDATE message to its peers. It is beyond the scope of the BGPsec protocol to detect this form of malicious behavior. BGPsec is designed to protect messages sent within BGP (i.e., within the control plane) -- not when the control plane is bypassed.
共存するAS間のトンネリングを介してBGPsec UPDATEメッセージを渡す可能性があります。たとえば、AS-XはAS-Yとピアリングせず、AS-Yと共謀し、トンネリングによってBGPsec UPDATEメッセージに署名してAS-Yに送信するとします。 AS-Yはさらに、BGPsec UPDATEメッセージに署名し、ピアに伝播できます。このような悪意のある動作を検出することは、BGPsecプロトコルの範囲を超えています。 BGPsecは、BGP内（つまり、コントロールプレーン内）で送信されたメッセージを保護するように設計されています。コントロールプレーンがバイパスされている場合ではありません。
A variant of the collusion by tunneling mentioned above can happen in the context of AS confederations. When a BGPsec router (outside of a confederation) is forwarding an UPDATE message to a Member-AS in the confederation, it signs the UPDATE message to the public AS number of the confederation and not to the member's AS number (see Section 4.3). The Member-AS can tunnel the signed UPDATE message to another Member-AS as received (i.e., without adding a signature). The UPDATE message can then be propagated using BGPsec to other confederation members or to BGPsec neighbors outside of the confederation. This kind of operation is possible, but no grave security or reachability compromise is feared for the following reasons:
上記のトンネリングによる共謀の変形は、AS連合のコンテキストで発生する可能性があります。 BGPsecルーター（コンフェデレーション外）が、コンフェデレーション内のMember-ASにUPDATEメッセージを転送する場合、コンフェデレーションのパブリックAS番号に署名し、メンバーのAS番号には署名しません（セクション4.3を参照）。 Member-ASは、受信した（つまり、署名を追加せずに）署名済みUPDATEメッセージを別のMember-ASにトンネルできます。その後、UPDATEメッセージは、BGPsecを使用して他のコンフェデレーションメンバーまたはコンフェデレーション外のBGPsecネイバーに伝播できます。この種の操作は可能ですが、次の理由により、重大なセキュリティまたは到達可能性の妥協は恐れられません。
o The confederation members belong to one organization, and strong internal trust is expected.
o コンフェデレーションメンバーは1つの組織に属しており、強い内部信頼が期待されます。
o Recall that the signatures that are internal to the confederation MUST be removed prior to forwarding the UPDATE message to an outside BGPsec router (see Section 4.3).
o コンフェデレーションの内部にある署名は、UPDATEメッセージを外部のBGPsecルーターに転送する前に削除する必要があることを思い出してください（セクション4.3を参照）。
BGPsec does not provide protection against attacks at the transport layer. As with any BGP session, an adversary on the path between a BGPsec speaker and its peer is able to perform attacks such as modifying valid BGPsec UPDATE messages to cause them to fail validation, injecting (unsigned) BGP UPDATE messages without BGPsec_PATH attributes, injecting BGPsec UPDATE messages with BGPsec_PATH attributes that fail validation, or causing the peer to tear down the BGP session. The use of BGPsec does nothing to increase the power of an on-path adversary -- in particular, even an on-path adversary cannot cause a BGPsec speaker to believe that a BGPsec-invalid route is valid. However, as with any BGP session, BGPsec sessions SHOULD be protected by appropriate transport security mechanisms (see the Security Considerations section in [RFC4271]).
BGPsecは、トランスポート層での攻撃に対する保護を提供しません。他のBGPセッションと同様に、BGPsecスピーカーとそのピアの間のパス上の攻撃者は、有効なBGPsec UPDATEメッセージを変更して検証に失敗させる、BGPsec_PATH属性のない（署名されていない）BGP UPDATEメッセージを挿入する、BGPsecを注入するなどの攻撃を実行できます検証に失敗した、またはピアにBGPセッションを破棄させるBGPsec_PATH属性を持つUPDATEメッセージ。 BGPsecを使用しても、パス上の攻撃者の能力を高めることはできません。特に、パス上の攻撃者でさえ、BGPsecスピーカーにBGPsec無効なルートが有効であると信じ込ませることができません。ただし、他のBGPセッションと同様に、BGPsecセッションは適切なトランスポートセキュリティメカニズムによって保護する必要があります（SHOULD）（[RFC4271]のセキュリティに関する考慮事項のセクションを参照）。
There is a possibility of replay attacks, defined as follows. In the context of BGPsec, a replay attack occurs when a malicious BGPsec speaker in the AS path suppresses a prefix withdrawal (implicit or explicit). Further, a replay attack is said to occur also when a malicious BGPsec speaker replays a previously received BGPsec announcement for a prefix that has since been withdrawn. The mitigation strategy for replay attacks involves router certificate rollover; please see [ROLLOVER] for details.
以下のように定義されるリプレイ攻撃の可能性があります。 BGPsecのコンテキストでは、ASパスの悪意のあるBGPsecスピーカーがプレフィックスの取り消し（暗黙的または明示的）を抑制すると、リプレイ攻撃が発生します。さらに、悪意のあるBGPsecスピーカーが以前に受信したBGPsecアナウンスメントを、後で取り消されたプレフィックスに対して再生した場合にも、リプレイ攻撃が発生すると言われています。リプレイ攻撃の緩和戦略には、ルーター証明書のロールオーバーが含まれます。詳細は[ROLLOVER]をご覧ください。
IANA has registered a new BGP capability described in Section 2.1 in the "Capability Codes" registry's "IETF Review" range [RFC8126]. The description for the new capability is "BGPsec Capability". This document is the reference for the new capability.
IANAは、セクション2.1で説明されている新しいBGP機能を「機能コード」レジストリの「IETFレビュー」範囲[RFC8126]に登録しました。新しい機能の説明は「BGPsec機能」です。このドキュメントは、新しい機能のリファレンスです。
IANA has also registered a new path attribute described in Section 3 in the "BGP Path Attributes" registry. The code for this new attribute is "BGPsec_PATH". This document is the reference for the new attribute.
IANAは、「BGPパス属性」レジストリのセクション3で説明されている新しいパス属性も登録しました。この新しい属性のコードは「BGPsec_PATH」です。このドキュメントは、新しい属性のリファレンスです。
IANA has defined the "BGPsec Capability" registry in the "Resource Public Key Infrastructure (RPKI)" group. The registry is as shown in Figure 10, with values assigned from Section 2.1:
IANAは、「Resource Public Key Infrastructure（RPKI）」グループに「BGPsec Capability」レジストリを定義しています。レジストリは図10に示すとおりであり、値はセクション2.1から割り当てられています。
+------+------------------------------------+------------+
| Bits | Field | Reference |
+------+------------------------------------+------------+
| 0-3 | Version | [RFC8205] |
| | Value = 0x0 | |
+------+------------------------------------+------------+
| 4 | Direction | [RFC8205] |
| |(Both possible values 0 and 1 are | |
| | fully specified by this RFC) | |
+------+------------------------------------+------------+
| 5-7 | Unassigned | [RFC8205] |
| | Value = 000 (in binary) | |
+------+------------------------------------+------------+
Figure 10: IANA Registry for BGPsec Capability
図10：BGPsec機能のIANAレジストリ
The Direction bit (fourth bit) has a value of either 0 or 1, and both values are fully specified by this document. Future Version values and future values of the Unassigned bits are assigned using the "Standards Action" registration procedures defined in RFC 8126 [RFC8126].
方向ビット（4番目のビット）の値は0または1で、両方の値はこのドキュメントで完全に指定されています。未割り当てビットの将来のバージョン値と将来の値は、RFC 8126 [RFC8126]で定義されている「標準アクション」登録手順を使用して割り当てられます。
IANA has defined the "BGPsec_PATH Flags" registry in the "Resource Public Key Infrastructure (RPKI)" group. The registry is as shown in Figure 11, with one value assigned from Section 3.1:
IANAは、「Resource Public Key Infrastructure（RPKI）」グループに「BGPsec_PATH Flags」レジストリを定義しています。レジストリは図11に示すとおりであり、セクション3.1から1つの値が割り当てられています。
+------+-------------------------------------------+------------+
| Flag | Description | Reference |
+------+-------------------------------------------+------------+
| 0 | Confed_Segment | [RFC8205] |
| | Bit value = 1 means Flag set | |
| | (indicates Confed_Segment) | |
| | Bit value = 0 is default | |
+------+-------------------------------------------+------------+
| 1-7 | Unassigned | [RFC8205] |
| | Value: All 7 bits set to zero | |
+------+-------------------------------------------+------------+
Figure 11: IANA Registry for BGPsec_PATH Flags Field
図11：BGPsec_PATHフラグフィールドのIANAレジストリ
Future values of the Unassigned bits are assigned using the "Standards Action" registration procedures defined in RFC 8126 [RFC8126].
未割り当てビットの将来の値は、RFC 8126 [RFC8126]で定義されている「標準アクション」登録手順を使用して割り当てられます。
[IANA-AF] IANA, "Address Family Numbers", <https://www.iana.org/assignments/address-family-numbers>.
[IANA-AF] IANA、「アドレスファミリー番号」、<https://www.iana.org/assignments/address-family-numbers>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、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>。
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>.
[RFC5065] Traina、P.、McPherson、D。、およびJ. Scudder、「BGPの自律システム連合」、RFC 5065、DOI 10.17487 / RFC5065、2007年8月、<https://www.rfc-editor.org/ info / rfc5065>。
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC5492] Scudder、J。およびR. Chandra、「BGP-4を使用した機能のアドバタイズ」、RFC 5492、DOI 10.17487 / RFC5492、2009年2月、<https://www.rfc-editor.org/info/rfc5492>。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「A Route for Route Origin Authorizations（ROAs）」、RFC 6482、DOI 10.17487 / RFC6482、2012年2月、<https：//www.rfc- editor.org/info/rfc6482>。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、DOI 10.17487 / RFC6487、2012年2月、<https：//www.rfc- editor.org/info/rfc6487>。
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-editor.org/info/rfc6793>.
[RFC6793] Vohra、Q.、E。Chen、「BGP Support for Four-Octet Autonomous System（AS）Number Space」、RFC 6793、DOI 10.17487 / RFC6793、2012年12月、<https：//www.rfc-editor。 org / info / rfc6793>。
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.
[RFC7606] Chen、E。、編、Scudder、J。、編、Mohapatra、P。、およびK. Patel、「BGP UPDATEメッセージのエラー処理の改訂版」、RFC 7606、DOI 10.17487 / RFC7606、2015年8月、 <https://www.rfc-editor.org/info/rfc7606>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>.
[RFC8208]ターナー、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] Reynolds、M.、Turner、S。、およびS. Kent、「BGPsecルーター証明書、証明書失効リスト、および認証要求のプロファイル」、RFC 8209、DOI 10.17487 / RFC8209、2017年9月、<https：/ /www.rfc-editor.org/info/rfc8209>。
[Borchert] Borchert, O. and M. Baer, "Subject: Modification request: draft-ietf-sidr-bgpsec-protocol-14", message to the IETF SIDR WG Mailing List, 10 February 2016, <https://mailarchive.ietf.org/arch/msg/ sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5Mu>.
[Borchert] Borchert、O。およびM. Baer、「件名：変更リクエスト：draft-ietf-sidr-bgpsec-protocol-14」、IETF SIDR WGメーリングリストへのメッセージ、2016年2月10日、<https：// mailarchive .ietf.org / arch / msg / sidr / 8B_e4CNxQCUKeZ_AUzsdnn2f5Mu>。
[FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", NIST FIPS Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS186-4]米国国立標準技術研究所、「デジタル署名標準（DSS）」、NIST FIPS Publication 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<http：//nvlpubs.nist .gov / nistpubs / FIPS / NIST.FIPS.186-4.pdf>。
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, DOI 10.17487/RFC6472, December 2011, <https://www.rfc-editor.org/info/rfc6472>.
[RFC6472] Kumari、W。およびK. Sriram、「BGPでAS_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、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<https://www.rfc-editor.org/info/rfc6480> 。
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, <https://www.rfc-editor.org/info/rfc6483>.
[RFC6483] Huston、G.およびG. Michaelson、「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>。
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.
[RFC6810] Bush、R。およびR. Austein、「The Resource Public Key Infrastructure（RPKI）to Router Protocol」、RFC 6810、DOI 10.17487 / RFC6810、2013年1月、<https://www.rfc-editor.org/ info / rfc6810>。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R。、およびR. Austein、「BGP Prefix Origin Validation」、RFC 6811、DOI 10.17487 / RFC6811、2013年1月、<https：/ /www.rfc-editor.org/info/rfc6811>。
[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods for Generating Key Identifiers Values", RFC 7093, DOI 10.17487/RFC7093, December 2013, <https://www.rfc-editor.org/info/rfc7093>.
[RFC7093]ターナー、S。、ケント、S。、およびJ.マンガー、「キー識別子の値を生成するための追加の方法」、RFC 7093、DOI 10.17487 / RFC7093、2013年12月、<https：//www.rfc-editor。 org / info / rfc7093>。
[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, <https://www.rfc-editor.org/info/rfc7115>.
[RFC7115]ブッシュR.、「リソース公開鍵基盤（RPKI）に基づく元の検証操作」、BCP 185、RFC 7115、DOI 10.17487 / RFC7115、2014年1月、<https://www.rfc-editor.org / info / rfc7115>。
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, <https://www.rfc-editor.org/info/rfc7132>.
[RFC7132] Kent、S。およびA. Chi、「BGPパスセキュリティの脅威モデル」、RFC 7132、DOI 10.17487 / RFC7132、2014年2月、<https://www.rfc-editor.org/info/rfc7132>。
[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", July 2017, <https://www.rfc-editor.org/info/rfc8181>.
[RFC8181] Weiler、S.、Sonalker、A。、およびR. Austein、「A Resource Protocol for the Resource Public Key Infrastructure（RPKI）」、2017年7月、<https://www.rfc-editor.org/info / rfc8181>。
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <https://www.rfc-editor.org/info/rfc8182>.
[RFC8182] Bruijnzeels、T.、Muravskiy、O.、Weber、B。、およびR. Austein、「The RPKI Repository Delta Protocol（RRDP）」、RFC 8182、DOI 10.17487 / RFC8182、2017年7月、<https：// www.rfc-editor.org/info/rfc8182>。
[RFC8206] George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, September 2017, <https://www.rfc-editor.org/info/rfc8206>.
[RFC8206]ジョージ、W、およびS.マーフィー、「自律システム（AS）移行に関するBGPsecの考慮事項」、RFC 8206、DOI 10.17487 / RFC8206、2017年9月、<https://www.rfc-editor.org/info/ rfc8206>。
[RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211, RFC 8207, DOI 10.17487/RFC8207, September 2017, <https://www.rfc-editor.org/info/rfc8207>.
[RFC8207] Bush、R。、「BGPsec Operational Considerations」、BCP 211、RFC 8207、DOI 10.17487 / RFC8207、2017年9月、<https://www.rfc-editor.org/info/rfc8207>。
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/info/rfc8210>.
[RFC8210] Bush、R。およびR. Austein、「The Resource Public Key Infrastructure（RPKI）to Router Protocol、Version 1」、RFC 8210、DOI 10.17487 / RFC8210、2017年9月、<https：//www.rfc-editor .org / info / rfc8210>。
[ROLLOVER] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", Work in Progress, draft-ietf-sidrops-bgpsec-rollover-01, August 2017.
[ロールオーバー] Weis、B.、Gagliano、R。、およびK. Patel、「BGPsecルーター証明書のロールオーバー」、作業中、draft-ietf-sidrops-bgpsec-rollover-01、2017年8月。
[SLURM] Mandelberg, D., Ma, D., and T. Bruijnzeels, "Simplified Local internet nUmber Resource Management with the RPKI", Work in Progress, draft-ietf-sidr-slurm-04, March 2017.
[SLURM] Mandelberg、D.、Ma、D。、およびT. Bruijnzeels、「RPKIを使用した簡素化されたローカルインターネットナンバーリソース管理」、進行中の作業、draft-ietf-sidr-slurm-04、2017年3月。
[SP800-90A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST SP 800-90A Rev 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-90Ar1.pdf>.
[SP800-90A]米国国立標準技術研究所、「確定的ランダムビットジェネレータを使用した乱数生成の推奨」、NIST SP 800-90A Rev 1、DOI 10.6028 / NIST.SP.800-90Ar1、2015年6月、<http： //nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-90Ar1.pdf>。
Acknowledgements
謝辞
The authors would like to thank Michael Baer, Oliver Borchert, David Mandelberg, Mehmet Adalier, Sean Turner, Wes George, Jeff Haas, Alvaro Retana, Nevil Brownlee, Matthias Waehlisch, Tim Polk, Russ Mundy, Wes Hardaker, Sharon Goldberg, Ed Kern, Doug Maughan, Pradosh Mohapatra, Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger Volk, and David Ward for their review, comments, and suggestions during the course of this work. Thanks are also due to many IESG reviewers whose comments greatly helped improve the clarity, accuracy, and presentation in the document.
著者は、マイケル・ベア、オリバー・ボーチャート、デビッド・マンデルバーグ、メフメット・アダリエ、ショーン・ターナー、ウェス・ジョージ、ジェフ・ハース、アルバロ・レターナ、ネビル・ブラウンリー、マティアス・ウェーリッシュ、ティム・ポーク、ラス・マンディ、ウェス・ハーダーカー、シャロン・ゴールドバーグ、エド・カーンに感謝します、Doug Maughan、Pradosh Mohapatra、Mark Reynolds、Heather Schiller、Jason Schiller、Ruediger Volk、およびDavid Wardのレビュー、コメント、およびこの作業の過程での提案。また、多くのIESGレビューアのコメントに感謝します。そのコメントは、ドキュメントの明確性、正確性、およびプレゼンテーションを大幅に改善するのに役立ちました。
The authors particularly wish to acknowledge Oliver Borchert and Michael Baer for their review and suggestions [Borchert] concerning the sequence of octets to be hashed (Figures 8 and 9 in Sections 4.2 and 5.2, respectively). This was an important contribution based on their implementation experience.
著者は特に、ハッシュされるオクテットのシーケンスに関するレビューと提案[Borchert]（セクション4.2と5.2の図8と9）について、Oliver BorchertとMichael Baerに感謝します。これは、実装の経験に基づく重要な貢献でした。
Contributors
貢献者
The following people have made significant contributions to this document and should be considered co-authors:
次の人々はこのドキュメントに重要な貢献をしており、共著者と見なされるべきです：
Rob Austein Dragon Research Labs Email: sra@hactrn.net
Rob Austein Dragon Research Labsメール：sra@hactrn.net
Steven Bellovin Columbia University Email: smb@cs.columbia.edu
スティーブンベロビンコロンビア大学Eメール：smb@cs.columbia.edu
Russ Housley Vigil Security Email: housley@vigilsec.com
Russ Housley Vigilセキュリティメール：housley@vigilsec.com
Stephen Kent BBN Technologies Email: kent@alum.mit.edu
Stephan Kent Buban Technologiesメール：Kent@Elum.mit.edu
Warren Kumari Google Email: warren@kumari.net
Warren Kumari Googleメール：warren@kumari.net
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 SPARTA, Inc., a Parsons Company Email: sandy@tislabs.com
パーソンズの会社、サンディマーフィーSPARTA、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
Authors' Addresses
著者のアドレス
Matthew Lepinski (editor) New College of Florida 5800 Bay Shore Road Sarasota, FL 34243 United States of America
マシューレピンスキー（編集者）ニューカレッジオブフロリダ5800ベイショアロードサラソタ、FL 34243アメリカ合衆国
Email: mlepinski@ncf.edu
Kotikalapudi Sriram (editor) USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899 United States of America
Kotikalapudi Sriram（編集者）米国国立標準技術研究所100 Bureau Driveゲーサーズバーグ、MD 20899アメリカ合衆国
Email: kotikalapudi.sriram@nist.gov