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