draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04.txt   draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05.txt 
Internet Engineering Task Force (IETF) S. Turner Internet Engineering Task Force (IETF) S. Turner
Internet-Draft sn3rd Internet-Draft sn3rd
Updates: 8208 (if approved) O. Borchert Obsoletes: 8208 (if approved) O. Borchert
Intended status: Standards Track NIST Intended status: Standards Track NIST
Expires: June 6, 2019 December 3, 2018 Expires: October 17, 2019 April 15, 2019
BGPsec Algorithms, Key Formats, and Signature Formats BGPsec Algorithms, Key Formats, and Signature Formats
draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05
Abstract Abstract
This document specifies the algorithms, algorithm parameters, This document specifies the algorithms, algorithm parameters,
asymmetric key formats, asymmetric key sizes, and signature formats asymmetric key formats, asymmetric key sizes, and signature formats
used in BGPsec (Border Gateway Protocol Security). This document used in BGPsec (Border Gateway Protocol Security). This document
updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature
Formats") by adding Special-Use Algorithm IDs and correcting the Formats") by adding Documentation Algorithm IDs, Experimentation
range of unassigned algorithms IDs to fill the complete range. Algorithm IDs, correcting the range of unassigned algorithms IDs to
fill the complete range, and restructured the document for better
reading.
This document also includes example BGPsec UPDATE messages as well as This document also includes example BGPsec UPDATE messages as well as
the private keys used to generate the messages and the certificates the private keys used to generate the messages and the certificates
necessary to validate those signatures. necessary to validate those signatures.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 2, 2018 This Internet-Draft will expire on August 2, 2018
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes from RFC 8208 . . . . . . . . . . . . . . . . . . 4 1.2. Changes from RFC 8208 . . . . . . . . . . . . . . . . . . 4
2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Algorithm ID Types . . . . . . . . . . . . . . . . . . . . 4 2.1. Algorithm ID Types . . . . . . . . . . . . . . . . . . . . 4
2.2. Signature Algorithms . . . . . . . . . . . . . . . . . . . 5 2.2. Signature Algorithms . . . . . . . . . . . . . . . . . . . 6
2.2.1. Algorithm ID 0x01 - (ECDSA-P256) . . . . . . . . . . . 5 2.2.1. Algorithm ID 0x01 (1) - (ECDSA-P256) . . . . . . . . . 6
3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . 6 3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . 6
3.1. Asymmetric Key Pair for Algorithm ID 0x01 - (ECDSA-P256) . 6 3.1. Asymmetric Key Pair for Algorithm ID 0x01 (1) -
(ECDSA-P256) . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Public Key Format . . . . . . . . . . . . . . . . . . 6 3.1.1. Public Key Format . . . . . . . . . . . . . . . . . . 6
3.1.2. Private Key Format . . . . . . . . . . . . . . . . . . 6 3.1.2. Private Key Format . . . . . . . . . . . . . . . . . . 7
4. Signature Formats . . . . . . . . . . . . . . . . . . . . . . 6 4. Signature Formats . . . . . . . . . . . . . . . . . . . . . . 7
5. Additional Requirements . . . . . . . . . . . . . . . . . . . 6 5. Additional Requirements . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13
A.1. Topology and Experiment Description . . . . . . . . . . . 12 A.1. Topology and Experiment Description . . . . . . . . . . . 13
A.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 A.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.3. BGPsec IPv4 . . . . . . . . . . . . . . . . . . . . . . . 16 A.3. BGPsec IPv4 . . . . . . . . . . . . . . . . . . . . . . . 17
A.4. BGPsec IPv6 . . . . . . . . . . . . . . . . . . . . . . . 19 A.4. BGPsec IPv6 . . . . . . . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document specifies the following: This document specifies the following:
o the digital signature algorithm and parameters, o the digital signature algorithm and parameters,
o the hash algorithm and parameters, o the hash algorithm and parameters,
o the algorithm identifier assignment and classification, o the algorithm identifier assignment and classification,
skipping to change at page 3, line 36 skipping to change at page 3, line 36
This document updates [RFC7935] to add support for a) a different This document updates [RFC7935] to add support for a) a different
algorithm for BGPsec certificate requests, which are issued only by algorithm for BGPsec certificate requests, which are issued only by
BGPsec speakers; b) a different Subject Public Key Info format for BGPsec speakers; b) a different Subject Public Key Info format for
BGPsec certificates, which is needed for the specified BGPsec BGPsec certificates, which is needed for the specified BGPsec
signature algorithm; and c) different signature formats for BGPsec signature algorithm; and c) different signature formats for BGPsec
signatures, which are needed for the specified BGPsec signature signatures, which are needed for the specified BGPsec signature
algorithm. The BGPsec certificates are differentiated from other algorithm. The BGPsec certificates are differentiated from other
RPKI certificates by the use of the BGPsec Extended Key Usage as RPKI certificates by the use of the BGPsec Extended Key Usage as
defined in [RFC8209]. BGPsec uses a different algorithm [RFC6090] defined in [RFC8209]. BGPsec uses a different algorithm [RFC6090]
[DSS] as compared to the rest of the RPKI by using a different [DSS] as compared to the rest of the RPKI that provides similar
algorithm that provides similar security with smaller keys making the security with smaller keys making the certificates smaller; these
certificates smaller; these algorithms also result in smaller algorithms also result in smaller signatures, which makes the PDUs
signatures, which makes the PDUs smaller. smaller.
Appendix A contains example BGPsec UPDATE messages as well as the Appendix A (non-normative) contains example BGPsec UPDATE messages as
private keys used to generate the messages and the certificates well as the private keys used to generate the messages and the
necessary to validate the signatures. certificates necessary to validate the signatures.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Changes from RFC 8208 1.2. Changes from RFC 8208
skipping to change at page 4, line 19 skipping to change at page 4, line 19
o Added Section 2.1 of algorithm ID types. Also, the interpretation o Added Section 2.1 of algorithm ID types. Also, the interpretation
of these IDs is described. of these IDs is described.
o Restructured Sections 2 and 3 to align with the corresponding o Restructured Sections 2 and 3 to align with the corresponding
algorithm suite identifier value. algorithm suite identifier value.
o Correction of range for unassigned algorithm suite identifier o Correction of range for unassigned algorithm suite identifier
values. values.
o Adding of Special-Use algorithm suite identifier values. o Adding of Documentation algorithm suite identifier values.
o Adding of Experimentation algorithm suite identifier values.
o Changed Next-HOP IP in Appendix A's IPv6 Example to use private
usage IPv6 address.
2. Algorithms 2. Algorithms
The algorithms used to compute signatures on CA certificates, The algorithms used to compute signatures on CA certificates, BGPsec
BGPsec Router Certificates, and Certificate Revocation Lists Router Certificates, and Certificate Revocation Lists (CRLs) are as
(CRLs) are as specified in Section 2 of [RFC7935]. This section specified in Section 2 of [RFC7935]. This section addresses BGPsec
addresses BGPsec algorithms; for example, these algorithms are algorithms used by BGPsec [RFC8205] [DSS]. For example, these
used by BGPsec routers to sign and verify BGPsec UPDATE messages. algorithms are used by BGPsec routers to sign and verify BGPsec
To identify which algorithm is used, the BGPsec UPDATE message UPDATE messages. To identify which algorithm is used, the BGPsec
contains the corresponding algorithm ID in each Signature_Block of UPDATE message contains the corresponding algorithm ID in each
the BGPsec UPDATE message. Signature_Block of the BGPsec UPDATE message.
2.1. Algorithm ID Types 2.1. Algorithm ID Types
Algorithms in BGPsec UPDATE messages are identified by the Algorithms in BGPsec UPDATE messages are identified by the Algorithm
Algorithm Suite Identifier field (Algorithm ID) within the Suite Identifier field (Algorithm ID) within the Signature_Block (see
Signature_Block (see Section 3.2 of [RFC8205]). Section 3.2 of [RFC8205]).
This document specifies four types of algorithm IDs: This document specifies five types of algorithm IDs:
o Reserved Algorithm ID o Reserved Algorithm ID
Reserved algorithm IDs are the values 0x00 and 0xFF. These IDs Reserved algorithm IDs are the values 0x00 (0) and 0xFF (255).
MUST NOT be used in a Signature_Block and if encountered, the These IDs MUST NOT be used in a Signature_Block and if
router MUST treat BGPsec UPDATE messages as Malformed [RFC4271]. encountered, the router MUST treat BGPsec UPDATE messages as
Malformed [RFC4271].
o Signature Algorithm ID o Signature Algorithm ID
Signature algorithms are defined in Section 2.2 of this document. Signature algorithms are defined in Section 2.2 of this document.
Processing of BGPsec UPDATE signing and validation using signature Processing of BGPsec UPDATE signing and validation using signature
algorithms is described in length in Section 4.2 and Section 5.2 algorithms is described in length in Section 4.2 and Section 5.2
of [RFC8205]. of [RFC8205].
o Unassigned Algorithm ID o Unassigned Algorithm ID
This type of algorithm ID is free for future assignments and MUST This type of algorithm ID is free for future assignments and MUST
NOT be used until an algorithm is officially assigned (see NOT be used until an algorithm is officially assigned (see
Section 7). In case a router encounters an unassigned algorithm Section 7). In case a router encounters an unassigned algorithm
ID in one of the Signature_Blocks of a BGPsec UPDATE message, the ID in one of the Signature_Blocks of a BGPsec UPDATE message, the
router SHOULD process the Signature_Block as router SHOULD process the Signature_Block as
"unsupported algorithm" as specified in Section 5.2 of [RFC8205]. "unsupported algorithm" as specified in Section 5.2 of [RFC8205].
o Special-Use Algorithm ID o Experimentation Algorithm ID
Special-Use algorithm IDs span from 0xFA (250) to 0xFE (254). To Experimentation algorithm IDs span from 0xF7 (247) to 0xFA (250).
allow documentation and experimentation to accurately describe To allow experimentation to accurately describe deployment
deployment examples, the use of publicly assigned algorithm IDs is examples, the use of publicly assigned algorithm IDs is
inappropriate, and a reserved block of Special-Use algorithm IDs inappropriate, and a reserved block of Experimentation algorithm
is required. This ensures that documentation and experimentation IDs is required. This ensures that experimentation does not clash
does not clash with assigned algorithm IDs in deployed networks, with assigned algorithm IDs in deployed networks, and mitigates
and mitigates the risks to operational integrity of the network the risks to operational integrity of the network through
through inappropriate use of documentation to perform literal inappropriate use of experimentation to perform literal
configuration of routing elements on production systems. A router configuration of routing elements on production systems. A router
that encounters an algorithm ID of this type outside of an that encounters an algorithm ID of this type outside of an
experimental network, SHOULD treat it the same as experimental network, SHOULD treat it the same as
"unsupported algorithm" as specified in Section 5.2 of [RFC8205]. "unsupported algorithm" as specified in Section 5.2 of [RFC8205].
o Documentation Algorithm ID
Documentation algorithm IDs span from 0xFB (251) to 0xFE (254).
To allow documentation to accurately describe deployment examples,
the use of publicly assigned algorithm IDs is inappropriate, and a
reserved block of Documentation algorithm IDs is required. This
ensures that documentation does not clash with assigned algorithm
IDs in deployed networks, and mitigates the risks to operational
integrity of the network through inappropriate use of
documentation to perform literal configuration of routing elements
on production systems. A router that encounters an algorithm ID
of this type SHOULD treat it the same as "unsupported algorithm"
as specified in Section 5.2 of [RFC8205].
2.2. Signature Algorithms 2.2. Signature Algorithms
2.2.1. Algorithm ID 0x01 - (ECDSA-P256) 2.2.1. Algorithm ID 0x01 (1) - (ECDSA-P256)
o The signature algorithm used MUST be the Elliptic Curve Digital o The signature algorithm used MUST be the Elliptic Curve Digital
Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS]. Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS].
o The hash algorithm used MUST be SHA-256 [SHS]. o The hash algorithm used MUST be SHA-256 [SHS].
Hash algorithms are not identified by themselves in certificates or Hash algorithms are not identified by themselves in certificates or
BGPsec UPDATE messages. They are represented by an OID that combines BGPsec UPDATE messages. They are represented by an OID that combines
the hash algorithm with the digital signature algorithm as follows: the hash algorithm with the digital signature algorithm as follows:
o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the Public-Key o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the Public-Key
Cryptography Standards #10 (PKCS #10) signatureAlgorithm field Cryptography Standards #10 (PKCS #10) signatureAlgorithm field
[RFC2986] or in the Certificate Request Message Format (CRMF) [RFC2986] or in the Certificate Request Message Format (CRMF)
POPOSigningKey algorithm field [RFC4211]; where the OID is placed POPOSigningKey algorithm field [RFC4211]; where the OID is placed
depends on the certificate request format generated. depends on the certificate request format generated.
o In BGPsec UPDATE messages, the ECDSA with SHA-256 algorithm suite o In BGPsec UPDATE messages, the ECDSA with SHA-256 algorithm suite
identifier value 0x01 (see Section 7) is included in the identifier value 0x01 (1) (see Section 7) is included in the
Signature_Block List's Algorithm Suite Identifier field. Signature_Block List's Algorithm Suite Identifier field.
3. Asymmetric Key Pair Formats 3. Asymmetric Key Pair Formats
The key formats used to compute signatures on CA certificates, BGPsec The key formats used to compute signatures on CA certificates, BGPsec
Router Certificates, and CRLs are as specified in Section 3 of Router Certificates, and CRLs are as specified in Section 3 of
[RFC7935]. This section addresses key formats found in the BGPsec [RFC7935]. This section addresses key formats found in the BGPsec
Router Certificate requests and in BGPsec Router Certificates. Router Certificate requests and in BGPsec Router Certificates.
3.1. Asymmetric Key Pair for Algorithm ID 0x01 - (ECDSA-P256) 3.1. Asymmetric Key Pair for Algorithm ID 0x01 (1) - (ECDSA-P256)
The ECDSA private keys used to compute signatures for certificate The ECDSA private keys used to compute signatures for certificate
requests and BGPsec UPDATE messages MUST be associated with the P-256 requests and BGPsec UPDATE messages MUST be associated with the P-256
curve domain parameters [RFC5480]. The public key pair MUST use the curve domain parameters [RFC5480]. The public key pair MUST use the
uncompressed form. uncompressed form.
3.1.1. Public Key Format 3.1.1. Public Key Format
The Subject's public key is included in subjectPublicKeyInfo The Subject's public key is included in subjectPublicKeyInfo
[RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey.
skipping to change at page 7, line 27 skipping to change at page 8, line 14
7. IANA Considerations 7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) has created the The Internet Assigned Numbers Authority (IANA) has created the
"BGPsec Algorithm Suite Registry" in the Resource Public Key "BGPsec Algorithm Suite Registry" in the Resource Public Key
Infrastructure (RPKI) group. The one-octet "BGPsec Algorithm Suite Infrastructure (RPKI) group. The one-octet "BGPsec Algorithm Suite
Registry" identifiers assigned by IANA identify the digest algorithm Registry" identifiers assigned by IANA identify the digest algorithm
and signature algorithm used in the BGPsec Signature_Block List's and signature algorithm used in the BGPsec Signature_Block List's
Algorithm Suite Identifier field. Algorithm Suite Identifier field.
IANA has registered a single algorithm suite identifier for the [RFC8208] directed IANA to register a single algorithm suite
digest algorithm SHA-256 [SHS] and for the signature algorithm ECDSA identifier for the digest algorithm SHA-256 [SHS] and for the
on the P-256 curve [RFC6090] [DSS]. signature algorithm ECDSA on the P-256 curve [RFC6090] [DSS]. This
identifier is still valid, and IANA has updated registration to refer
to this document.
IANA is asked to modify the previously registered "Unassigned" IANA is asked to modify the previously registered "Unassigned"
address space. address space.
Algorithm Digest Signature Specification Algorithm Digest Signature Specification
Suite Algorithm Algorithm Pointer Suite Algorithm Algorithm Pointer
Identifier Identifier
+------------+---------------+--------------+-----------------------+ +------------+---------------+--------------+-----------------------+
| 0x2-0xEF | Unassigned | Unassigned | | | 0x2-0xEF | Unassigned | Unassigned | |
+------------+---------------+--------------+-----------------------+ +------------+---------------+--------------+-----------------------+
To be modified to: To be modified to:
Algorithm Digest Signature Specification Algorithm Digest Signature Specification
Suite Algorithm Algorithm Pointer Suite Algorithm Algorithm Pointer
Identifier Identifier
+------------+---------------+--------------+-----------------------+ +------------+---------------+--------------+-----------------------+
| 0x2-0xFA | Unassigned | Unassigned | | | 0x02-0xF6 | Unassigned | Unassigned | |
+------------+---------------+--------------+-----------------------+ +------------+---------------+--------------+-----------------------+
In addition IANA is asked to register the following address space for In addition IANA is asked to register the following address space for
"Special-Use": "Documentation" and "Experimentation":
Algorithm Digest Signature Specification Algorithm Digest Signature Specification
Suite Algorithm Algorithm Pointer Suite Algorithm Algorithm Pointer
Identifier Identifier
+------------+---------------+--------------+-----------------------+ +------------+-----------------+-----------------+------------------+
| 0xFB-0xFE | Special-Use | Special-Use | This Document | | 0xF7-0xFA | Experimentation | Experimentation | This Document |
+------------+---------------+--------------+-----------------------+ +------------+-----------------+-----------------+------------------+
| 0xFB-0xFE | Documentation | Documentation | This Document |
+------------+-----------------+-----------------+------------------+
After the requested modification, the "BGPsec Algorithm Suite After the requested modification, the "BGPsec Algorithm Suite
Registry" in the RPKI group should contain the following values: Registry" in the RPKI group should contain the following values:
BGPsec Algorithm Suite Registry BGPsec Algorithm Suite Registry
Algorithm Digest Signature Specification Algorithm Digest Signature Specification
Suite Algorithm Algorithm Pointer Suite Algorithm Algorithm Pointer
Identifier Identifier
+------------+---------------+--------------+-----------------------+ +------------+-----------------+-----------------+------------------+
| 0x00 | Reserved | Reserved | This document | | 0x00 | Reserved | Reserved | This document |
+------------+---------------+--------------+-----------------------+ +------------+-----------------+-----------------+------------------+
| 0x01 | SHA-256 | ECDSA P-256 | [SHS] [DSS] [RFC6090] | | 0x01 | SHA-256 | ECDSA P-256 | [SHS] [DSS] |
| | | | This document | | | | | [RFC6090] |
+------------+---------------+--------------+-----------------------+ | | | | This document |
| 0x02-0xFA | Unassigned | Unassigned | | +------------+-----------------+-----------------+------------------+
+------------+---------------+--------------+-----------------------+ | 0x02-0xF6 | Unassigned | Unassigned | |
| 0xFB-0xFE | Special-Use | Special-Use | This Document | +------------+-----------------+-----------------+------------------+
+------------+---------------+--------------+-----------------------+ | 0xF7-0xFA | Experimentation | Experimentation | This Document |
| 0xFF | Reserved | Reserved | This document | +------------+-----------------+-----------------+------------------+
+------------+---------------+--------------+-----------------------+ | 0xFB-0xFE | Documentation | Documentation | This Document |
+------------+-----------------+-----------------+------------------+
| 0xFF | Reserved | Reserved | This document |
+------------+-----------------+-----------------+------------------+
Future assignments are to be made using the Standards Action process Future assignments are to be made using the Standards Action process
defined in [RFC8126]. Assignments consist of the one-octet algorithm defined in [RFC8126]. Assignments consist of the one-octet algorithm
suite identifier value and the associated digest algorithm name and suite identifier value and the associated digest algorithm name and
signature algorithm name. signature algorithm name.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 12, line 16 skipping to change at page 13, line 16
A.1. Topology and Experiment Description A.1. Topology and Experiment Description
Topology: Topology:
AS(64496)----AS(65536)----AS(65537) AS(64496)----AS(65536)----AS(65537)
Prefix Announcement: AS(64496), 192.0.2.0/24, 2001:db8::/32 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 The signature algorithm used in this example is ECDSA P-256 using the
algorithm suite identifier ID 0x01 as specified in Section 7 of this algorithm suite identifier ID 0x01 (1) as specified in Section 7 of
document. this document.
A.2. Keys A.2. Keys
For this example, the ECDSA algorithm was provided with a static k to For this example, the ECDSA algorithm was provided with a static k to
make the result deterministic. make the result deterministic.
The k used for all signature operations was taken from [RFC6979], The k used for all signature operations was taken from [RFC6979],
Appendix A.2.5, "Signatures With SHA-256, message = 'sample'". Appendix A.2.5, "Signatures With SHA-256, message = 'sample'".
Note: Even though the certificates below are expired, the are still
useful within the constraint of this document.
k = A6E3C57DD01ABE90086538398355DD4C k = A6E3C57DD01ABE90086538398355DD4C
3B17AA873382B0F24D6129493D8AAD60 3B17AA873382B0F24D6129493D8AAD60
Keys of AS64496: Keys of AS64496:
================ ================
ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154 ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154
private key: private key:
x = D8AA4DFBE2478F86E88A7451BF075565 x = D8AA4DFBE2478F86E88A7451BF075565
709C575AC1C136D081C540254CA440B9 709C575AC1C136D081C540254CA440B9
skipping to change at page 19, line 13 skipping to change at page 20, line 13
07A17ED7AA055ECA 07A17ED7AA055ECA
A.4. BGPsec IPv6 A.4. BGPsec IPv6
BGPsec IPv6 UPDATE from AS(65536) to AS(65537): BGPsec IPv6 UPDATE from AS(65536) to AS(65537):
=============================================== ===============================================
Binary Form of BGP/BGPsec UPDATE (TCP-DUMP): Binary Form of BGP/BGPsec UPDATE (TCP-DUMP):
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 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 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 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 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 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 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 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 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 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 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 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 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 CC 45 B5 EE C1 54 00 48 30 46 02 21 00 EF D4 8B
skipping to change at page 20, line 31 skipping to change at page 21, line 31
| +--Type Code: MULTI_EXIT_DISC (4) | +--Type Code: MULTI_EXIT_DISC (4)
| +--Length: 4 bytes | +--Length: 4 bytes
| +--data: 00 00 00 00 | +--data: 00 00 00 00
+--MP_REACH_NLRI (29 bytes) +--MP_REACH_NLRI (29 bytes)
| +--Flags: 0x80 (Optional, Non-transitive, Complete) | +--Flags: 0x80 (Optional, Non-transitive, Complete)
| +--Type Code: MP_REACH_NLRI (14) | +--Type Code: MP_REACH_NLRI (14)
| +--Length: 26 bytes | +--Length: 26 bytes
| +--Address family: IPv6 (2) | +--Address family: IPv6 (2)
| +--Subsequent address family identifier: Unicast (1) | +--Subsequent address family identifier: Unicast (1)
| +--Next hop network address: (16 bytes) | +--Next hop network address: (16 bytes)
| | +--Next hop: 2001:0010:0000:0000:0000:0000:c633:6464 | | +--Next hop: fd00:0000:0000:0000:0000:0000:c633:6464
| +--Subnetwork points of attachment: 0 | +--Subnetwork points of attachment: 0
| +--Network layer reachability information: (5 bytes) | +--Network layer reachability information: (5 bytes)
| +--2001:db8::/32 | +--2001:db8::/32
| +--MP Reach NLRI prefix length: 32 | +--MP Reach NLRI prefix length: 32
| +--MP Reach NLRI IPv6 prefix: 2001:db8:: | +--MP Reach NLRI IPv6 prefix: 2001:db8::
+--BGPSEC Path Attribute (209 bytes) +--BGPSEC Path Attribute (209 bytes)
+--Flags: 0x90 (Optional, Complete, Extended Length) +--Flags: 0x90 (Optional, Complete, Extended Length)
+--Type Code: BGPSEC Path Attribute (30) +--Type Code: BGPSEC Path Attribute (30)
+--Length: 205 bytes +--Length: 205 bytes
 End of changes. 35 change blocks. 
87 lines changed or deleted 120 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/