RFC 8608

BGPsec Algorithms, Key Formats, and Signature Formats

📅 published June 2019, from ietf

BGPsec Algorithms, Key Formats, and Signature Formats 💖

Internet Engineering Task Force (IETF) 🎀 Author: S. Turner (sn3rd) and O. Borchert (NIST) 💅 Request for Comments: 8608 🦋 Category: Standards Track ✨ Date: June 2019 🌸 Obsoletes: RFC 8208 🙈 Updates: RFC 7935 🫶 ISSN: 2070-1721 🧚

Abstract

okay so this doc is all about the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats that BGPsec (Border Gateway Protocol Security) uses 🔥 It 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") 💅 The glow-up comes from adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithm IDs so it fills the complete range, and restructuring the whole thing so it's easier to read ✨

It also has example BGPsec UPDATE messages, the private keys used to generate those messages, and the certificates you need to validate the signatures 🎀

Status of This Memo

this is an Internet Standards Track document 🌈

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 💖 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 for more on Internet Standards, check Section 2 of RFC 7841 📚

for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8608 🦋

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. ⭐

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, because 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 they are provided without warranty as described in the Simplified BSD License 💜

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
  1.2.  Changes from RFC 8208 . . . . . . . . . . . . . . . . . .   4
2.  Algorithms  . . . . . . . . . . . . . . . . . . . . . . . . .   4
  2.1.  Algorithm ID Types  . . . . . . . . . . . . . . . . . . .   4
  2.2.  Signature Algorithms  . . . . . . . . . . . . . . . . . .   6
    2.2.1.  Algorithm ID 0x01 (1) - (ECDSA P-256) . . . . . . . .   6
3.  Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . .   6
  3.1.  Asymmetric Key Pair for Algorithm ID 0x01 (1) - (ECDSA
        P-256)  . . . . . . . . . . . . . . . . . . . . . . . . .   6
    3.1.1.  Public Key Format . . . . . . . . . . . . . . . . . .   6
    3.1.2.  Private Key Format  . . . . . . . . . . . . . . . . .   7
4.  Signature Formats . . . . . . . . . . . . . . . . . . . . . .   7
5.  Additional Requirements . . . . . . . . . . . . . . . . . . .   7
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  12
  A.1.  Topology and Experiment Description . . . . . . . . . . .  12
  A.2.  Keys  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
  A.3.  BGPsec IPv4 . . . . . . . . . . . . . . . . . . . . . . .  16
  A.4.  BGPsec IPv6 . . . . . . . . . . . . . . . . . . . . . . .  18
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1. Introduction ✨

this doc specifies the following 💅

  • the digital signature algorithm and parameters,
  • the hash algorithm and parameters,
  • the algorithm identifier assignment and classification,
  • the public and private key formats, and
  • the signature formats

these are used by Resource Public Key Infrastructure (RPKI) Certification Authorities (CAs) and BGPsec (Border Gateway Protocol Security) speakers (aka routers) 🌸 CAs use these algorithms when they process requests for BGPsec Router Certificates [RFC8209]. BGPsec routers use them for things like requesting BGPsec certificates [RFC8209], signing BGPsec UPDATE messages [RFC8205], and verifying signatures on BGPsec UPDATE messages [RFC8205] 🔥

this doc updates [RFC7935] to add support for three things 🎀

  • a different algorithm for BGPsec certificate requests, which are issued only by BGPsec speakers,
  • a different Subject Public Key Info format for BGPsec certificates, which is needed for the specified BGPsec signature algorithm, and
  • different signature formats for BGPsec signatures, which are needed for the specified BGPsec signature algorithm.

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, which makes the certificates smaller 🧚 those algorithms also result in smaller signatures, which make the PDUs smaller too 💜

Appendix A (non-normative) has example BGPsec UPDATE messages, the private keys used to generate them, and the certificates needed to validate the signatures 🍓

1.1. Terminology 🌈

the caps-lock words below are the ones that matter 👑

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.

1.2. Changes from RFC 8208 🍓

this section lists the big changes between [RFC8208] and this doc 💖

  • Added Section 2.1 containing Algorithm ID types. The interpretation of these IDs is also described there.
  • Restructured Sections 2 and 3 to align with the corresponding algorithm suite identifier value.
  • Corrected the range for unassigned algorithm suite identifier values.
  • Added Documentation algorithm suite identifier values.
  • Added Experimentation algorithm suite identifier values.
  • Changed the next-hop IP in Appendix A's IPv6 example to use a private usage IPv6 address.

2. Algorithms 💅

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 covers the algorithms used by BGPsec [RFC8205] [DSS]. for example, BGPsec routers use these algorithms to sign and verify BGPsec UPDATE messages 🔥 to figure out which algorithm is being used, the BGPsec UPDATE message has the matching algorithm ID in each Signature_Block of the message 🦋

2.1. Algorithm ID Types 🎀

algorithms in BGPsec UPDATE messages are identified by the Algorithm Suite Identifier field (algorithm ID) inside the Signature_Block (see Section 3.2 of [RFC8205]) ✨

this doc specifies five types of Algorithm IDs 🌈

  • Reserved Algorithm ID 🙈

reserved algorithm IDs are the values 0x00 (0) and 0xFF (255). These IDs MUST NOT be used in a Signature_Block, and if one is encountered, the router MUST treat BGPsec UPDATE messages as malformed [RFC4271] 💀

  • Signature Algorithm ID 💖

signature algorithms are defined in Section 2.2 of this doc. Processing of BGPsec UPDATE signing and validation using signature algorithms is described at length in Sections 4.2 and 5.2 of [RFC8205] 📚

  • Unassigned Algorithm ID 🧚

this type of Algorithm ID is free for future assignments. It MUST NOT be used until an algorithm is officially assigned (see Section 7). If 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] 👑

  • Experimentation Algorithm ID 🧪

experimentation algorithm IDs span from 0xF7 (247) to 0xFA (250). To let experimentation accurately describe deployment examples, using publicly assigned algorithm IDs is inappropriate, and a reserved block of Experimentation algorithm IDs is required. This makes sure experimentation doesn't clash with assigned algorithm IDs in deployed networks, and it reduces the risks to operational integrity of the network from using experimentation to do 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] 💅

  • Documentation Algorithm ID 🌸

documentation algorithm IDs span from 0xFB (251) to 0xFE (254). To let documentation accurately describe deployment examples, using publicly assigned algorithm IDs is inappropriate, and a reserved block of Documentation algorithm IDs is required. This makes sure documentation doesn't clash with assigned algorithm IDs in deployed networks, and it reduces the risks to operational integrity of the network from using documentation to do 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] 🫶

2.2. Signature Algorithms 🦋

2.2.1. Algorithm ID 0x01 (1) - (ECDSA P-256) 💎

  • The signature algorithm used MUST be the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS].
  • The hash algorithm used MUST be SHA-256 [SHS].

hash algorithms aren't identified by themselves in certificates or BGPsec UPDATE messages 🥺 instead, they're represented by an OID that combines the hash algorithm with the digital signature algorithm, like this 🧁

  • 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 goes depends on the certificate request format that gets generated 🌈
  • 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 💜

3. Asymmetric Key Pair Formats 🔑

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 covers the key formats found in BGPsec Router Certificate requests and in BGPsec Router Certificates 🎀

more to come in part 2, bestie 💖

3.1. Asymmetric Key Pair for Algorithm ID 0x01 (1) - (ECDSA P-256) 🔑✨

Okay bestie, so the ECDSA private keys that sign 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. No cap, that's the whole rule 💅

3.1.1. Public Key Format 🗝️

The Subject's public key lives inside subjectPublicKeyInfo [RFC5280]. It has two sub-fields, algorithm and subjectPublicKey, and here's how they're set up:

  • 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].
  • subjectPublicKey: ECPoint MUST be used to encode the certificate's subjectPublicKey field, as specified in Section 2.2 of [RFC5480].

3.1.2. Private Key Format 🔐

Your local policy is the boss here 👑 It decides the private key format.

4. Signature Formats ✍️

The structure for the certificate's and CRL's signature field MUST be as specified in Section 4 of [RFC7935]. It's the same format every other RPKI certificate uses, which is so iconic for consistency 🎀 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].

5. Additional Requirements 🔄

BGPsec is expected to need updated key sizes and a different set of signature and hash algorithms over time, so it can keep an acceptable level of cryptographic security. This profile should be updated to specify those future requirements when appropriate 🌸

The recommended procedures for that transition of key sizes and algorithms are specified in [RFC6916].

6. Security Considerations 💀

Okay this section is SERIOUS, so pay attention 😭

No new security considerations are introduced as a result of this specification. Phew 🫶

7. IANA Considerations 🦋

The Internet Assigned Numbers Authority (IANA) created the "BGPsec Algorithm Suites" registry in the Resource Public Key Infrastructure (RPKI) group. The one-octet algorithm suite identifiers IANA assigns identify the digest algorithm and signature algorithm used in the BGPsec Signature_Block List's Algorithm Suite Identifier field 🌈

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]. That identifier is still valid, and IANA has updated the registration to refer to this document ✨

IANA changed the range of the "Unassigned" address space from "0x2-0xEF" to "0x02-0xF6":

  Algorithm   Digest          Signature       Specification
  Suite       Algorithm       Algorithm       Pointer
  Identifier
+------------+---------------+--------------+-----------------------+
| 0x02-0xF6  | Unassigned    | Unassigned   |                       |
+------------+---------------+--------------+-----------------------+

IANA also registered these address spaces for "Experimentation" and "Documentation":

  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 these values:

  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 made using the Standards Action process defined in [RFC8126]. Each assignment consists of the one-octet algorithm suite identifier value plus the associated digest algorithm name and signature algorithm name 🎀

8. References 📚

8.1. Normative References

8.2. Informative References

Appendix A. Examples 🎀

A.1. Topology and Experiment Description 🧚

Here's the topology:

AS(64496)----AS(65536)----AS(65537)

The prefix announcement is:

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. Ilysm this example, it's so clean 💖

A.2. Keys ✨

For this example, the ECDSA algorithm was given a static k so the result is deterministic. Bestie, that means the same inputs always produce the same signature, which is so helpful for testing 🧪💜

The k used for all signature operations was taken from [RFC6979], Appendix A.2.5, "Signatures With SHA-256, message = 'sample'". Iconic sourcing 📚🎀

Note: Even though the certificates below are expired, they are still useful within the constraint of this document. Expired but still useful, that's giving "vintage but make it functional" 👗🫶

  k = A6E3C57DD01ABE90086538398355DD4C
      3B17AA873382B0F24D6129493D8AAD60

Here are the keys for AS64496 🌸

Keys of AS64496:
================
ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154

private key:
  x = D8AA4DFBE2478F86E88A7451BF075565
      709C575AC1C136D081C540254CA440B9

public key:
  Ux = 7391BABB92A0CB3BE10E59B19EBFFB21
       4E04A91E0CBA1B139A7D38D90F77E55A
  Uy = A05B8E695678E0FA16904B55D9D4F5C0
       DFC58895EE50BC4F75D205A25BD36FF5

And here's the router key certificate for that same AS, made with OpenSSL 1.0.1e-fips 11 Feb 2013. It's giving "I printed my whole ID card" 🪪🍓

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-----

Now for AS(65536)! 👑

Keys of AS(65536):
==================
ski: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC

private key:
  x = 6CB2E931B112F24554BCDCAAFD9553A9
      519A9AF33C023B60846A21FC95583172

public key:
  Ux = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1
       E9D0E0DBEAEE425BD2F0D3175AA0E989
  Uy = EA9B603E38F35FB329DF495641F2BA04
       0F1C3AC6138307F257CBA6B8B588F41F

And its router key certificate, also made with OpenSSL 1.0.1e-fips 11 Feb 2013 🌈

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-----

A.3. BGPsec IPv4 🦋

Time for the main event: a BGPsec IPv4 UPDATE going from AS(65536) to AS(65537). Here is its binary form, straight from the TCP dump 🍿

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

Next up are the signatures. First, the one from AS(64496) to AS(65536) 🔐

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

And the one from AS(65536) to AS(65537) 💅

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 comes from bgpsec-io, a BGPsec traffic generator that uses a Wireshark-like printout. Honestly it's so easy to read, it's giving "the packet explained itself" 🧚

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

A.4. BGPsec IPv6 ✨

okay so this one is the IPv6 version of the same BGPsec UPDATE story, bestie 🦋 it's giving "same drama, new address family." the sender is AS(65536) and the receiver is AS(65537), and there's a full binary dump of the UPDATE first. no cap, the hex is kind of iconic 🫶

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 version is made with bgpsec-io, a BGPsec traffic generator that prints everything in a Wireshark-like way. it's so pretty to read 🎀

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 gave a huge shoutout to Geoff Huston and George Michaelson for making [RFC7935], which this whole document is entirely based on 💖 they also thanked Roque Gagliano, David Mandelberg, Tom Petch, Sam Weiler, and Stephen Kent for reviewing and commenting. Mehmet Adalier, Kotikalapudi Sriram, and Doug Montgomery were the ones who built the test vectors in Appendix A, so they get major credit 👑 and Geoff Huston again, since he wrote [RFC5398], which gave them the wording they borrowed for Section 2.1 of this document 🧚

Authors' Addresses 💌

Sean Turner sn3rd

Email: sean@sn3rd.com

Oliver Borchert NIST 100 Bureau Drive Gaithersburg, MD 20899 United States of America

Email: oliver.borchert@nist.gov

📦 where this page comes from