idnits 2.17.1 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2018) is 2247 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 6090 ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) S. Turner 3 Internet-Draft sn3rd 4 Updates: 8208 (if approved) O. Borchert 5 Intended status: Standards Track NIST 6 Expires: September 2, 2018 March 1, 2018 8 BGPsec Algorithms, Key Formats, and Signature Formats 9 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-00 11 Abstract 13 This document specifies the algorithms, algorithm parameters, 14 asymmetric key formats, asymmetric key sizes, and signature formats 15 used in BGPsec (Border Gateway Protocol Security). This document 16 updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature 17 Formats") by adding Special-Use Algorithm IDs and correcting the 18 range of unassigned algorithms IDs to fill the complete range. 20 This document also includes example BGPsec UPDATE messages as well as 21 the private keys used to generate the messages and the certificates 22 necessary to validate those signatures. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 2, 2018 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Changes from RFC 8208 . . . . . . . . . . . . . . . . . . 4 61 2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Algorithm ID Types . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Signature Algorithms . . . . . . . . . . . . . . . . . . . 5 64 2.2.1. Algorithm ID 0x01 - (ECDSA-P256) . . . . . . . . . . . 5 65 3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . 6 66 3.1. Asymmetric Key Pair for Algorithm ID 0x01 - (ECDSA-p256) . 6 67 3.1.1. Public Key Format . . . . . . . . . . . . . . . . . . 6 68 3.1.2. Private Key Format . . . . . . . . . . . . . . . . . . 6 69 4. Signature Formats . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Additional Requirements . . . . . . . . . . . . . . . . . . . 6 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 77 A.1. Topology and Experiment Description . . . . . . . . . . . 11 78 A.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 A.3. BGPsec IPv4 . . . . . . . . . . . . . . . . . . . . . . . 15 80 A.4. BGPsec IPv6 . . . . . . . . . . . . . . . . . . . . . . . 18 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 84 1. Introduction 86 This document specifies the following: 88 o the digital signature algorithm and parameters, 90 o the hash algorithm and parameters, 92 o the algorithm identifier assignment and classification, 94 o the public and private key formats, and 96 o the signature formats 98 used by Resource Public Key Infrastructure (RPKI) Certification 99 Authorities (CAs) and BGPsec (Border Gateway Protocol Security) 100 speakers (i.e., routers). CAs use these algorithms when processing 101 requests for BGPsec Router Certificates [RFC8209]. Examples of when 102 BGPsec routers use these algorithms include requesting BGPsec 103 certificates [RFC8209], signing BGPsec UPDATE messages [RFC8205], and 104 verifying signatures on BGPsec UPDATE messages [RFC8205]. 106 This document updates [RFC7935] to add support for a) a different 107 algorithm for BGPsec certificate requests, which are issued only by 108 BGPsec speakers; b) a different Subject Public Key Info format for 109 BGPsec certificates, which is needed for the specified BGPsec 110 signature algorithm; and c) different signature formats for BGPsec 111 signatures, which are needed for the specified BGPsec signature 112 algorithm. The BGPsec certificates are differentiated from other 113 RPKI certificates by the use of the BGPsec Extended Key Usage as 114 defined in [RFC8209]. BGPsec uses a different algorithm [RFC6090] 115 [DSS] as compared to the rest of the RPKI to minimize the size of the 116 protocol exchanged between routers. 118 Appendix A contains example BGPsec UPDATE messages as well as the 119 private keys used to generate the messages and the certificates 120 necessary to validate the signatures. 122 1.1. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 1.2. Changes from RFC 8208 132 This section describes the significant changes between [RFC8208] and 133 this document. 135 o Adding section 2.1 of algorithm ID types and what to do when these 136 IDs are observed. 138 o Restructured Sections 2 and 3 to align with the corresponding 139 algorithm suite identifier value. 141 o Correction of range for unassigned algorithm suite identifier 142 values. 144 o Adding of Special-Use algorithm suite identifier values. 146 2. Algorithms 148 The algorithms used to compute signatures on CA certificates, 149 BGPsec Router Certificates, and Certificate Revocation Lists 150 (CRLs) are as specified in Section 2 of [RFC7935]. This section 151 addresses BGPsec algorithms; for example, these algorithms are 152 used by BGPsec routers to sign and verify BGPsec UPDATE messages. 153 To identify which algorithm is used, the BGPsec UPDATE message 154 contains the corresponding algorithm ID in each Signature_Block of 155 the BGPsec UPDATE message. 157 2.1. Algorithm ID Types 159 Algorithms in BGPsec UPDATE messages are identified by the 160 Algorithm Suite Identifier field (Algorithm ID) within the 161 Signature_Block (see Section 3.2 of [RFC8205]). 163 This document specifies four types of algorithm IDs: 165 o Reserved Algorithm ID 167 Reserved algorithm IDs are the values 0x00 and 0xFF. These IDs 168 MUST NOT be used in a Signature_Block and if encountered, the 169 router MUST treat BGPsec UPDATE messages as Malformed [RFC4271]. 171 o Signature Algorithm ID 173 Signature algorithms are defined in Section 2.2 of this document. 174 Processing of BGPsec UPDATE signing and validation using signature 175 algorithms is described in length in Section 4.2 and Section 5.2 176 of [RFC8205]. 178 o Unassigned Algorithm ID 180 This type of algorithm ID is free for future assignments and MUST 181 NOT be used until an algorithm is officially assigned (see 182 Section 7). In case a router encounters an unassigned algorithm 183 ID in one of the Signature_Blocks of a BGPsec UPDATE message, the 184 router SHOULD process the Signature_Block as 185 "unsupported algorithm" as specified in Section 5.2 of [RFC8205]. 187 o Special-Use Algorithm ID 189 Special-Use algorithm IDs span from 0xFA (250) to 0xFE (254). To 190 allow documentation and experimentation to accurately describe 191 deployment examples, the use of publicly assigned algorithm IDs is 192 inappropriate, and a reserved block of Special-Use algorithm IDs 193 is required. This ensures that documentation and experimentation 194 does not clash with assigned algorithm IDs in deployed networks, 195 and mitigates the risks to operational integrity of the network 196 through inappropriate use of documentation to perform literal 197 configuration of routing elements on production systems. A router 198 that encounters an algorithm ID of this type outside of an 199 experimental network, SHOULD treat these type same as 200 "unsupported algorithm" as specified in Section 5.2 of [RFC8205]. 202 2.2. Signature Algorithms 204 2.2.1. Algorithm ID 0x01 - (ECDSA-P256) 206 o The signature algorithm used MUST be the Elliptic Curve Digital 207 Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS]. 209 o The hash algorithm used MUST be SHA-256 [SHS]. 211 Hash algorithms are not identified by themselves in certificates or 212 BGPsec UPDATE messages. They are represented by an OID that combines 213 the hash algorithm with the digital signature algorithm as follows: 215 o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the Public-Key 216 Cryptography Standards #10 (PKCS #10) signatureAlgorithm field 217 [RFC2986] or in the Certificate Request Message Format (CRMF) 218 POPOSigningKey algorithm field [RFC4211]; where the OID is placed 219 depends on the certificate request format generated. 221 o In BGPsec UPDATE messages, the ECDSA with SHA-256 algorithm suite 222 identifier value 0x01 (see Section 7) is included in the 223 Signature_Block List's Algorithm Suite Identifier field. 225 3. Asymmetric Key Pair Formats 227 The key formats used to compute signatures on CA certificates, BGPsec 228 Router Certificates, and CRLs are as specified in Section 3 of 229 [RFC7935]. This section addresses key formats found in the BGPsec 230 Router Certificate requests and in BGPsec Router Certificates. 232 3.1. Asymmetric Key Pair for Algorithm ID 0x01 - (ECDSA-p256) 234 The ECDSA private keys used to compute signatures for certificate 235 requests and BGPsec UPDATE messages MUST be associated with the P-256 236 curve domain parameters [RFC5480]. The public key pair MUST use the 237 uncompressed form. 239 3.1.1. Public Key Format 241 The Subject's public key is included in subjectPublicKeyInfo 242 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 243 The values for the structures and their sub-structures follow: 245 o algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID 246 MUST be used in the algorithm field, as specified in Section 2.1.1 247 of [RFC5480]. The value for the associated parameters MUST be 248 secp256r1, as specified in Section 2.1.1.1 of [RFC5480]. 250 o subjectPublicKey: ECPoint MUST be used to encode the certificate's 251 subjectPublicKey field, as specified in Section 2.2 of [RFC5480]. 253 3.1.2. Private Key Format 255 Local policy determines private key format. 257 4. Signature Formats 259 The structure for the certificate's and CRL's signature field MUST be 260 as specified in Section 4 of [RFC7935]; this is the same format used 261 by other RPKI certificates. The structure for the certification 262 request's and BGPsec UPDATE message's signature field MUST be as 263 specified in Section 2.2.3 of [RFC3279]. 265 5. Additional Requirements 267 It is anticipated that BGPsec will require the adoption of updated 268 key sizes and a different set of signature and hash algorithms over 269 time, in order to maintain an acceptable level of cryptographic 270 security. This profile should be updated to specify such future 271 requirements, when appropriate. 273 The recommended procedures to implement such a transition of key 274 sizes and algorithms are specified in [RFC6916]. 276 6. Security Considerations 278 The security considerations of [RFC3279], [RFC5480], [RFC6090], 279 [RFC7935], and [RFC8209] apply to certificates. The security 280 considerations of [RFC3279], [RFC6090], [RFC7935], and [RFC8209] 281 apply to certification requests. The security considerations of 282 [RFC3279], [RFC6090], and [RFC8205] apply to BGPsec UPDATE messages. 283 No new security considerations are introduced as a result of this 284 specification. 286 7. IANA Considerations 288 The Internet Assigned Numbers Authority (IANA) has created the 289 "BGPsec Algorithm Suite Registry" in the Resource Public Key 290 Infrastructure (RPKI) group. The one-octet "BGPsec Algorithm Suite 291 Registry" identifiers assigned by IANA identify the digest algorithm 292 and signature algorithm used in the BGPsec Signature_Block List's 293 Algorithm Suite Identifier field. 295 IANA has registered a single algorithm suite identifier for the 296 digest algorithm SHA-256 [SHS] and for the signature algorithm ECDSA 297 on the P-256 curve [RFC6090] [DSS]. 299 BGPsec Algorithm Suite Registry 301 Algorithm Digest Signature Specification 302 Suite Algorithm Algorithm Pointer 303 Identifier 304 +------------+---------------+--------------+-----------------------+ 305 | 0x00 | Reserved | Reserved | This document | 306 +------------+---------------+--------------+-----------------------+ 307 | 0x01 | SHA-256 | ECDSA P-256 | [SHS] [DSS] [RFC6090] | 308 | | | | This document | 309 +------------+---------------+--------------+-----------------------+ 310 | 0x02-0xFA | Unassigned | Unassigned | | 311 +------------+---------------+--------------+-----------------------+ 312 | 0xFB-0xFE | Special-Use | Special-Use | This Document | 313 +------------+---------------+--------------+-----------------------+ 314 | 0xFF | Reserved | Reserved | This document | 315 +------------+---------------+--------------+-----------------------+ 317 Future assignments are to be made using the Standards Action process 318 defined in [RFC8126]. Assignments consist of the one-octet algorithm 319 suite identifier value and the associated digest algorithm name and 320 signature algorithm name. 322 8. References 324 8.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, DOI 328 10.17487/RFC2119, March 1997, . 331 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 332 Request Syntax Specification Version 1.7", RFC 2986, DOI 333 10.17487/RFC2986, November 2000, . 336 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 337 Identifiers for the Internet X.509 Public Key 338 Infrastructure Certificate and Certificate Revocation List 339 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 340 2002, . 342 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 343 Certificate Request Message Format (CRMF)", RFC 4211, DOI 344 10.17487/RFC4211, September 2005, . 347 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 348 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 349 10.17487/RFC4271, January 2006, . 352 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 353 Housley, R., and W. Polk, "Internet X.509 Public Key 354 Infrastructure Certificate and Certificate Revocation List 355 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 356 . 358 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 359 "Elliptic Curve Cryptography Subject Public Key 360 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 361 . 363 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 364 Curve Cryptography Algorithms", RFC 6090, DOI 365 10.17487/RFC6090, February 2011, . 368 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 369 Procedure for the Resource Public Key Infrastructure 370 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 371 2013, . 373 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 374 Algorithms and Key Sizes for Use in the Resource Public 375 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 376 August 2016, . 378 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 379 Writing an IANA Considerations Section in RFCs", BCP 26, 380 RFC 8126, DOI 10.17487/RFC8126, June 2017, 381 . 383 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 384 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 385 10.17487/RFC8174, May 2017, . 388 [RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol 389 Specification", RFC 8205, DOI 10.17487/RFC8205, September 390 2017, . 392 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 393 Formats, and Signature Formats", RFC 8208, DOI 394 10.17487/RFC8208, September 2017, . 397 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 398 BGPsec Router Certificates, Certificate Revocation Lists, 399 and Certification Requests", RFC 8209, DOI 400 10.17487/RFC8209, September 2017, . 403 [DSS] National Institute of Standards and Technology, "Digital 404 Signature Standard (DSS)", NIST FIPS Publication 186-4, 405 DOI 10.6028/NIST.FIPS.186-4, July 2013, 406 . 409 [SHS] National Institute of Standards and Technology, "Secure 410 Hash Standard (SHS)", NIST FIPS Publication 180-4, 411 DOI 10.6028/NIST.FIPS.180-4, August 2015, 412 . 415 8.2. Informative References 417 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 418 Documentation Use", RFC 5398, DOI 10.17487/RFC5398, 419 December 2008, . 421 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 422 Algorithm (DSA) and Elliptic Curve Digital Signature 423 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 424 2013, . 426 Appendix A. Examples 428 A.1. Topology and Experiment Description 430 Topology: 432 AS(64496)----AS(65536)----AS(65537) 434 Prefix Announcement: AS(64496), 192.0.2.0/24, 2001:db8::/32 436 The signature algorithm used in this example is ECDSA P-256 using the 437 algorithm suite identifier ID 0x01 as specified in Section 7 of this 438 document. 440 A.2. Keys 442 For this example, the ECDSA algorithm was provided with a static k to 443 make the result deterministic. 445 The k used for all signature operations was taken from [RFC6979], 446 Appendix A.2.5, "Signatures With SHA-256, message = 'sample'". 448 k = A6E3C57DD01ABE90086538398355DD4C 449 3B17AA873382B0F24D6129493D8AAD60 451 Keys of AS64496: 452 ================ 453 ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154 455 private key: 456 x = D8AA4DFBE2478F86E88A7451BF075565 457 709C575AC1C136D081C540254CA440B9 459 public key: 460 Ux = 7391BABB92A0CB3BE10E59B19EBFFB21 461 4E04A91E0CBA1B139A7D38D90F77E55A 462 Uy = A05B8E695678E0FA16904B55D9D4F5C0 463 DFC58895EE50BC4F75D205A25BD36FF5 465 Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013 466 -------------------------------------------------------------------- 467 Certificate: 468 Data: 469 Version: 3 (0x2) 470 Serial Number: 38655612 (0x24dd67c) 471 Signature Algorithm: ecdsa-with-SHA256 472 Issuer: CN=ROUTER-0000FBF0 473 Validity 474 Not Before: Jan 1 05:00:00 2017 GMT 475 Not After : Jul 1 05:00:00 2018 GMT 476 Subject: CN=ROUTER-0000FBF0 477 Subject Public Key Info: 478 Public Key Algorithm: id-ecPublicKey 479 Public-Key: (256 bit) 480 pub: 481 04:73:91:ba:bb:92:a0:cb:3b:e1:0e:59:b1:9e:bf: 482 fb:21:4e:04:a9:1e:0c:ba:1b:13:9a:7d:38:d9:0f: 483 77:e5:5a:a0:5b:8e:69:56:78:e0:fa:16:90:4b:55: 484 d9:d4:f5:c0:df:c5:88:95:ee:50:bc:4f:75:d2:05: 485 a2:5b:d3:6f:f5 486 ASN1 OID: prime256v1 487 X509v3 extensions: 488 X509v3 Key Usage: 489 Digital Signature 490 X509v3 Subject Key Identifier: 491 AB:4D:91:0F:55:CA:E7:1A:21:5E: 492 F3:CA:FE:3A:CC:45:B5:EE:C1:54 493 X509v3 Extended Key Usage: 494 1.3.6.1.5.5.7.3.30 495 sbgp-autonomousSysNum: critical 496 Autonomous System Numbers: 497 64496 498 Routing Domain Identifiers: 499 inherit 501 Signature Algorithm: ecdsa-with-SHA256 502 30:44:02:20:07:b7:b4:6a:5f:a4:f1:cc:68:36:39:03:a4:83: 503 ec:7c:80:02:d2:f6:08:9d:46:b2:ec:2a:7b:e6:92:b3:6f:b1: 504 02:20:00:91:05:4a:a1:f5:b0:18:9d:27:24:e8:b4:22:fd:d1: 505 1c:f0:3d:b1:38:24:5d:64:29:35:28:8d:ee:0c:38:29 507 -----BEGIN CERTIFICATE----- 508 MIIBiDCCAS+gAwIBAgIEAk3WfDAKBggqhkjOPQQDAjAaMRgwFgYDVQQDDA9ST1VU 509 RVItMDAwMEZCRjAwHhcNMTcwMTAxMDUwMDAwWhcNMTgwNzAxMDUwMDAwWjAaMRgw 510 FgYDVQQDDA9ST1VURVItMDAwMEZCRjAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC 511 AARzkbq7kqDLO+EOWbGev/shTgSpHgy6GxOafTjZD3flWqBbjmlWeOD6FpBLVdnU 512 9cDfxYiV7lC8T3XSBaJb02/1o2MwYTALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFKtN 513 kQ9VyucaIV7zyv46zEW17sFUMBMGA1UdJQQMMAoGCCsGAQUFBwMeMB4GCCsGAQUF 514 BwEIAQH/BA8wDaAHMAUCAwD78KECBQAwCgYIKoZIzj0EAwIDRwAwRAIgB7e0al+k 515 8cxoNjkDpIPsfIAC0vYInUay7Cp75pKzb7ECIACRBUqh9bAYnSck6LQi/dEc8D2x 516 OCRdZCk1KI3uDDgp 517 -----END CERTIFICATE----- 519 Keys of AS(65536): 520 ================== 521 ski: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC 523 private key: 524 x = 6CB2E931B112F24554BCDCAAFD9553A9 525 519A9AF33C023B60846A21FC95583172 527 public key: 528 Ux = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1 529 E9D0E0DBEAEE425BD2F0D3175AA0E989 530 Uy = EA9B603E38F35FB329DF495641F2BA04 531 0F1C3AC6138307F257CBA6B8B588F41F 533 Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013 534 -------------------------------------------------------------------- 535 Certificate: 536 Data: 537 Version: 3 (0x2) 538 Serial Number: 3752143940 (0xdfa52c44) 539 Signature Algorithm: ecdsa-with-SHA256 540 Issuer: CN=ROUTER-00010000 541 Validity 542 Not Before: Jan 1 05:00:00 2017 GMT 543 Not After : Jul 1 05:00:00 2018 GMT 544 Subject: CN=ROUTER-00010000 545 Subject Public Key Info: 546 Public Key Algorithm: id-ecPublicKey 547 Public-Key: (256 bit) 548 pub: 549 04:28:fc:5f:e9:af:cf:5f:4c:ab:3f:5f:85:cb:21: 550 2f:c1:e9:d0:e0:db:ea:ee:42:5b:d2:f0:d3:17:5a: 551 a0:e9:89:ea:9b:60:3e:38:f3:5f:b3:29:df:49:56: 552 41:f2:ba:04:0f:1c:3a:c6:13:83:07:f2:57:cb:a6: 553 b8:b5:88:f4:1f 554 ASN1 OID: prime256v1 555 X509v3 extensions: 556 X509v3 Key Usage: 557 Digital Signature 558 X509v3 Subject Key Identifier: 559 47:F2:3B:F1:AB:2F:8A:9D:26:86: 560 4E:BB:D8:DF:27:11:C7:44:06:EC 561 X509v3 Extended Key Usage: 562 1.3.6.1.5.5.7.3.30 563 sbgp-autonomousSysNum: critical 564 Autonomous System Numbers: 565 65536 566 Routing Domain Identifiers: 567 inherit 569 Signature Algorithm: ecdsa-with-SHA256 570 30:45:02:21:00:8c:d9:f8:12:96:88:82:74:03:a1:82:82:18: 571 c5:31:00:ee:35:38:e8:fa:ae:72:09:fe:98:67:01:78:69:77: 572 8c:02:20:5f:ee:3a:bf:10:66:be:28:d3:b3:16:a1:6b:db:66: 573 21:99:ed:a6:e4:ad:64:3c:ba:bf:44:fb:cb:b7:50:91:74 575 -----BEGIN CERTIFICATE----- 576 MIIBijCCATCgAwIBAgIFAN+lLEQwCgYIKoZIzj0EAwIwGjEYMBYGA1UEAwwPUk9V 577 VEVSLTAwMDEwMDAwMB4XDTE3MDEwMTA1MDAwMFoXDTE4MDcwMTA1MDAwMFowGjEY 578 MBYGA1UEAwwPUk9VVEVSLTAwMDEwMDAwMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcD 579 QgAEKPxf6a/PX0yrP1+FyyEvwenQ4Nvq7kJb0vDTF1qg6Ynqm2A+OPNfsynfSVZB 580 8roEDxw6xhODB/JXy6a4tYj0H6NjMGEwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBRH 581 8jvxqy+KnSaGTrvY3ycRx0QG7DATBgNVHSUEDDAKBggrBgEFBQcDHjAeBggrBgEF 582 BQcBCAEB/wQPMA2gBzAFAgMBAAChAgUAMAoGCCqGSM49BAMCA0gAMEUCIQCM2fgS 583 loiCdAOhgoIYxTEA7jU46Pqucgn+mGcBeGl3jAIgX+46vxBmvijTsxaha9tmIZnt 584 puStZDy6v0T7y7dQkXQ= 585 -----END CERTIFICATE----- 587 A.3. BGPsec IPv4 589 BGPsec IPv4 UPDATE from AS(65536) to AS(65537): 590 =============================================== 591 Binary Form of BGPsec UPDATE (TCP-DUMP): 593 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 594 01 03 02 00 00 00 EC 40 01 01 02 80 04 04 00 00 595 00 00 80 0E 0D 00 01 01 04 C6 33 64 64 00 18 C0 596 00 02 90 1E 00 CD 00 0E 01 00 00 01 00 00 01 00 597 00 00 FB F0 00 BF 01 47 F2 3B F1 AB 2F 8A 9D 26 598 86 4E BB D8 DF 27 11 C7 44 06 EC 00 48 30 46 02 599 21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD 9C D4 5E 600 81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E A8 4E AF 601 37 16 02 21 00 90 F2 C1 29 AB B2 F3 9B 6A 07 96 602 3B D5 55 A8 7A B2 B7 33 3B 7B 91 F1 66 8F D8 61 603 8C 83 FA C3 F1 AB 4D 91 0F 55 CA E7 1A 21 5E F3 604 CA FE 3A CC 45 B5 EE C1 54 00 48 30 46 02 21 00 605 EF D4 8B 2A AC B6 A8 FD 11 40 DD 9C D4 5E 81 D6 606 9D 2C 87 7B 56 AA F9 91 C3 4D 0E A8 4E AF 37 16 607 02 21 00 8E 21 F6 0E 44 C6 06 6C 8B 8A 95 A3 C0 608 9D 3A D4 37 95 85 A2 D7 28 EE AD 07 A1 7E D7 AA 609 05 5E CA 611 Signature from AS(64496) to AS(65536): 612 -------------------------------------- 613 Digest: 21 33 E5 CA A0 26 BE 07 3D 9C 1B 4E FE B9 B9 77 614 9F 20 F8 F5 DE 29 FA 98 40 00 9F 60 47 D0 81 54 615 Signature: 30 46 02 21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD 616 9C D4 5E 81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E 617 A8 4E AF 37 16 02 21 00 8E 21 F6 0E 44 C6 06 6C 618 8B 8A 95 A3 C0 9D 3A D4 37 95 85 A2 D7 28 EE AD 619 07 A1 7E D7 AA 05 5E CA 621 Signature from AS(65536) to AS(65537): 622 -------------------------------------- 623 Digest: 01 4F 24 DA E2 A5 21 90 B0 80 5C 60 5D B0 63 54 624 22 3E 93 BA 41 1D 3D 82 A3 EC 26 36 52 0C 5F 84 625 Signature: 30 46 02 21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD 626 9C D4 5E 81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E 627 A8 4E AF 37 16 02 21 00 90 F2 C1 29 AB B2 F3 9B 628 6A 07 96 3B D5 55 A8 7A B2 B7 33 3B 7B 91 F1 66 629 8F D8 61 8C 83 FA C3 F1 631 The human-readable output is produced using bgpsec-io, a BGPsec 632 traffic generator that uses a Wireshark-like printout. 634 Send UPDATE Message 635 +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 636 +--length: 259 637 +--type: 2 (UPDATE) 638 +--withdrawn_routes_length: 0 639 +--total_path_attr_length: 236 640 +--ORIGIN: INCOMPLETE (4 bytes) 641 | +--Flags: 0x40 (Well-Known, Transitive, Complete) 642 | +--Type Code: ORIGIN (1) 643 | +--Length: 1 byte 644 | +--Origin: INCOMPLETE (1) 645 +--MULTI_EXIT_DISC (7 bytes) 646 | +--Flags: 0x80 (Optional, Non-transitive, Complete) 647 | +--Type Code: MULTI_EXIT_DISC (4) 648 | +--Length: 4 bytes 649 | +--data: 00 00 00 00 650 +--MP_REACH_NLRI (16 bytes) 651 | +--Flags: 0x80 (Optional, Non-transitive, Complete) 652 | +--Type Code: MP_REACH_NLRI (14) 653 | +--Length: 13 bytes 654 | +--Address family: IPv4 (1) 655 | +--Subsequent address family identifier: Unicast (1) 656 | +--Next hop network address: (4 bytes) 657 | | +--Next hop: 198.51.100.100 658 | +--Subnetwork points of attachment: 0 659 | +--Network layer reachability information: (4 bytes) 660 | +--192.0.2.0/24 661 | +--MP Reach NLRI prefix length: 24 662 | +--MP Reach NLRI IPv4 prefix: 192.0.2.0 663 +--BGPSEC Path Attribute (209 bytes) 664 +--Flags: 0x90 (Optional, Complete, Extended Length) 665 +--Type Code: BGPSEC Path Attribute (30) 666 +--Length: 205 bytes 667 +--Secure Path (14 bytes) 668 | +--Length: 14 bytes 669 | +--Secure Path Segment: (6 bytes) 670 | | +--pCount: 1 671 | | +--Flags: 0 672 | | +--AS number: 65536 (1.0) 673 | +--Secure Path Segment: (6 bytes) 674 | +--pCount: 1 675 | +--Flags: 0 676 | +--AS number: 64496 (0.64496) 677 +--Signature Block (191 bytes) 678 +--Length: 191 bytes 679 +--Algo ID: 1 680 +--Signature Segment: (94 bytes) 681 | +--SKI: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC 682 | +--Length: 72 bytes 683 | +--Signature: 3046022100EFD48B 2AACB6A8FD1140DD 684 | 9CD45E81D69D2C87 7B56AAF991C34D0E 685 | A84EAF3716022100 90F2C129ABB2F39B 686 | 6A07963BD555A87A B2B7333B7B91F166 687 | 8FD8618C83FAC3F1 688 +--Signature Segment: (94 bytes) 689 +--SKI: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154 690 +--Length: 72 bytes 691 +--Signature: 3046022100EFD48B 2AACB6A8FD1140DD 692 9CD45E81D69D2C87 7B56AAF991C34D0E 693 A84EAF3716022100 8E21F60E44C6066C 694 8B8A95A3C09D3AD4 379585A2D728EEAD 695 07A17ED7AA055ECA 697 A.4. BGPsec IPv6 699 BGPsec IPv6 UPDATE from AS(65536) to AS(65537): 700 =============================================== 701 Binary Form of BGP/BGPsec UPDATE (TCP-DUMP): 703 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 704 01 10 02 00 00 00 F9 40 01 01 02 80 04 04 00 00 705 00 00 80 0E 1A 00 02 01 10 20 01 00 10 00 00 00 706 00 00 00 00 00 C6 33 64 64 00 20 20 01 0D B8 90 707 1E 00 CD 00 0E 01 00 00 01 00 00 01 00 00 00 FB 708 F0 00 BF 01 47 F2 3B F1 AB 2F 8A 9D 26 86 4E BB 709 D8 DF 27 11 C7 44 06 EC 00 48 30 46 02 21 00 EF 710 D4 8B 2A AC B6 A8 FD 11 40 DD 9C D4 5E 81 D6 9D 711 2C 87 7B 56 AA F9 91 C3 4D 0E A8 4E AF 37 16 02 712 21 00 D1 B9 4F 62 51 04 6D 21 36 A1 05 B0 F4 72 713 7C C5 BC D6 74 D9 7D 28 E6 1B 8F 43 BD DE 91 C3 714 06 26 AB 4D 91 0F 55 CA E7 1A 21 5E F3 CA FE 3A 715 CC 45 B5 EE C1 54 00 48 30 46 02 21 00 EF D4 8B 716 2A AC B6 A8 FD 11 40 DD 9C D4 5E 81 D6 9D 2C 87 717 7B 56 AA F9 91 C3 4D 0E A8 4E AF 37 16 02 21 00 718 E2 A0 2C 68 FE 53 CB 96 93 4C 78 1F 5A 14 A2 97 719 19 79 20 0C 91 56 ED F8 55 05 8E 80 53 F4 AC D3 721 Signature from AS(64496) to AS(65536): 722 -------------------------------------- 723 Digest: 8A 0C D3 E9 8E 55 10 45 82 1D 80 46 01 D6 55 FC 724 52 11 89 DF 4D B0 28 7D 84 AC FC 77 55 6D 06 C7 725 Signature: 30 46 02 21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD 726 9C D4 5E 81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E 727 A8 4E AF 37 16 02 21 00 E2 A0 2C 68 FE 53 CB 96 728 93 4C 78 1F 5A 14 A2 97 19 79 20 0C 91 56 ED F8 729 55 05 8E 80 53 F4 AC D3 731 Signature from AS(65536) to AS(65537): 732 -------------------------------------- 733 Digest: 44 49 EC 70 8D EC 5C 85 00 C2 17 8C 72 FE 4C 79 734 FF A9 3C 95 31 61 01 2D EE 7E EE 05 46 AF 5F D0 735 Signature: 30 46 02 21 00 EF D4 8B 2A AC B6 A8 FD 11 40 DD 736 9C D4 5E 81 D6 9D 2C 87 7B 56 AA F9 91 C3 4D 0E 737 A8 4E AF 37 16 02 21 00 D1 B9 4F 62 51 04 6D 21 738 36 A1 05 B0 F4 72 7C C5 BC D6 74 D9 7D 28 E6 1B 739 8F 43 BD DE 91 C3 06 26 741 The human-readable output is produced using bgpsec-io, a BGPsec 742 traffic generator that uses a Wireshark-like printout. 744 Send UPDATE Message 745 +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 746 +--length: 272 747 +--type: 2 (UPDATE) 748 +--withdrawn_routes_length: 0 749 +--total_path_attr_length: 249 750 +--ORIGIN: INCOMPLETE (4 bytes) 751 | +--Flags: 0x40 (Well-Known, Transitive, Complete) 752 | +--Type Code: ORIGIN (1) 753 | +--Length: 1 byte 754 | +--Origin: INCOMPLETE (1) 755 +--MULTI_EXIT_DISC (7 bytes) 756 | +--Flags: 0x80 (Optional, Non-transitive, Complete) 757 | +--Type Code: MULTI_EXIT_DISC (4) 758 | +--Length: 4 bytes 759 | +--data: 00 00 00 00 760 +--MP_REACH_NLRI (29 bytes) 761 | +--Flags: 0x80 (Optional, Non-transitive, Complete) 762 | +--Type Code: MP_REACH_NLRI (14) 763 | +--Length: 26 bytes 764 | +--Address family: IPv6 (2) 765 | +--Subsequent address family identifier: Unicast (1) 766 | +--Next hop network address: (16 bytes) 767 | | +--Next hop: 2001:0010:0000:0000:0000:0000:c633:6464 768 | +--Subnetwork points of attachment: 0 769 | +--Network layer reachability information: (5 bytes) 770 | +--2001:db8::/32 771 | +--MP Reach NLRI prefix length: 32 772 | +--MP Reach NLRI IPv6 prefix: 2001:db8:: 774 +--BGPSEC Path Attribute (209 bytes) 775 +--Flags: 0x90 (Optional, Complete, Extended Length) 776 +--Type Code: BGPSEC Path Attribute (30) 777 +--Length: 205 bytes 778 +--Secure Path (14 bytes) 779 | +--Length: 14 bytes 780 | +--Secure Path Segment: (6 bytes) 781 | | +--pCount: 1 782 | | +--Flags: 0 783 | | +--AS number: 65536 (1.0) 784 | +--Secure Path Segment: (6 bytes) 785 | +--pCount: 1 786 | +--Flags: 0 787 | +--AS number: 64496 (0.64496) 788 +--Signature Block (191 bytes) 789 +--Length: 191 bytes 790 +--Algo ID: 1 791 +--Signature Segment: (94 bytes) 792 | +--SKI: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC 793 | +--Length: 72 bytes 794 | +--Signature: 3046022100EFD48B 2AACB6A8FD1140DD 795 | 9CD45E81D69D2C87 7B56AAF991C34D0E 796 | A84EAF3716022100 D1B94F6251046D21 797 | 36A105B0F4727CC5 BCD674D97D28E61B 798 | 8F43BDDE91C30626 799 +--Signature Segment: (94 bytes) 800 +--SKI: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154 801 +--Length: 72 bytes 802 +--Signature: 3046022100EFD48B 2AACB6A8FD1140DD 803 9CD45E81D69D2C87 7B56AAF991C34D0E 804 A84EAF3716022100 E2A02C68FE53CB96 805 934C781F5A14A297 1979200C9156EDF8 806 55058E8053F4ACD3 808 Acknowledgements 810 The authors wish to thank Geoff Huston and George Michaelson for 811 producing [RFC7935], which this document is entirely based on. The 812 authors would also like to thank Roque Gagliano, David Mandelberg, 813 Tom Petch, Sam Weiler, and Stephen Kent for their reviews and 814 comments. Mehmet Adalier, Kotikalapudi Sriram, and Doug Montgomery 815 were instrumental in developing the test vectors found in Appendix A. 816 Additionally we want to thank Geoff Huston, author of [RFC5398] from 817 where we borrowed wording for Section 2.1 of this document. 819 Authors' Addresses 821 Sean Turner 822 sn3rd 824 Email: sean@sn3rd.com 826 Oliver Borchert 827 NIST 828 100 Bureau Drive 829 Gaithersburg, MD 20899 830 United States of America 832 Email: oliver.borchert@nist.gov