[要約] RFC 8608は、BGPsecアルゴリズム、キーフォーマット、および署名フォーマットに関する情報を提供します。このRFCの目的は、BGPセキュリティ拡張の実装と展開を支援することです。
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 8608 sn3rd
Obsoletes: 8208 O. Borchert
Updates: 7935 NIST
Category: Standards Track June 2019
ISSN: 2070-1721
BGPsec Algorithms, Key Formats, and Signature Formats
BGPsecアルゴリズム、キー形式、および署名形式
Abstract
概要
This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.
このドキュメントでは、BGPsec（ボーダーゲートウェイプロトコルセキュリティ）で使用されるアルゴリズム、アルゴリズムパラメーター、非対称キー形式、非対称キーサイズ、および署名形式を指定します。このドキュメントは、RFC 7935（「リソースの公開鍵インフラストラクチャで使用するアルゴリズムとキーサイズのプロファイル」）を更新し、ドキュメントと実験アルゴリズムIDを追加して修正することにより、RFC 8208（「BGPsecアルゴリズム、キー形式、および署名形式」）を廃止します。割り当てられていないアルゴリズムIDの範囲で全範囲を埋め、ドキュメントを再構成して読みやすくします。
This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.
このドキュメントには、BGPsec UPDATEメッセージの例、メッセージの生成に使用される秘密鍵、およびそれらの署名の検証に必要な証明書も含まれています。
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/rfc8608.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8608で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes from RFC 8208 . . . . . . . . . . . . . . . . . . 4
2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Algorithm ID Types . . . . . . . . . . . . . . . . . . . 4
2.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 6
2.2.1. Algorithm ID 0x01 (1) - (ECDSA P-256) . . . . . . . . 6
3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . 6
3.1. Asymmetric Key Pair for Algorithm ID 0x01 (1) - (ECDSA
P-256) . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Public Key Format . . . . . . . . . . . . . . . . . . 6
3.1.2. Private Key Format . . . . . . . . . . . . . . . . . 7
4. Signature Formats . . . . . . . . . . . . . . . . . . . . . . 7
5. Additional Requirements . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
A.1. Topology and Experiment Description . . . . . . . . . . . 12
A.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.3. BGPsec IPv4 . . . . . . . . . . . . . . . . . . . . . . . 16
A.4. BGPsec IPv6 . . . . . . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
This document specifies the following:
このドキュメントでは、次のことを指定しています。
o the digital signature algorithm and parameters,
o デジタル署名アルゴリズムとパラメーター
o the hash algorithm and parameters,
o ハッシュアルゴリズムとパラメーター
o the algorithm identifier assignment and classification,
o アルゴリズム識別子の割り当てと分類
o the public and private key formats, and
o 公開鍵と秘密鍵のフォーマット、および
o the signature formats
o 署名フォーマット
used by Resource Public Key Infrastructure (RPKI) Certification Authorities (CAs) and BGPsec (Border Gateway Protocol Security) speakers (i.e., routers). CAs use these algorithms when processing requests for BGPsec Router Certificates [RFC8209]. Examples of when BGPsec routers use these algorithms include requesting BGPsec certificates [RFC8209], signing BGPsec UPDATE messages [RFC8205], and verifying signatures on BGPsec UPDATE messages [RFC8205].
リソースパブリックキーインフラストラクチャ（RPKI）証明機関（CA）とBGPsec（ボーダーゲートウェイプロトコルセキュリティ）スピーカー（ルーターなど）で使用されます。 CAは、BGPsecルーター証明書のリクエストを処理するときにこれらのアルゴリズムを使用します[RFC8209]。 BGPsecルーターがこれらのアルゴリズムを使用する例には、BGPsec証明書の要求[RFC8209]、BGPsec UPDATEメッセージへの署名[RFC8205]、およびBGPsec UPDATEメッセージの署名の検証[RFC8205]が含まれます。
This document updates [RFC7935] to add support for a) a different algorithm for BGPsec certificate requests, which are issued only by BGPsec speakers; b) a different Subject Public Key Info format for BGPsec certificates, which is needed for the specified BGPsec signature algorithm; and c) different signature formats for BGPsec signatures, which are needed for the specified BGPsec signature algorithm. The BGPsec certificates are differentiated from other RPKI certificates by the use of the BGPsec Extended Key Usage as defined in [RFC8209]. BGPsec uses a different algorithm [RFC6090] [DSS] from the rest of the RPKI to provide similar security with smaller keys, making the certificates smaller; these algorithms also result in smaller signatures, which make the PDUs smaller.
このドキュメントは、[RFC7935]を更新して、次のサポートを追加します。a）BGPsec証明書要求の異なるアルゴリズム。BGPsecスピーカーのみが発行します。 b）指定されたBGPsec署名アルゴリズムに必要なBGPsec証明書の別のサブジェクト公開鍵情報形式。 c）BGPsec署名のさまざまな署名形式。指定されたBGPsec署名アルゴリズムに必要です。 BGPsec証明書は、[RFC8209]で定義されているBGPsec拡張キー使用法を使用することにより、他のRPKI証明書と区別されます。 BGPsecは、残りのRPKIとは異なるアルゴリズム[RFC6090] [DSS]を使用して、より小さいキーで同様のセキュリティを提供し、証明書を小さくします。これらのアルゴリズムにより、署名が小さくなり、PDUが小さくなります。
Appendix A (non-normative) contains example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate the signatures.
付録A（非規範的）には、BGPsec UPDATEメッセージの例と、メッセージの生成に使用される秘密鍵、および署名の検証に必要な証明書が含まれています。
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 section describes the significant changes between [RFC8208] and this document.
このセクションでは、[RFC8208]とこのドキュメントの間の重要な変更点について説明します。
o Added Section 2.1 containing Algorithm ID types. Also, the interpretation of these IDs is described.
o アルゴリズムIDタイプを含むセクション2.1を追加。また、これらのIDの解釈についても説明します。
o Restructured Sections 2 and 3 to align with the corresponding algorithm suite identifier value.
o セクション2および3を再構成して、対応するアルゴリズムスイート識別子の値に合わせます。
o Corrected the range for unassigned algorithm suite identifier values.
o 割り当てられていないアルゴリズムスイート識別子の値の範囲を修正しました。
o Added Documentation algorithm suite identifier values.
o ドキュメントアルゴリズムスイートの識別子の値を追加しました。
o Added Experimentation algorithm suite identifier values.
o 実験アルゴリズムスイートの識別子の値が追加されました。
o Changed the next-hop IP in Appendix A's IPv6 example to use a private usage IPv6 address.
o 付録AのIPv6の例のネクストホップIPを、プライベート使用のIPv6アドレスを使用するように変更しました。
The algorithms used to compute signatures on CA certificates, BGPsec Router Certificates, and Certificate Revocation Lists (CRLs) are as specified in Section 2 of [RFC7935]. This section addresses algorithms used by BGPsec [RFC8205] [DSS]. For example, these algorithms are used by BGPsec routers to sign and verify BGPsec UPDATE messages. To identify which algorithm is used, the BGPsec UPDATE message contains the corresponding algorithm ID in each Signature_Block of the BGPsec UPDATE message.
CA証明書、BGPsecルーター証明書、および証明書失効リスト（CRL）の署名を計算するために使用されるアルゴリズムは、[RFC7935]のセクション2で指定されているとおりです。このセクションでは、BGPsec [RFC8205] [DSS]で使用されるアルゴリズムについて説明します。たとえば、これらのアルゴリズムは、BGPsecルーターがBGPsec UPDATEメッセージに署名して検証するために使用されます。使用されているアルゴリズムを識別するために、BGPsec UPDATEメッセージには、BGPsec UPDATEメッセージの各Signature_Blockに対応するアルゴリズムIDが含まれています。
Algorithms in BGPsec UPDATE messages are identified by the Algorithm Suite Identifier field (algorithm ID) within the Signature_Block (see Section 3.2 of [RFC8205]).
BGPsec UPDATEメッセージのアルゴリズムは、Signature_Block内のAlgorithm Suite Identifierフィールド（アルゴリズムID）によって識別されます（[RFC8205]のセクション3.2を参照）。
This document specifies five types of Algorithm IDs:
このドキュメントでは、5種類のアルゴリズムIDを指定しています。
o Reserved Algorithm ID
o 予約済みアルゴリズムID
Reserved algorithm IDs are the values 0x00 (0) and 0xFF (255). These IDs MUST NOT be used in a Signature_Block, and if encountered, the router MUST treat BGPsec UPDATE messages as malformed [RFC4271].
予約済みのアルゴリズムIDは、値0x00（0）および0xFF（255）です。これらのIDはSignature_Blockで使用してはならず（MUST NOT）、検出された場合、ルーターはBGPsec UPDATEメッセージを不正な形式として処理する必要があります[RFC4271]。
o Signature Algorithm ID
o 署名アルゴリズムID
Signature algorithms are defined in Section 2.2 of this document. Processing of BGPsec UPDATE signing and validation using signature algorithms is described at length in Sections 4.2 and 5.2 of [RFC8205].
署名アルゴリズムは、このドキュメントのセクション2.2で定義されています。署名アルゴリズムを使用したBGPsec UPDATE署名および検証の処理については、[RFC8205]のセクション4.2および5.2で詳しく説明しています。
o Unassigned Algorithm ID
o 割り当てられていないアルゴリズムID
This type of Algorithm ID is free for future assignments and MUST NOT be used until an algorithm is officially assigned (see Section 7). In case a router encounters an unassigned algorithm ID in one of the Signature_Blocks of a BGPsec UPDATE message, the router SHOULD process the Signature_Block as an unsupported algorithm as specified in Section 5.2 of [RFC8205].
このタイプのアルゴリズムIDは将来の割り当てのために無料であり、アルゴリズムが正式に割り当てられるまで使用しないでください（セクション7を参照）。ルータがBGPsec UPDATEメッセージのSignature_Blocksの1つで割り当てられていないアルゴリズムIDを検出した場合、ルータは[RFC8205]のセクション5.2で指定されているように、Signature_Blockをサポートされていないアルゴリズムとして処理する必要があります（SHOULD）。
o Experimentation Algorithm ID
o 実験アルゴリズムID
Experimentation algorithm IDs span from 0xF7 (247) to 0xFA (250). To allow experimentation to accurately describe deployment examples, the use of publicly assigned algorithm IDs is inappropriate, and a reserved block of Experimentation algorithm IDs is required. This ensures that experimentation does not clash with assigned algorithm IDs in deployed networks and mitigates the risks to operational integrity of the network through inappropriate use of experimentation to perform literal configuration of routing elements on production systems. A router that encounters an algorithm ID of this type outside of an experimental network SHOULD treat it the same as an unsupported algorithm as specified in Section 5.2 of [RFC8205].
実験アルゴリズムIDの範囲は0xF7（247）〜0xFA（250）です。実験で導入例を正確に説明できるようにするには、公開で割り当てられたアルゴリズムIDの使用は不適切であり、実験アルゴリズムIDの予約ブロックが必要です。これにより、デプロイされたネットワークで割り当てられたアルゴリズムIDと実験が衝突することがなくなり、本番システムでルーティング要素のリテラル構成を実行する実験を不適切に使用することにより、ネットワークの運用の完全性に対するリスクが軽減されます。試験運用ネットワーク外でこのタイプのアルゴリズムIDに遭遇したルーターは、[RFC8205]のセクション5.2で指定されているサポートされていないアルゴリズムと同じように扱う必要があります（SHOULD）。
o Documentation Algorithm ID
o ドキュメントアルゴリズムID
Documentation algorithm IDs span from 0xFB (251) to 0xFE (254). To allow documentation to accurately describe deployment examples, the use of publicly assigned algorithm IDs is inappropriate, and a reserved block of Documentation algorithm IDs is required. This ensures that documentation does not clash with assigned algorithm IDs in deployed networks and mitigates the risks to operational integrity of the network through inappropriate use of documentation to perform literal configuration of routing elements on production systems. A router that encounters an algorithm ID of this type SHOULD treat it the same as an unsupported algorithm as specified in Section 5.2 of [RFC8205].
ドキュメントアルゴリズムIDの範囲は0xFB（251）から0xFE（254）です。ドキュメントで展開例を正確に説明できるようにするには、公開で割り当てられたアルゴリズムIDの使用は不適切であり、ドキュメントアルゴリズムIDの予約ブロックが必要です。これにより、展開されたネットワークで割り当てられたアルゴリズムIDとドキュメントが衝突することがなくなり、ドキュメントを不適切に使用して実稼働システムでルーティング要素のリテラル構成を実行することにより、ネットワークの運用上の整合性に対するリスクが軽減されます。このタイプのアルゴリズムIDを検出したルーターは、[RFC8205]のセクション5.2で指定されているサポートされていないアルゴリズムと同じように扱う必要があります（SHOULD）。
o The signature algorithm used MUST be the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS].
o 使用される署名アルゴリズムは、曲線P-256 [RFC6090] [DSS]を伴う楕円曲線デジタル署名アルゴリズム（ECDSA）でなければなりません。
o The hash algorithm used MUST be SHA-256 [SHS].
o 使用されるハッシュアルゴリズムはSHA-256 [SHS]である必要があります。
Hash algorithms are not identified by themselves in certificates or BGPsec UPDATE messages. They are represented by an OID that combines the hash algorithm with the digital signature algorithm as follows:
ハッシュアルゴリズムは、証明書またはBGPsec UPDATEメッセージではそれ自体では識別されません。これらは、次のようにハッシュアルゴリズムとデジタル署名アルゴリズムを組み合わせたOIDで表されます。
o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the Public-Key Cryptography Standards #10 (PKCS #10) signatureAlgorithm field [RFC2986] or in the Certificate Request Message Format (CRMF) POPOSigningKey algorithm field [RFC4211]; where the OID is placed depends on the certificate request format generated.
o ecdsa-with-SHA256 OID [RFC5480]は、Public-Key Cryptography Standards＃10（PKCS＃10）signatureAlgorithmフィールド[RFC2986]またはCertificate Request Message Format（CRMF）POPOSigningKeyアルゴリズムフィールド[RFC4211]に表示する必要があります。 OIDが配置される場所は、生成される証明書要求フォーマットによって異なります。
o In BGPsec UPDATE messages, the ECDSA with SHA-256 algorithm suite identifier value 0x01 (1) (see Section 7) is included in the Signature_Block List's Algorithm Suite Identifier field.
o BGPsec UPDATEメッセージでは、SHA-256アルゴリズムスイート識別子値0x01（1）（セクション7を参照）を含むECDSAが、Signature_Blockリストのアルゴリズムスイート識別子フィールドに含まれています。
The key formats used to compute signatures on CA certificates, BGPsec Router Certificates, and CRLs are as specified in Section 3 of [RFC7935]. This section addresses key formats found in the BGPsec Router Certificate requests and in BGPsec Router Certificates.
CA証明書、BGPsecルーター証明書、およびCRLの署名の計算に使用される主要な形式は、[RFC7935]のセクション3で指定されています。このセクションでは、BGPsecルーター証明書リクエストとBGPsecルーター証明書にある主要な形式について説明します。
The ECDSA private keys used to compute signatures for certificate requests and BGPsec UPDATE messages MUST be associated with the P-256 elliptic curve domain parameters [RFC5480]. The public key pair MUST use the uncompressed form.
証明書要求およびBGPsec UPDATEメッセージの署名を計算するために使用されるECDSA秘密鍵は、P-256楕円曲線ドメインパラメータ[RFC5480]に関連付けられている必要があります。公開鍵ペアは、非圧縮形式を使用する必要があります。
The Subject's public key is included in subjectPublicKeyInfo [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. The values for the structures and their sub-structures follow:
サブジェクトの公開鍵は、subjectPublicKeyInfo [RFC5280]に含まれています。アルゴリズムとsubjectPublicKeyの2つのサブフィールドがあります。構造とそのサブ構造の値は次のとおりです。
o algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID MUST be used in the algorithm field, as specified in Section 2.1.1 of [RFC5480]. The value for the associated parameters MUST be secp256r1, as specified in Section 2.1.1.1 of [RFC5480].
o アルゴリズム（AlgorithmIdentifierタイプ）：[RFC5480]のセクション2.1.1で指定されているように、アルゴリズムフィールドではid-ecPublicKey OIDを使用する必要があります。 [RFC5480]のセクション2.1.1.1で指定されているように、関連するパラメータの値はsecp256r1である必要があります。
o subjectPublicKey: ECPoint MUST be used to encode the certificate's subjectPublicKey field, as specified in Section 2.2 of [RFC5480].
o subjectPublicKey：[RFC5480]のセクション2.2で指定されているように、ECPointを使用して証明書のsubjectPublicKeyフィールドをエンコードする必要があります。
Local policy determines private key format.
ローカルポリシーは秘密鍵の形式を決定します。
The structure for the certificate's and CRL's signature field MUST be as specified in Section 4 of [RFC7935]; this is the same format used by other RPKI certificates. The structure for the certification request's and BGPsec UPDATE message's signature field MUST be as specified in Section 2.2.3 of [RFC3279].
証明書とCRLの署名フィールドの構造は、[RFC7935]のセクション4で指定されているとおりでなければなりません。これは、他のRPKI証明書で使用される形式と同じです。認証要求およびBGPsec UPDATEメッセージの署名フィールドの構造は、[RFC3279]のセクション2.2.3で指定されているとおりである必要があります。
It is anticipated that BGPsec will require the adoption of updated key sizes and a different set of signature and hash algorithms over time, in order to maintain an acceptable level of cryptographic security. This profile should be updated to specify such future requirements, when appropriate.
許容可能なレベルの暗号化セキュリティを維持するために、BGPsecでは、更新されたキーサイズと、異なる一連の署名およびハッシュアルゴリズムを徐々に採用することが予想されます。このプロファイルは、必要に応じて、このような将来の要件を指定するように更新する必要があります。
The recommended procedures to implement such a transition of key sizes and algorithms are specified in [RFC6916].
鍵サイズとアルゴリズムのそのような移行を実装するための推奨手順は、[RFC6916]で指定されています。
The security considerations of [RFC3279], [RFC5480], [RFC6090], [RFC7935], and [RFC8209] apply to certificates. The security considerations of [RFC3279], [RFC6090], [RFC7935], and [RFC8209] apply to certification requests. The security considerations of [RFC3279], [RFC6090], and [RFC8205] apply to BGPsec UPDATE messages. No new security considerations are introduced as a result of this specification.
[RFC3279]、[RFC5480]、[RFC6090]、[RFC7935]、および[RFC8209]のセキュリティに関する考慮事項が証明書に適用されます。 [RFC3279]、[RFC6090]、[RFC7935]、および[RFC8209]のセキュリティに関する考慮事項は、認証要求に適用されます。 [RFC3279]、[RFC6090]、および[RFC8205]のセキュリティに関する考慮事項は、BGPsec UPDATEメッセージに適用されます。この仕様の結果として、新しいセキュリティの考慮事項は導入されていません。
The Internet Assigned Numbers Authority (IANA) has created the "BGPsec Algorithm Suites" registry in the Resource Public Key Infrastructure (RPKI) group. The one-octet algorithm suite identifiers assigned by IANA identify the digest algorithm and signature algorithm used in the BGPsec Signature_Block List's Algorithm Suite Identifier field.
Internet Assigned Numbers Authority（IANA）は、Resource Public Key Infrastructure（RPKI）グループに「BGPsec Algorithm Suites」レジストリを作成しました。 IANAによって割り当てられた1オクテットのアルゴリズムスイート識別子は、BGPsec Signature_Block ListのAlgorithm Suite Identifierフィールドで使用されるダイジェストアルゴリズムと署名アルゴリズムを識別します。
Per [RFC8208], IANA registered a single algorithm suite identifier for the digest algorithm SHA-256 [SHS] and for the signature algorithm ECDSA on the P-256 curve [RFC6090] [DSS]. This identifier
[RFC8208]に従い、IANAはダイジェストアルゴリズムSHA-256 [SHS]とP-256曲線の署名アルゴリズムECDSA [RFC6090] [DSS]に対して単一のアルゴリズムスイート識別子を登録しました。この識別子
is still valid, and IANA has updated the registration to refer to this document.
はまだ有効であり、IANAはこのドキュメントを参照するように登録を更新しました。
IANA has modified the range of the "Unassigned" address space from "0x2-0xEF" to "0x02-0xF6":
IANAは、「未割り当て」アドレススペースの範囲を「0x2-0xEF」から「0x02-0xF6」に変更しました。
Algorithm Digest Signature Specification
Suite Algorithm Algorithm Pointer
Identifier
+------------+---------------+--------------+-----------------------+
| 0x02-0xF6 | Unassigned | Unassigned | |
+------------+---------------+--------------+-----------------------+
In addition, IANA has registered the following address spaces for "Experimentation" and "Documentation":
さらに、IANAは「実験」と「ドキュメント」用に次のアドレススペースを登録しています。
Algorithm Digest Signature Specification
Suite Algorithm Algorithm Pointer
Identifier
+------------+-----------------+-----------------+------------------+
| 0xF7-0xFA | Experimentation | Experimentation | This document |
+------------+-----------------+-----------------+------------------+
| 0xFB-0xFE | Documentation | Documentation | This document |
+------------+-----------------+-----------------+------------------+
The "BGPsec Algorithm Suites" registry in the RPKI group now contains the following values:
RPKIグループの「BGPsec Algorithm Suites」レジストリには、次の値が含まれるようになりました。
Algorithm Digest Signature Specification
Suite Algorithm Algorithm Pointer
Identifier
+------------+-----------------+-----------------+------------------+
| 0x00 | Reserved | Reserved | This document |
+------------+-----------------+-----------------+------------------+
| 0x01 | SHA-256 | ECDSA P-256 | [SHS] [DSS] |
| | | | [RFC6090] |
| | | | This document |
+------------+-----------------+-----------------+------------------+
| 0x02-0xF6 | Unassigned | Unassigned | |
+------------+-----------------+-----------------+------------------+
| 0xF7-0xFA | Experimentation | Experimentation | This document |
+------------+-----------------+-----------------+------------------+
| 0xFB-0xFE | Documentation | Documentation | This document |
+------------+-----------------+-----------------+------------------+
| 0xFF | Reserved | Reserved | This document |
+------------+-----------------+-----------------+------------------+
Future assignments are to be made using the Standards Action process
defined in [RFC8126]. Assignments consist of the one-octet algorithm
suite identifier value and the associated digest algorithm name and
signature algorithm name.
[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>。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc2986>.
[RFC2986] Nystrom、M。およびB. Kaliski、「PKCS＃10：Certification Request Syntax Specification Version 1.7」、RFC 2986、DOI 10.17487 / RFC2986、2000年11月、<https://www.rfc-editor.org/info / rfc2986>。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC3279] Bassham、L.、Polk、W。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、DOI 10.17487 / RFC3279、 2002年4月、<https://www.rfc-editor.org/info/rfc3279>。
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, <https://www.rfc-editor.org/info/rfc4211>.
[RFC4211] Schaad、J。、「Internet X.509 Public Key Infrastructure Certificate Request Message Format（CRMF）」、RFC 4211、DOI 10.17487 / RFC4211、2005年9月、<https://www.rfc-editor.org/info / rfc4211>。
[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>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/info/rfc5480>.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号化サブジェクト公開鍵情報」、RFC 5480、DOI 10.17487 / RFC5480、2009年3月、< https://www.rfc-editor.org/info/rfc5480>。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/info/rfc6090>.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、DOI 10.17487 / RFC6090、2011年2月、<https://www.rfc-editor.org/ info / rfc6090>。
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>.
[RFC6916]ガリアーノ、R。、ケント、S。、およびS.ターナー、「リソース公開鍵インフラストラクチャ（RPKI）のアルゴリズムの俊敏性手順」、BCP 182、RFC 6916、DOI 10.17487 / RFC6916、2013年4月、<https： //www.rfc-editor.org/info/rfc6916>。
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC7935] Huston、G。およびG. Michaelson、編、「リソースの公開鍵インフラストラクチャで使用するアルゴリズムと鍵サイズのプロファイル」、RFC 7935、DOI 10.17487 / RFC7935、2016年8月、<https：// www .rfc-editor.org / info / rfc7935>。
[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>。
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205]レピンスキー、M。、エド。 K. Sriram、編、「BGPsecプロトコル仕様」、RFC 8205、DOI 10.17487 / RFC8205、2017年9月、<https://www.rfc-editor.org/info/rfc8205>。
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>.
[RFC8208]ターナー、S。およびO.ボーチャート、「BGPsecアルゴリズム、キー形式、および署名形式」、RFC 8208、DOI 10.17487 / RFC8208、2017年9月、<https://www.rfc-editor.org/info/ rfc8208>。
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
[RFC8209]レイノルズ、M。、ターナー、S。、およびS.ケント、「BGPsecルーター証明書、証明書失効リスト、および認証要求のプロファイル」、RFC 8209、DOI 10.17487 / RFC8209、2017年9月、<https：/ /www.rfc-editor.org/info/rfc8209>。
[DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", NIST FIPS Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[DSS]米国国立標準技術研究所、「Digital Signature Standard（DSS）」、NIST FIPS Publication 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<https://nvlpubs.nist.gov / nistpubs / FIPS / NIST.FIPS.186-4.pdf>。
[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", NIST FIPS Publication 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[SHS]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、NIST FIPS Publication 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<https://nvlpubs.nist.gov / nistpubs / FIPS / NIST.FIPS.180-4.pdf>。
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, DOI 10.17487/RFC5398, December 2008, <https://www.rfc-editor.org/info/rfc5398>.
[RFC5398] Huston、G。、「Autonomous System（AS）Number Reservation for Documentation Use」、RFC 5398、DOI 10.17487 / RFC5398、2008年12月、<https://www.rfc-editor.org/info/rfc5398>。
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC6979]ポルノ、T。、「デジタル署名アルゴリズム（DSA）と楕円曲線デジタル署名アルゴリズム（ECDSA）の決定論的使用法」、RFC 6979、DOI 10.17487 / RFC6979、2013年8月、<https：//www.rfc- editor.org/info/rfc6979>。
Topology:
トポロジー：
AS(64496)----AS(65536)----AS(65537)
Prefix Announcement: AS(64496), 192.0.2.0/24, 2001:db8::/32
The signature algorithm used in this example is ECDSA P-256, using the algorithm suite identifier ID 0x01 (1) as specified in Section 7 of this document.
この例で使用されている署名アルゴリズムはECDSA P-256であり、このドキュメントのセクション7で指定されているアルゴリズムスイート識別子ID 0x01（1）を使用しています。
For this example, the ECDSA algorithm was provided with a static k to make the result deterministic.
この例では、結果を確定的にするために、ECDSAアルゴリズムに静的kが提供されました。
The k used for all signature operations was taken from [RFC6979], Appendix A.2.5, "Signatures With SHA-256, message = 'sample'".
すべての署名操作に使用されるkは、[RFC6979]、付録A.2.5、「SHA-256の署名、メッセージ= 'sample'」から取得されました。
Note: Even though the certificates below are expired, they are still useful within the constraint of this document.
注：以下の証明書は有効期限が切れていますが、このドキュメントの制限内では引き続き有効です。
k = A6E3C57DD01ABE90086538398355DD4C
3B17AA873382B0F24D6129493D8AAD60
Keys of AS64496:
================
ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154
private key:
x = D8AA4DFBE2478F86E88A7451BF075565
709C575AC1C136D081C540254CA440B9
public key:
Ux = 7391BABB92A0CB3BE10E59B19EBFFB21
4E04A91E0CBA1B139A7D38D90F77E55A
Uy = A05B8E695678E0FA16904B55D9D4F5C0
DFC58895EE50BC4F75D205A25BD36FF5
Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013
--------------------------------------------------------------------
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 38655612 (0x24dd67c)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ROUTER-0000FBF0
Validity
Not Before: Jan 1 05:00:00 2017 GMT
Not After : Jul 1 05:00:00 2018 GMT
Subject: CN=ROUTER-0000FBF0
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:73:91:ba:bb:92:a0:cb:3b:e1:0e:59:b1:9e:bf:
fb:21:4e:04:a9:1e:0c:ba:1b:13:9a:7d:38:d9:0f:
77:e5:5a:a0:5b:8e:69:56:78:e0:fa:16:90:4b:55:
d9:d4:f5:c0:df:c5:88:95:ee:50:bc:4f:75:d2:05:
a2:5b:d3:6f:f5
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage:
Digital Signature
X509v3 Subject Key Identifier:
AB:4D:91:0F:55:CA:E7:1A:21:5E:
F3:CA:FE:3A:CC:45:B5:EE:C1:54
X509v3 Extended Key Usage:
1.3.6.1.5.5.7.3.30
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
64496
Routing Domain Identifiers:
inherit
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:07:b7:b4:6a:5f:a4:f1:cc:68:36:39:03:a4:83:
ec:7c:80:02:d2:f6:08:9d:46:b2:ec:2a:7b:e6:92:b3:6f:b1:
02:20:00:91:05:4a:a1:f5:b0:18:9d:27:24:e8:b4:22:fd:d1:
1c:f0:3d:b1:38:24:5d:64:29:35:28:8d:ee:0c:38:29
-----BEGIN CERTIFICATE-----
MIIBiDCCAS+gAwIBAgIEAk3WfDAKBggqhkjOPQQDAjAaMRgwFgYDVQQDDA9ST1VU
RVItMDAwMEZCRjAwHhcNMTcwMTAxMDUwMDAwWhcNMTgwNzAxMDUwMDAwWjAaMRgw
FgYDVQQDDA9ST1VURVItMDAwMEZCRjAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AARzkbq7kqDLO+EOWbGev/shTgSpHgy6GxOafTjZD3flWqBbjmlWeOD6FpBLVdnU
9cDfxYiV7lC8T3XSBaJb02/1o2MwYTALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFKtN
kQ9VyucaIV7zyv46zEW17sFUMBMGA1UdJQQMMAoGCCsGAQUFBwMeMB4GCCsGAQUF
BwEIAQH/BA8wDaAHMAUCAwD78KECBQAwCgYIKoZIzj0EAwIDRwAwRAIgB7e0al+k
8cxoNjkDpIPsfIAC0vYInUay7Cp75pKzb7ECIACRBUqh9bAYnSck6LQi/dEc8D2x
OCRdZCk1KI3uDDgp
-----END CERTIFICATE-----
Keys of AS(65536):
==================
ski: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC
private key:
x = 6CB2E931B112F24554BCDCAAFD9553A9
519A9AF33C023B60846A21FC95583172
public key:
Ux = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1
E9D0E0DBEAEE425BD2F0D3175AA0E989
Uy = EA9B603E38F35FB329DF495641F2BA04
0F1C3AC6138307F257CBA6B8B588F41F
Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013
--------------------------------------------------------------------
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3752143940 (0xdfa52c44)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ROUTER-00010000
Validity
Not Before: Jan 1 05:00:00 2017 GMT
Not After : Jul 1 05:00:00 2018 GMT
Subject: CN=ROUTER-00010000
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:28:fc:5f:e9:af:cf:5f:4c:ab:3f:5f:85:cb:21:
2f:c1:e9:d0:e0:db:ea:ee:42:5b:d2:f0:d3:17:5a:
a0:e9:89:ea:9b:60:3e:38:f3:5f:b3:29:df:49:56:
41:f2:ba:04:0f:1c:3a:c6:13:83:07:f2:57:cb:a6:
b8:b5:88:f4:1f
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage:
Digital Signature
X509v3 Subject Key Identifier:
47:F2:3B:F1:AB:2F:8A:9D:26:86:
4E:BB:D8:DF:27:11:C7:44:06:EC
X509v3 Extended Key Usage:
1.3.6.1.5.5.7.3.30
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
65536
Routing Domain Identifiers:
inherit
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:8c:d9:f8:12:96:88:82:74:03:a1:82:82:18:
c5:31:00:ee:35:38:e8:fa:ae:72:09:fe:98:67:01:78:69:77:
8c:02:20:5f:ee:3a:bf:10:66:be:28:d3:b3:16:a1:6b:db:66:
21:99:ed:a6:e4:ad:64:3c:ba:bf:44:fb:cb:b7:50:91:74
-----BEGIN CERTIFICATE-----
MIIBijCCATCgAwIBAgIFAN+lLEQwCgYIKoZIzj0EAwIwGjEYMBYGA1UEAwwPUk9V
VEVSLTAwMDEwMDAwMB4XDTE3MDEwMTA1MDAwMFoXDTE4MDcwMTA1MDAwMFowGjEY
MBYGA1UEAwwPUk9VVEVSLTAwMDEwMDAwMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcD
QgAEKPxf6a/PX0yrP1+FyyEvwenQ4Nvq7kJb0vDTF1qg6Ynqm2A+OPNfsynfSVZB
8roEDxw6xhODB/JXy6a4tYj0H6NjMGEwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBRH
8jvxqy+KnSaGTrvY3ycRx0QG7DATBgNVHSUEDDAKBggrBgEFBQcDHjAeBggrBgEF
BQcBCAEB/wQPMA2gBzAFAgMBAAChAgUAMAoGCCqGSM49BAMCA0gAMEUCIQCM2fgS
loiCdAOhgoIYxTEA7jU46Pqucgn+mGcBeGl3jAIgX+46vxBmvijTsxaha9tmIZnt
puStZDy6v0T7y7dQkXQ=
-----END CERTIFICATE-----
BGPsec IPv4 UPDATE from AS(65536) to AS(65537):
===============================================
Binary Form of BGPsec UPDATE (TCP-DUMP):
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
01 03 02 00 00 00 EC 40 01 01 02 80 04 04 00 00
00 00 80 0E 0D 00 01 01 04 C6 33 64 64 00 18 C0
00 02 90 1E 00 CD 00 0E 01 00 00 01 00 00 01 00
00 00 FB F0 00 BF 01 47 F2 3B F1 AB 2F 8A 9D 26
86 4E BB D8 DF 27 11 C7 44 06 EC 00 48 30 46 02
21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD 9C D4 5E
81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E A8 4E AF
37 16 02 21 00 90 F2 C1 29 AB B2 F3 9B 6A 07 96
3B D5 55 A8 7A B2 B7 33 3B 7B 91 F1 66 8F D8 61
8C 83 FA C3 F1 AB 4D 91 0F 55 CA E7 1A 21 5E F3
CA FE 3A CC 45 B5 EE C1 54 00 48 30 46 02 21 00
EF D4 8B 2A AC B6 A8 FD 11 40 DD 9C D4 5E 81 D6
9D 2C 87 7B 56 AA F9 91 C3 4D 0E A8 4E AF 37 16
02 21 00 8E 21 F6 0E 44 C6 06 6C 8B 8A 95 A3 C0
9D 3A D4 37 95 85 A2 D7 28 EE AD 07 A1 7E D7 AA
05 5E CA
Signature from AS(64496) to AS(65536):
--------------------------------------
Digest: 21 33 E5 CA A0 26 BE 07 3D 9C 1B 4E FE B9 B9 77
9F 20 F8 F5 DE 29 FA 98 40 00 9F 60 47 D0 81 54
Signature: 30 46 02 21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD
9C D4 5E 81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E
A8 4E AF 37 16 02 21 00 8E 21 F6 0E 44 C6 06 6C
8B 8A 95 A3 C0 9D 3A D4 37 95 85 A2 D7 28 EE AD
07 A1 7E D7 AA 05 5E CA
Signature from AS(65536) to AS(65537):
--------------------------------------
Digest: 01 4F 24 DA E2 A5 21 90 B0 80 5C 60 5D B0 63 54
22 3E 93 BA 41 1D 3D 82 A3 EC 26 36 52 0C 5F 84
Signature: 30 46 02 21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD
9C D4 5E 81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E
A8 4E AF 37 16 02 21 00 90 F2 C1 29 AB B2 F3 9B
6A 07 96 3B D5 55 A8 7A B2 B7 33 3B 7B 91 F1 66
8F D8 61 8C 83 FA C3 F1
The human-readable output is produced using bgpsec-io, a BGPsec traffic generator that uses a Wireshark-like printout.
人間が読める形式の出力は、Wiresharkのようなプリントアウトを使用するBGPsecトラフィックジェネレータであるbgpsec-ioを使用して生成されます。
Send UPDATE Message
+--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+--length: 259
+--type: 2 (UPDATE)
+--withdrawn_routes_length: 0
+--total_path_attr_length: 236
+--ORIGIN: INCOMPLETE (4 bytes)
| +--Flags: 0x40 (Well-Known, Transitive, Complete)
| +--Type Code: ORIGIN (1)
| +--Length: 1 byte
| +--Origin: INCOMPLETE (1)
+--MULTI_EXIT_DISC (7 bytes)
| +--Flags: 0x80 (Optional, Non-transitive, Complete)
| +--Type Code: MULTI_EXIT_DISC (4)
| +--Length: 4 bytes
| +--data: 00 00 00 00
+--MP_REACH_NLRI (16 bytes)
| +--Flags: 0x80 (Optional, Non-transitive, Complete)
| +--Type Code: MP_REACH_NLRI (14)
| +--Length: 13 bytes
| +--Address family: IPv4 (1)
| +--Subsequent address family identifier: Unicast (1)
| +--Next hop network address: (4 bytes)
| | +--Next hop: 198.51.100.100
| +--Subnetwork points of attachment: 0
| +--Network layer reachability information: (4 bytes)
| +--192.0.2.0/24
| +--MP Reach NLRI prefix length: 24
| +--MP Reach NLRI IPv4 prefix: 192.0.2.0
+--BGPSEC Path Attribute (209 bytes)
+--Flags: 0x90 (Optional, Complete, Extended Length)
+--Type Code: BGPSEC Path Attribute (30)
+--Length: 205 bytes
+--Secure Path (14 bytes)
| +--Length: 14 bytes
| +--Secure Path Segment: (6 bytes)
| | +--pCount: 1
| | +--Flags: 0
| | +--AS number: 65536 (1.0)
| +--Secure Path Segment: (6 bytes)
| +--pCount: 1
| +--Flags: 0
| +--AS number: 64496 (0.64496)
+--Signature Block (191 bytes)
+--Length: 191 bytes
+--Algo ID: 1
+--Signature Segment: (94 bytes)
| +--SKI: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC
| +--Length: 72 bytes
| +--Signature: 3046022100EFD48B 2AACB6A8FD1140DD
| 9CD45E81D69D2C87 7B56AAF991C34D0E
| A84EAF3716022100 90F2C129ABB2F39B
| 6A07963BD555A87A B2B7333B7B91F166
| 8FD8618C83FAC3F1
+--Signature Segment: (94 bytes)
+--SKI: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154
+--Length: 72 bytes
+--Signature: 3046022100EFD48B 2AACB6A8FD1140DD
9CD45E81D69D2C87 7B56AAF991C34D0E
A84EAF3716022100 8E21F60E44C6066C
8B8A95A3C09D3AD4 379585A2D728EEAD
07A17ED7AA055ECA
BGPsec IPv6 UPDATE from AS(65536) to AS(65537):
===============================================
Binary Form of BGP/BGPsec UPDATE (TCP-DUMP):
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
01 10 02 00 00 00 F9 40 01 01 02 80 04 04 00 00
00 00 80 0E 1A 00 02 01 10 FD 00 00 00 00 00 00
00 00 00 00 00 C6 33 64 64 00 20 20 01 0D B8 90
1E 00 CD 00 0E 01 00 00 01 00 00 01 00 00 00 FB
F0 00 BF 01 47 F2 3B F1 AB 2F 8A 9D 26 86 4E BB
D8 DF 27 11 C7 44 06 EC 00 48 30 46 02 21 00 EF
D4 8B 2A AC B6 A8 FD 11 40 DD 9C D4 5E 81 D6 9D
2C 87 7B 56 AA F9 91 C3 4D 0E A8 4E AF 37 16 02
21 00 D1 B9 4F 62 51 04 6D 21 36 A1 05 B0 F4 72
7C C5 BC D6 74 D9 7D 28 E6 1B 8F 43 BD DE 91 C3
06 26 AB 4D 91 0F 55 CA E7 1A 21 5E F3 CA FE 3A
CC 45 B5 EE C1 54 00 48 30 46 02 21 00 EF D4 8B
2A AC B6 A8 FD 11 40 DD 9C D4 5E 81 D6 9D 2C 87
7B 56 AA F9 91 C3 4D 0E A8 4E AF 37 16 02 21 00
E2 A0 2C 68 FE 53 CB 96 93 4C 78 1F 5A 14 A2 97
19 79 20 0C 91 56 ED F8 55 05 8E 80 53 F4 AC D3
Signature from AS(64496) to AS(65536):
--------------------------------------
Digest: 8A 0C D3 E9 8E 55 10 45 82 1D 80 46 01 D6 55 FC
52 11 89 DF 4D B0 28 7D 84 AC FC 77 55 6D 06 C7
Signature: 30 46 02 21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD
9C D4 5E 81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E
A8 4E AF 37 16 02 21 00 E2 A0 2C 68 FE 53 CB 96
93 4C 78 1F 5A 14 A2 97 19 79 20 0C 91 56 ED F8
55 05 8E 80 53 F4 AC D3
Signature from AS(65536) to AS(65537):
--------------------------------------
Digest: 44 49 EC 70 8D EC 5C 85 00 C2 17 8C 72 FE 4C 79
FF A9 3C 95 31 61 01 2D EE 7E EE 05 46 AF 5F D0
Signature: 30 46 02 21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD
9C D4 5E 81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E
A8 4E AF 37 16 02 21 00 D1 B9 4F 62 51 04 6D 21
36 A1 05 B0 F4 72 7C C5 BC D6 74 D9 7D 28 E6 1B
8F 43 BD DE 91 C3 06 26
The human-readable output is produced using bgpsec-io, a BGPsec traffic generator that uses a Wireshark-like printout.
人間が読める形式の出力は、Wiresharkのようなプリントアウトを使用するBGPsecトラフィックジェネレータであるbgpsec-ioを使用して生成されます。
Send UPDATE Message
+--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+--length: 272
+--type: 2 (UPDATE)
+--withdrawn_routes_length: 0
+--total_path_attr_length: 249
+--ORIGIN: INCOMPLETE (4 bytes)
| +--Flags: 0x40 (Well-Known, Transitive, Complete)
| +--Type Code: ORIGIN (1)
| +--Length: 1 byte
| +--Origin: INCOMPLETE (1)
+--MULTI_EXIT_DISC (7 bytes)
| +--Flags: 0x80 (Optional, Non-transitive, Complete)
| +--Type Code: MULTI_EXIT_DISC (4)
| +--Length: 4 bytes
| +--data: 00 00 00 00
+--MP_REACH_NLRI (29 bytes)
| +--Flags: 0x80 (Optional, Non-transitive, Complete)
| +--Type Code: MP_REACH_NLRI (14)
| +--Length: 26 bytes
| +--Address family: IPv6 (2)
| +--Subsequent address family identifier: Unicast (1)
| +--Next hop network address: (16 bytes)
| | +--Next hop: fd00:0000:0000:0000:0000:0000:c633:6464
| +--Subnetwork points of attachment: 0
| +--Network layer reachability information: (5 bytes)
| +--2001:db8::/32
| +--MP Reach NLRI prefix length: 32
| +--MP Reach NLRI IPv6 prefix: 2001:db8::
+--BGPSEC Path Attribute (209 bytes)
+--Flags: 0x90 (Optional, Complete, Extended Length)
+--Type Code: BGPSEC Path Attribute (30)
+--Length: 205 bytes
+--Secure Path (14 bytes)
| +--Length: 14 bytes
| +--Secure Path Segment: (6 bytes)
| | +--pCount: 1
| | +--Flags: 0
| | +--AS number: 65536 (1.0)
| +--Secure Path Segment: (6 bytes)
| +--pCount: 1
| +--Flags: 0
| +--AS number: 64496 (0.64496)
+--Signature Block (191 bytes)
+--Length: 191 bytes
+--Algo ID: 1
+--Signature Segment: (94 bytes)
| +--SKI: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC
| +--Length: 72 bytes
| +--Signature: 3046022100EFD48B 2AACB6A8FD1140DD
| 9CD45E81D69D2C87 7B56AAF991C34D0E
| A84EAF3716022100 D1B94F6251046D21
| 36A105B0F4727CC5 BCD674D97D28E61B
| 8F43BDDE91C30626
+--Signature Segment: (94 bytes)
+--SKI: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154
+--Length: 72 bytes
+--Signature: 3046022100EFD48B 2AACB6A8FD1140DD
9CD45E81D69D2C87 7B56AAF991C34D0E
A84EAF3716022100 E2A02C68FE53CB96
934C781F5A14A297 1979200C9156EDF8
55058E8053F4ACD3
Acknowledgements
謝辞
The authors wish to thank Geoff Huston and George Michaelson for producing [RFC7935], which this document is entirely based on. The authors would also like to thank Roque Gagliano, David Mandelberg, Tom Petch, Sam Weiler, and Stephen Kent for their reviews and comments. Mehmet Adalier, Kotikalapudi Sriram, and Doug Montgomery were instrumental in developing the test vectors found in Appendix A. Additionally, we want to thank Geoff Huston, author of [RFC5398] from which we borrowed wording for Section 2.1 of this document.
著者は、このドキュメントが完全に基づいている[RFC7935]を作成してくれたGeoff HustonとGeorge Michaelsonに感謝します。著者はまた、レビューとコメントを提供してくれたRoque Gagliano、David Mandelberg、Tom Petch、Sam Weiler、およびStephen Kentにも感謝します。 Mehmet Adalier、Kotikalapudi Sriram、およびDoug Montgomeryは、付録Aにあるテストベクトルの開発に尽力しました。さらに、このドキュメントのセクション2.1の文言を借用した[RFC5398]の作者であるGeoff Hustonに感謝します。
Authors' Addresses
著者のアドレス
Sean Turner sn3rd
ショーンターナーsn3rd
Email: sean@sn3rd.com
Oliver Borchert NIST 100 Bureau Drive Gaithersburg, MD 20899 United States of America
Oliver Borchert NIST 100 Bureau Drive Gaithersburg、MD 20899アメリカ合衆国
Email: oliver.borchert@nist.gov