RFC 8208

BGPsec Algorithms, Key Formats, and Signature Formats

πŸ“… published September 2017, from ietf

RFC 8208: BGPsec Algorithms, Key Formats, and Signature Formats πŸŽ€

Okay bestie, let's get into it. This is RFC 8208, and it's a Standards Track doc from the IETF, so it's real official protocol stuff πŸ’…

It was written by S. Turner (sn3rd) and O. Borchert (NIST), it came out in September 2017, and its ISSN is 2070-1721 ✨ It updates RFC 7935, which is the profile for algorithms and key sizes in the Resource Public Key Infrastructure. πŸ¦‹

Abstract 🫢

So the whole point of this doc is to spell out the algorithms, algorithm parameters, asymmetric key formats, key sizes, and signature formats that BGPsec (Border Gateway Protocol Security) uses. It also updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") πŸ’–

It also comes with example BGPsec UPDATE messages, plus the private keys used to make those messages and the certificates you'd need to check the signatures. Iconic, right? πŸ”₯

Status of This Memo πŸ“œ

This is an Internet Standards Track document. πŸŽ€

It's a product of the Internet Engineering Task Force (IETF), so it represents what the IETF community agreed on. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more about Internet Standards, check Section 2 of RFC 7841 🌸

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8208 🧚

Copyright (c) 2017 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) as they stood on the publication date. Please actually read these, because they explain your rights and restrictions for this doc πŸ™ˆ If you pull Code Components out of this document, they have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes ✨

Table of Contents πŸ“

1. Introduction ....................................................3
   1.1. Terminology ................................................3
2. Algorithms ......................................................4
3. Asymmetric Key Pair Formats .....................................4
   3.1. Public Key Format ..........................................5
   3.2. Private Key Format .........................................5
4. Signature Formats ...............................................5
5. Additional Requirements .........................................5
6. Security Considerations .........................................5
7. IANA Considerations .............................................6
8. References ......................................................7
   8.1. Normative References .......................................7
   8.2. Informative References .....................................8
Appendix A. Examples ...............................................9
  A.1. Topology and Experiment Description .........................9
  A.2. Keys ........................................................9
  A.3. BGPsec IPv4 ................................................13
  A.4. BGPsec IPv6 ................................................16
Acknowledgements ..................................................19
Authors' Addresses ................................................19

1. Introduction ✨

This doc covers four things, bestie πŸ‘‘

  • the digital signature algorithm and its parameters,
  • the hash algorithm and its parameters,
  • the public and private key formats, and
  • the signature formats

Those are used by Resource Public Key Infrastructure (RPKI) Certification Authorities (CAs) and by BGPsec (Border Gateway Protocol Security) speakers, which are the routers (i.e., routers) πŸ¦‹ CAs use these algorithms when they process requests for BGPsec Router Certificates [RFC8209]. On the router side, BGPsec routers use them when they request BGPsec certificates [RFC8209], sign BGPsec UPDATE messages [RFC8205], and verify signatures on BGPsec UPDATE messages [RFC8205] 🌈

So this doc updates [RFC7935] to add three things. (a) A different algorithm for BGPsec certificate requests, which only BGPsec speakers issue. (b) A different Subject Public Key Info format for BGPsec certificates, which the specified BGPsec signature algorithm needs. (c) Different signature formats for BGPsec signatures, which the specified BGPsec signature algorithm also needs 🧚 BGPsec certificates are told apart from other RPKI certificates by the BGPsec Extended Key Usage, as defined in [RFC8209]. And BGPsec uses a different algorithm [RFC6090] [DSS] than the rest of the RPKI, so the protocol traffic between routers stays small πŸ“

Appendix A has example BGPsec UPDATE messages, the private keys used to make them, and the certificates you need to validate the signatures πŸ’–

1.1. Terminology πŸ’…

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, like they do here πŸŽ€

2. Algorithms 🌸

The algorithms that sign CA certificates, BGPsec Router Certificates, and Certificate Revocation Lists (CRLs) are the ones in Section 2 of [RFC7935]. This section is about the BGPsec algorithms. For example, BGPsec routers use these to request BGPsec certificates, RPKI CAs use them to verify BGPsec certification requests, and BGPsec routers use them to generate and verify BGPsec UPDATE messages 🫢

  • Okay so the signature algorithm MUST be the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS]. πŸ”₯
  • And the hash algorithm MUST be SHA-256 [SHS]. πŸ’…

Hash algorithms don't get identified on their own 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]. Which one you use depends on the certificate request format you generated 🧚
  • In BGPsec UPDATE messages, the ECDSA with SHA-256 algorithm suite identifier value 0x1 (see Section 7) goes in the Signature_Block List's Algorithm Suite Identifier field ✨
Part 1 of 3 is done, bestie πŸŽ€ Part 2 picks up at Section 3, Asymmetric Key Pair Formats, so keep your eyes peeled πŸ‘€πŸ’œ

8.1. Normative References

Okay bestie, this is the homework list πŸ“š These are the docs the spec leans on the hardest, so they count as "you need these to get it" reads 🫢

8.2. Informative References

Extra credit reading 🧚 This one's not required, but it's a really good hang if you want the deep dive πŸ’œ


Appendix A. Examples ✨

Okay, this is the part where we get to play with real data πŸŽ€ Everything below is a worked example, so you can see what the formats look like in the wild.

A.1. Topology and Experiment Description

Picture a tiny little network: three ASes chained together in a line, with one of them making an announcement. Cute and simple πŸ¦‹

Topology:

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

Prefix Announcement: AS(64496), 192.0.2.0/24, 2001:db8::/32

A.2. Keys

For this example, we gave the ECDSA algorithm a static k so the result comes out the same every single time πŸ” That makes it way easier to check your work bestie πŸ’…

Every signature operation used the k pulled from [RFC6979], Appendix A.2.5, "Signatures With SHA-256, message = 'sample'". Here it is:

k = A6E3C57DD01ABE90086538398355DD4C
    3B17AA873382B0F24D6129493D8AAD60

Next up, the keys for AS64496 and the router key certificate that goes with them 🌸

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

private key:
  x = D8AA4DFBE2478F86E88A7451BF075565
      709C575AC1C136D081C540254CA440B9

public key:
  Ux = 7391BABB92A0CB3BE10E59B19EBFFB21
       4E04A91E0CBA1B139A7D38D90F77E55A
  Uy = A05B8E695678E0FA16904B55D9D4F5C0
       DFC58895EE50BC4F75D205A25BD36FF5
Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013
--------------------------------------------------------------------
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 38655612 (0x24dd67c)
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=ROUTER-0000FBF0
        Validity
            Not Before: Jan  1 05:00:00 2017 GMT
            Not After : Jul  1 05:00:00 2018 GMT
        Subject: CN=ROUTER-0000FBF0
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:73:91:ba:bb:92:a0:cb:3b:e1:0e:59:b1:9e:bf:
                    fb:21:4e:04:a9:1e:0c:ba:1b:13:9a:7d:38:d9:0f:
                    77:e5:5a:a0:5b:8e:69:56:78:e0:fa:16:90:4b:55:
                    d9:d4:f5:c0:df:c5:88:95:ee:50:bc:4f:75:d2:05:
                    a2:5b:d3:6f:f5
                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Key Usage:
                Digital Signature
            X509v3 Subject Key Identifier:
                AB:4D:91:0F:55:CA:E7:1A:21:5E:
                F3:CA:FE:3A:CC:45:B5:EE:C1:54
            X509v3 Extended Key Usage:
                1.3.6.1.5.5.7.3.30
            sbgp-autonomousSysNum: critical
                Autonomous System Numbers:
                  64496
                Routing Domain Identifiers:
                  inherit

    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:07:b7:b4:6a:5f:a4:f1:cc:68:36:39:03:a4:83:
         ec:7c:80:02:d2:f6:08:9d:46:b2:ec:2a:7b:e6:92:b3:6f:b1:
         02:20:00:91:05:4a:a1:f5:b0:18:9d:27:24:e8:b4:22:fd:d1:
         1c:f0:3d:b1:38:24:5d:64:29:35:28:8d:ee:0c:38:29
-----BEGIN CERTIFICATE-----
MIIBiDCCAS+gAwIBAgIEAk3WfDAKBggqhkjOPQQDAjAaMRgwFgYDVQQDDA9ST1VU
RVItMDAwMEZCRjAwHhcNMTcwMTAxMDUwMDAwWhcNMTgwNzAxMDUwMDAwWjAaMRgw
FgYDVQQDDA9ST1VURVItMDAwMEZCRjAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AARzkbq7kqDLO+EOWbGev/shTgSpHgy6GxOafTjZD3flWqBbjmlWeOD6FpBLVdnU
9cDfxYiV7lC8T3XSBaJb02/1o2MwYTALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFKtN
kQ9VyucaIV7zyv46zEW17sFUMBMGA1UdJQQMMAoGCCsGAQUFBwMeMB4GCCsGAQUF
BwEIAQH/BA8wDaAHMAUCAwD78KECBQAwCgYIKoZIzj0EAwIDRwAwRAIgB7e0al+k
8cxoNjkDpIPsfIAC0vYInUay7Cp75pKzb7ECIACRBUqh9bAYnSck6LQi/dEc8D2x
OCRdZCk1KI3uDDgp
-----END CERTIFICATE-----

Now the same deal for AS(65536) πŸ’– Keys first, then its certificate:

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

private key:
  x = 6CB2E931B112F24554BCDCAAFD9553A9
      519A9AF33C023B60846A21FC95583172

public key:
  Ux = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1
       E9D0E0DBEAEE425BD2F0D3175AA0E989
  Uy = EA9B603E38F35FB329DF495641F2BA04
       0F1C3AC6138307F257CBA6B8B588F41F
Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013
--------------------------------------------------------------------
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3752143940 (0xdfa52c44)
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=ROUTER-00010000
        Validity
            Not Before: Jan  1 05:00:00 2017 GMT
            Not After : Jul  1 05:00:00 2018 GMT
        Subject: CN=ROUTER-00010000
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:28:fc:5f:e9:af:cf:5f:4c:ab:3f:5f:85:cb:21:
                    2f:c1:e9:d0:e0:db:ea:ee:42:5b:d2:f0:d3:17:5a:
                    a0:e9:89:ea:9b:60:3e:38:f3:5f:b3:29:df:49:56:
                    41:f2:ba:04:0f:1c:3a:c6:13:83:07:f2:57:cb:a6:
                    b8:b5:88:f4:1f
                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Key Usage:
                Digital Signature
            X509v3 Subject Key Identifier:
                47:F2:3B:F1:AB:2F:8A:9D:26:86:
                4E:BB:D8:DF:27:11:C7:44:06:EC
            X509v3 Extended Key Usage:
                1.3.6.1.5.5.7.3.30
            sbgp-autonomousSysNum: critical
                Autonomous System Numbers:
                  65536
                Routing Domain Identifiers:
                  inherit

    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:21:00:8c:d9:f8:12:96:88:82:74:03:a1:82:82:18:
         c5:31:00:ee:35:38:e8:fa:ae:72:09:fe:98:67:01:78:69:77:
         8c:02:20:5f:ee:3a:bf:10:66:be:28:d3:b3:16:a1:6b:db:66:
         21:99:ed:a6:e4:ad:64:3c:ba:bf:44:fb:cb:b7:50:91:74
-----BEGIN CERTIFICATE-----
MIIBijCCATCgAwIBAgIFAN+lLEQwCgYIKoZIzj0EAwIwGjEYMBYGA1UEAwwPUk9V
VEVSLTAwMDEwMDAwMB4XDTE3MDEwMTA1MDAwMFoXDTE4MDcwMTA1MDAwMFowGjEY
MBYGA1UEAwwPUk9VVEVSLTAwMDEwMDAwMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcD
QgAEKPxf6a/PX0yrP1+FyyEvwenQ4Nvq7kJb0vDTF1qg6Ynqm2A+OPNfsynfSVZB
8roEDxw6xhODB/JXy6a4tYj0H6NjMGEwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBRH
8jvxqy+KnSaGTrvY3ycRx0QG7DATBgNVHSUEDDAKBggrBgEFBQcDHjAeBggrBgEF
BQcBCAEB/wQPMA2gBzAFAgMBAAChAgUAMAoGCCqGSM49BAMCA0gAMEUCIQCM2fgS
loiCdAOhgoIYxTEA7jU46Pqucgn+mGcBeGl3jAIgX+46vxBmvijTsxaha9tmIZnt
puStZDy6v0T7y7dQkXQ=
-----END CERTIFICATE-----

Appendix A. Examples ✨

A.3. BGPsec IPv4 πŸ¦‹

okay bestie, A.3 is the IPv4 one and it's giving full BGPsec UPDATE glow-up πŸ’… the message goes from AS(65536) to AS(65537), and the binary dump is the raw tcpdump-style bytes. no cap, it's gorgeous 😭

BGPsec IPv4 UPDATE from AS(65536) to AS(65537):
===============================================
Binary Form of BGPsec UPDATE (TCP-DUMP):

FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF
01 03 02 00 00 00 EC 40  01 01 02 80 04 04 00 00
00 00 80 0E 0D 00 01 01  04 C6 33 64 64 00 18 C0
00 02 90 1E 00 CD 00 0E  01 00 00 01 00 00 01 00
00 00 FB F0 00 BF 01 47  F2 3B F1 AB 2F 8A 9D 26
86 4E BB D8 DF 27 11 C7  44 06 EC 00 48 30 46 02
21 00 EF D4 8B 2A AC B6  A8 FD 11 40 DD 9C D4 5E
81 D6 9D 2C 87 7B 56 AA  F9 91 C3 4D 0E A8 4E AF
37 16 02 21 00 90 F2 C1  29 AB B2 F3 9B 6A 07 96
3B D5 55 A8 7A B2 B7 33  3B 7B 91 F1 66 8F D8 61
8C 83 FA C3 F1 AB 4D 91  0F 55 CA E7 1A 21 5E F3
CA FE 3A CC 45 B5 EE C1  54 00 48 30 46 02 21 00
EF D4 8B 2A AC B6 A8 FD  11 40 DD 9C D4 5E 81 D6
9D 2C 87 7B 56 AA F9 91  C3 4D 0E A8 4E AF 37 16
02 21 00 8E 21 F6 0E 44  C6 06 6C 8B 8A 95 A3 C0
9D 3A D4 37 95 85 A2 D7  28 EE AD 07 A1 7E D7 AA
05 5E CA

Signature from AS(64496) to AS(65536):
--------------------------------------
Digest:    21 33 E5 CA A0 26 BE 07   3D 9C 1B 4E FE B9 B9 77
           9F 20 F8 F5 DE 29 FA 98   40 00 9F 60 47 D0 81 54
Signature: 30 46 02 21 00 EF D4 8B   2A AC B6 A8 FD 11 40 DD
           9C D4 5E 81 D6 9D 2C 87   7B 56 AA F9 91 C3 4D 0E
           A8 4E AF 37 16 02 21 00   8E 21 F6 0E 44 C6 06 6C
           8B 8A 95 A3 C0 9D 3A D4   37 95 85 A2 D7 28 EE AD
           07 A1 7E D7 AA 05 5E CA

Signature from AS(65536) to AS(65537):
--------------------------------------
Digest:    01 4F 24 DA E2 A5 21 90   B0 80 5C 60 5D B0 63 54
           22 3E 93 BA 41 1D 3D 82   A3 EC 26 36 52 0C 5F 84
Signature: 30 46 02 21 00 EF D4 8B   2A AC B6 A8 FD 11 40 DD
           9C D4 5E 81 D6 9D 2C 87   7B 56 AA F9 91 C3 4D 0E
           A8 4E AF 37 16 02 21 00   90 F2 C1 29 AB B2 F3 9B
           6A 07 96 3B D5 55 A8 7A   B2 B7 33 3B 7B 91 F1 66
           8F D8 61 8C 83 FA C3 F1

the human-readable version is made with bgpsec-io, which is a bgpsec traffic generator that prints things in a wireshark-like way 🧚 so you can actually read it, periodt πŸŽ€

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 🌈

and now the IPv6 version, which is the same UPDATE vibe but with a 2001:db8 prefix and a longer NLRI. it's the same two signers (AS(64496) and AS(65536)), so the signature segments look familiar, just with different bytes at the end 🫢

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 20 01 00 10 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

same deal with the readable printout, bgpsec-io does the wireshark-style version πŸ“

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: 2001:0010: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 wanted to shoutout Geoff Huston and George Michaelson for making [RFC7935], which this whole doc is basically built on πŸ’– they also thanked Roque Gagliano, David Mandelberg, Tom Petch, Sam Weiler, and Stephen Kent for reviewing and commenting. and Mehmet Adalier, Kotikalapudi Sriram, and Doug Montgomery were the MVPs who helped build the test vectors in Appendix A πŸ‘‘

Authors' Addresses πŸ’Œ

here's where you can find the authors, bestie 🧚

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