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（"用于资源公钥基础设施的算法和密钥大小简介"），并删除了 RFC 8208（"BGPsec 算法、密钥格式和签名格式"），增加了 "文档 "和 "实验 "算法 ID，修正了未分配算法 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.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组 (IETF) 的成果。它代表了 IETF 社区的共识。它已接受公众审查，并经互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参阅 RFC 7841 第 2 节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/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）的约束。 请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。 从本文档中提取的代码组件必须包含信托法律条款第 4.e 节中描述的简化 BSD 许可证文本，并且不提供简化 BSD 许可证中描述的担保。
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 证书与其他 RPKI 证书的区别在于使用了 [RFC8209] 中定义的 BGPsec 扩展密钥用法。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", "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 报文的每个 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 中的算法套件标识符字段（算法 ID）标识（参见 [RFC8205] 第 3.2 节）。
This document specifies five types of Algorithm IDs:
本文件规定了五种算法 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 不得在签名块中使用，如果遇到，路由器必须将 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 节定义了签名算法。[RFC8205] 第 4.2 节和第 5.2 节详细介绍了使用签名算法处理 BGPsec UPDATE 签名和验证。
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 消息的某个签名块中遇到未指定的算法 ID，路由器应按照 [RFC8205] 第 5.2 节中的规定，将该签名块作为不支持的算法处理。
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 节规定的不支持算法。
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 节中规定的不支持算法。
o The signature algorithm used MUST be the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS].
o 使用的签名算法必须是 P-256 曲线的椭圆曲线数字签名算法 (ECDSA) [RFC6090] [DSS]。
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 表示，该 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] 必须出现在《公钥加密标准第 10 号》（PKCS #10）签名算法字段 [RFC2986] 或证书请求信息格式（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 将被包含在签名块列表的算法套件标识符字段中。
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。结构及其子结构的值如下：
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 类型）：算法字段必须使用 id-ecPublicKey OID，如 [RFC5480] 第 2.1.1 节所述。相关参数的值必须是 secp256r1，如 [RFC5480] 第 2.1.1.1 节所述。
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.
互联网编号分配机构（IANA）在资源公钥基础设施（RPKI）组中创建了 "BGPsec 算法套件 "注册表。IANA 分配的单八位字节算法套件标识符可识别 BGPsec 签名块列表算法套件标识符字段中使用的摘要算法和签名算法。
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 is still valid, and IANA has updated the registration to refer to this document.
根据 [RFC8208]，IANA 为摘要算法 SHA-256 [SHS] 和 P-256 曲线上的签名算法 ECDSA [RFC6090] [DSS] 注册了一个算法套件标识符。该标识符仍然有效，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 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., "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>.
[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. 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>.
[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., 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>.
[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, September 2005, <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., 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>.
[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., 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>.
[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] 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>。
[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., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <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] 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>。
[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. 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>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton, M., Leiba, B., 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>。
[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., "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>。
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <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] 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>。
[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., 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>。
[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] 美国国家标准与技术研究院，"数字签名标准（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] 美国国家标准与技术研究院，"安全散列标准（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, December 2008, <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] 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>。
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，算法套件标识符 ID 0x01 (1)，如本文件第 7 节所述。
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.
bgpsec-io 是一种 BGPsec 流量生成器，使用类似于 Wireshark 的打印输出方式。
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.
bgpsec-io 是一种 BGPsec 流量生成器，使用类似于 Wireshark 的打印输出方式。
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.
作者感谢 Geoff Huston 和 George Michaelson 编写了 [RFC7935]，本文档完全基于 RFC7935。作者还要感谢 Roque Gagliano、David Mandelberg、Tom Petch、Sam Weiler 和 Stephen Kent 的审阅和评论。Mehmet Adalier、Kotikalapudi Sriram 和 Doug Montgomery 在开发附录 A 中的测试向量时发挥了重要作用。此外，我们还要感谢[RFC5398]的作者 Geoff Huston，本文第 2.1 节借用了他的措辞。
Authors' Addresses
作者地址
Sean Turner sn3rd
Sean Turner sn3rd
Email: [email protected]
Oliver Borchert NIST 100 Bureau Drive Gaithersburg, MD 20899 United States of America
Oliver Borchert NIST 100 Bureau Drive Gaithersburg, MD 20899 美利坚合众国
Email: [email protected]