draft-ietf-sidrops-rpki-prefixlist-02.txt   draft-ietf-sidrops-rpki-prefixlist-03.txt 
sidrops J. Snijders sidrops J. Snijders
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track G. Huston Intended status: Standards Track G. Huston
Expires: 1 August 2024 APNIC Expires: 22 September 2024 APNIC
29 January 2024 21 March 2024
A profile for Signed Prefix Lists for Use in the Resource Public Key A profile for Signed Prefix Lists for Use in the Resource Public Key
Infrastructure (RPKI) Infrastructure (RPKI)
draft-ietf-sidrops-rpki-prefixlist-02 draft-ietf-sidrops-rpki-prefixlist-03
Abstract Abstract
This document defines a "Signed Prefix List", a Cryptographic Message This document defines a "Signed Prefix List", a Cryptographic Message
Syntax (CMS) protected content type for use with the Resource Public Syntax (CMS) protected content type for use with the Resource Public
Key Infrastructure (RPKI) to carry the complete list of prefixes Key Infrastructure (RPKI) to carry the complete list of prefixes
which an Autonomous System (AS) may originate to all or any of its which an Autonomous System (the subject AS) may originate to all or
routing peers. The validation of a Signed Prefix List confirms that any of its routing peers. The validation of a Signed Prefix List
the holder of the listed ASN produced the object, and that this list confirms that the holder of the subject AS produced the object, and
is a current, accurate and complete description of address prefixes that this list is a current, accurate and complete description of
that may be announced into the routing system originated by this AS. address prefixes that may be announced into the routing system
originated by the subject AS.
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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 1 August 2024. This Internet-Draft will expire on 22 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The Signed Prefix List ContentType . . . . . . . . . . . . . 3 2. The Signed Prefix List ContentType . . . . . . . . . . . . . 3
3. The Signed Prefix List eContent . . . . . . . . . . . . . . . 3 3. The Signed Prefix List eContent . . . . . . . . . . . . . . . 4
3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. asID . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. asID . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. prefixes . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. prefixBlocks . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Element AddressFamilyAddressPrefixes . . . . . . . . 5 3.3.1. Element AddressFamilyAddressPrefixes . . . . . . . . 5
4. Signed Prefix List Validation . . . . . . . . . . . . . . . . 6 3.3.2. Canonical form for prefixBlocks . . . . . . . . . . . 6
5. Operational Considerations . . . . . . . . . . . . . . . . . 6 4. Semantics of Signed Prefix List . . . . . . . . . . . . . . . 7
5.1. EE Certificates . . . . . . . . . . . . . . . . . . . . . 7 5. Signed Prefix List Validation . . . . . . . . . . . . . . . . 7
5.2. Object Filenames . . . . . . . . . . . . . . . . . . . . 7 6. Operational Considerations . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6.1. EE Certificates . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6.2. Object Filenames . . . . . . . . . . . . . . . . . . . . 8
7.1. SMI Security for S/MIME CMS Content Type 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
(1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . 8 8.1. SMI Security for S/MIME CMS Content Type
7.3. RPKI Repository Name Schemes . . . . . . . . . . . . . . 8 (1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 9
7.4. SMI Security for S/MIME Module Identifier 8.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . 9
(1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . . 8 8.3. RPKI Repository Name Schemes . . . . . . . . . . . . . . 9
7.5. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 8.4. SMI Security for S/MIME Module Identifier
7.5.1. Signed Prefix List Media Type . . . . . . . . . . . . 9 (1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.5. Media Types . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.5.1. Signed Prefix List Media Type . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
Appendix B. Example payloads . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12
B.1. Example Signed Prefix List eContent Payload . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Example payloads . . . . . . . . . . . . . . . . . . 13
B.1. Example Signed Prefix List eContent Payload . . . . . . . 13
Appendix C. Implementation status . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document defines a "Signed Prefix List", a Cryptographic Message This document defines a "Signed Prefix List", a Cryptographic Message
Syntax (CMS) [RFC5652] [RFC6268] protected content type to carry a Syntax (CMS) [RFC5652] [RFC6268] protected content type to carry a
list of IP address prefixes and an Autonomous System Number. The list of IP address prefixes and an Autonomous System Number (the
list of prefixes describes the maximal set of prefixes that the subject AS). The list of prefixes describes the maximal set of
Autonomous System MAY announce to any of its routing peers. The prefixes that the subject AS MAY announce to any of its routing
content is signed by the holder of the RPKI private key associated peers. The content is signed by the holder of the RPKI private key
with the listed ASN. associated with the subject AS.
RPKI Signed Prefix Lists allow other RPKI-validating remote routing RPKI Signed Prefix Lists allow other RPKI-validating routing entities
entities to audit the collection of announcements that have the to audit the collection of announcements that have the subject AS as
subject ASN as the originating AS. Any prefixes originated by this the originating AS. Any prefixes originated by this AS not contained
AS not contained in a validated Signed Prefix List SHOULD be regarded in a validated Signed Prefix List SHOULD be regarded as ineligible,
as ineligible, but ultimately their consequent handling by the local but ultimately their consequent handling by the local routing entity
routing entity that performed the audit function is a matter of local that performed the audit function is a matter of local policy.
policy.
The intent of this object is to offer a RPKI-based successor to the The intent of this object is to offer a RPKI-based successor to the
[RFC2622] 'route-set' class objects used in Internet Routing [RFC2622] 'route-set' class objects used in Internet Routing
Registries (IRRs). The semantics of the route-set and the Signed Registries (IRRs). The semantics of the route-set and the Signed
Prefix List are similair. The difference is that the RPKI signature Prefix List are similair. The difference is that the RPKI signature
allows a relying party of be assured of the currency and authenticity allows a relying party of be assured of the currency and authenticity
of the Signed Prefix List as a complete enumeration of all prefixes of the Signed Prefix List as a complete enumeration of all prefixes
that may be announced as originating by this AS if the object can be that may be announced as originating by the subject AS.
validated by the RPKI.
Signed Prefix List objects follow the Signed Object Template for the Signed Prefix List objects follow the Signed Object Template for the
RPKI [RFC6488]. RPKI [RFC6488].
1.1. Requirements Language 1.1. Requirements Language
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
skipping to change at page 3, line 46 skipping to change at page 4, line 8
rpkiSignedPrefixList, with Object Identifier (OID) rpkiSignedPrefixList, with Object Identifier (OID)
1.2.840.113549.1.9.16.1.51. 1.2.840.113549.1.9.16.1.51.
This OID MUST appear within both the eContentType in the This OID MUST appear within both the eContentType in the
encapContentInfo object and the ContentType signed attribute in the encapContentInfo object and the ContentType signed attribute in the
signerInfo object (see [RFC6488]). signerInfo object (see [RFC6488]).
3. The Signed Prefix List eContent 3. The Signed Prefix List eContent
The content of a Signed Prefix List is a single ASN and a list of IP The content of a Signed Prefix List is a single ASN and a list of IP
address prefixes. An Signed Prefix List is formally defined as address prefixes. A Signed Prefix List is formally defined as
follows: follows:
RpkiSignedPrefixList-2024 RpkiSignedPrefixList-2024
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0) pkcs(1) pkcs9(9) smime(16) mod(0)
id-mod-rpkiSignedPrefixList-2024(TBD) } id-mod-rpkiSignedPrefixList-2024(TBD) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at page 5, line 20 skipping to change at page 5, line 26
3.1. Version 3.1. Version
The version number of the RpkiSignedPrefixList MUST be 0. The version number of the RpkiSignedPrefixList MUST be 0.
3.2. asID 3.2. asID
The Autonomous System Number contained here MUST be a contained The Autonomous System Number contained here MUST be a contained
within the set of AS Identifier resources listed by the EE within the set of AS Identifier resources listed by the EE
certificate carried in the CMS certificates field. certificate carried in the CMS certificates field.
3.3. prefixes 3.3. prefixBlocks
This field contains a SEQUENCE of AddressFamilyAddressPrefixes. The This field contains a SEQUENCE of AddressFamilyAddressPrefixes. The
AddressFamilyAddressPrefixes elements MUST be ordered in ascending AddressFamilyAddressPrefixes elements MUST be ordered in ascending
order by numeric value of the addressFamily field. order by numeric value of the addressFamily field.
3.3.1. Element AddressFamilyAddressPrefixes 3.3.1. Element AddressFamilyAddressPrefixes
This field contains a SEQUENCE which contains one instance of This field contains a SEQUENCE which contains one instance of
addressFamily and one instance of addressPrefixes. addressFamily and one instance of addressPrefixes.
3.3.1.1. addressFamily 3.3.1.1. addressFamily
This field contains a OCTET STRING which is either '0001'H (IPv4) or This field contains an OCTET STRING which is either '0001'H (IPv4) or
'0002'H (IPv6). '0002'H (IPv6).
3.3.1.2. addressPrefixes 3.3.1.2. addressPrefixes
This field contains a SEQUENCE of parameterized AddressPrefix This field contains a SEQUENCE of parameterized AddressPrefix
instances. The canonicalization procedure specified in Section 4.3.3 instances.
of [I-D.ietf-sidrops-rfc6482bis] MUST be applied.
3.3.1.3. Element AddressPrefix 3.3.1.3. Element AddressPrefix
This element is length bounded through the Information Object Class This element is length bounded through the Information Object Class
ADDRESS-FAMILY. The type is a BIT STRING, see Section 2.2.3.8 of ADDRESS-FAMILY. The type is a BIT STRING, see Section 2.2.3.8 of
[RFC3779] for more information on encoding IP prefixes. [RFC3779] for more information on encoding IP prefixes.
4. Signed Prefix List Validation 3.3.2. Canonical form for prefixBlocks
As the data structure described by the SignedPrefixList Section 3
module allows for many different ways to represent the same set of IP
address prefix information, a canonical form is defined such that
every set of address prefixes has a unique representation. To
produce and verify this canonical form, the process described in this
section MUST be used to ensure information elements are unique with
respect to one another and sorted in ascending order. This
canonicalization procedure builds upon the canonicalization procedure
specified in section 2.2.3.6 of [RFC3779] and Section 4.3.3 of
[I-D.ietf-sidrops-rfc6482bis].
To semantically compare, sort, and deduplicate the contents of the
prefixBlocks field, each AddressPrefix element is mapped to an
abstract data element composed of three integer values:
afi The AFI value appearing in the addressFamily field of the
containing addressPrefixes as an integer.
addr The first IP address of the IP prefix appearing in the
AddressPrefix field, as a 32-bit (IPv4) or 128-bit (IPv6) integer
value.
plen The prefix length of the IP prefix appearing in the
AddressPrefix address field as an integer value.
Thus, the equality or relative order of two AddressPrefix elements
can be tested by comparing their abstract representations.
3.3.2.1. Comparator
The set of prefixBlocks is totally ordered. The order of two
prefixBlocks is determined by the first non-equal comparison in the
following list.
1. Data elements with a lower afi value precede data elements with a
higher afi value.
2. Data elements with a lower addr value precede data elements with
a higher addr value.
3. Data elements with a lower plen value precede data elements with
a higher plen value.
Data elements for which all three values compare equal are duplicates
of one another.
4. Semantics of Signed Prefix List
The IP address prefixes listed in a Signed Prefix List object are an
enumeration of prefixes that may be announced as originating from the
AS identified by the asID (the subject AS) if the object can be
validated by the RPKI (Section 5). The object does not implicitly
permit a more-specific prefix subsumed by a listed IP address prefix
to be originated by this AS. For any such more-specific prefix to be
permitted by the Signed Prefix List object, it must be explicitly
listed in the list of IP address prefixes.
5. Signed Prefix List Validation
To validate a Signed Prefix List, the RP MUST perform all the To validate a Signed Prefix List, the RP MUST perform all the
validation checks specified in [RFC6488]. In addition, the RP MUST validation checks specified in [RFC6488]. In addition, the RP MUST
perform the following validation steps: perform the following validation steps:
1. The contents of the CMS eContent field MUST conform to all of the 1. The contents of the CMS eContent field MUST conform to all the
constraints described in Section 3. constraints described in Section 3.
2. The Autonomous System Identifier Delegation extension [RFC3779] 2. The Autonomous System Identifier Delegation extension [RFC3779]
MUST be present in the EE certificate contained in the CMS MUST be present in the EE certificate contained in the CMS
certificates field. certificates field.
3. The AS identifier present in the RpkiSignedPrefixList eContent 3. The AS identifier present in the RpkiSignedPrefixList eContent
'asID' field MUST be a subset of the AS Indentifiers present in 'asID' field MUST be contained in the AS Identifiers present in
the certificate extension. the certificate extension.
4. The Autonomous System Identifier Delegation extension MUST NOT 4. The Autonomous System Identifier Delegation extension MUST NOT
contain "inherit" elements. contain "inherit" elements.
5. The IP Address Delegation Extension [RFC3779] is not used in 5. The IP Address Delegation Extension [RFC3779] is not used in
Signed Prefix List, and MUST NOT be present in the EE Signed Prefix List, and MUST NOT be present in the EE
certificate. certificate.
5. Operational Considerations 6. Operational Considerations
Multiple valid Signed Prefix List objects which contain the same asID Multiple valid Signed Prefix List objects which contain the same asID
could exist. In such cases the union of address prefix members forms could exist. In such cases, the union of address prefix members of
the complete set of members. It is highly RECOMMENDED that a the collection of Signed Prefrix list objects forms the complete set
compliant CA maintains a single Signed Prefix List for a given asID. of members. It is RECOMMENDED that a CA maintains a single Signed
Prefix List for a given asID.
If an AS holder publishes a Signed Prefix List, then relying parties If an AS holder publishes a Signed Prefix List, then relying parties
SHOULD assume that the list is complete for that originating AS, and SHOULD assume that the list is complete for that originating AS, and
the presence of any route with the same AS as the originating AS and the presence of any route with the same AS as the originating AS and
an address prefix that is not included in the Signed Prefix List an address prefix that is not included in the Signed Prefix List
implies that the route has been propagated within the routing system implies that the route has been propagated within the routing system
without the permission of the originating AS. without the permission of the originating AS.
The construction of an 'allowlist' for a given EBGP session using The construction of an 'allowlist' for a given EBGP session using
Signed Prefix List(s) compliments both best current practises Signed Prefix List(s) compliments both best current practices
[RFC7454] and the practise of rejecting RPKI-ROV-invalid BGP route [RFC7454] and the practice of rejecting RPKI-ROV-invalid BGP route
announcements [RFC6811]. In other words, if a given BGP route is announcements [RFC6811]. In other words, if a given BGP route is
covered by a Signed Prefix List, but also is "invalid" from a Route covered by a Signed Prefix List, but also is "Invalid" from a Route
Origin Validation perspective, it is RECOMMENDED to reject the route Origin Validation perspective, it is RECOMMENDED to reject the route
announcement. announcement. Here the term "reject the route" is used in the sense
of "consider the route ineligible for path selection" [RFC4271].
5.1. EE Certificates 6.1. EE Certificates
The Certificate Authority (CA) SHOULD sign only one Signed Prefix The Certificate Authority (CA) SHOULD sign only one Signed Prefix
List with each generated private key and SHOULD generate a new key List with each generated private key and SHOULD generate a new key
pair for each new version of a Signed Prefix List object. The CA pair for each new version of a Signed Prefix List object. The CA
MUST generate a new End Entity (EE) certificate for each signing of a MUST generate a new End Entity (EE) certificate for each signing of a
particular Signed Prefix List. An associated EE certificate used in particular Signed Prefix List. An associated EE certificate used in
this fashion is termed a "one-time-use" EE certificate (see Section 3 this fashion is termed a "one-time-use" EE certificate (see Section 3
of [RFC6487]). of [RFC6487]).
5.2. Object Filenames 6.2. Object Filenames
A guideline for naming Signed Prefix List objects is that the file A guideline for naming Signed Prefix List objects is that the file
name chosen in the repository be a value derived from the public key name chosen in the repository be a value derived from the public key
of the EE certificate. One such method of generating a publication of the EE certificate. One such method of generating a publication
name is described in Section 2.1 of [RFC4387]; convert the 160-bit name is described in Section 2.1 of [RFC4387]; convert the 160-bit
hash of a EE's public key value into a 27-character string using a hash of an EE's public key value into a 27-character string using a
modified form of Base64 encoding, with an additional modification as modified form of Base64 encoding, with an additional modification as
proposed in Section 5, table 2, of [RFC4648]. proposed in Section 5, table 2, of [RFC4648].
6. Security Considerations 7. Security Considerations
Relying Parties are warned that the data in a Signed Prefix List is Relying Parties are warned that the data in a Signed Prefix List is
self-asserted by the AS holder. There is no implied authority from self-asserted by the AS holder. There is no implied authority in a
any IP prefix holder that grants the AS permission to originate a Signed Prefix List that any IP prefix holder has granted the AS
route for any prefixes. Such an authority is separately conveyed in permission to originate a route for any of the listed prefixes. Such
the RPKI as a ROA. an authority is separately conveyed in the RPKI as a ROA.
While a one-time-use EE certificate must only be used to generate and While one-time-use EE certificates and their associated key pairs are
sign a single Signed Prefix List object, CAs are not technically supposed to be used in an ephemeral manner; CAs are not technically
restricted from generating and signing multiple different Signed restricted from generating and signing multiple different objects
Prefix List objects with a single key pair. Any Signed Prefix List with the same key pair, or using the same EE certificate for
objects sharing the same EE certificate cannot be revoked different objects. Any RPKI objects, including Signed Prefix List
objects, that share the same EE certificate cannot be revoked
individually. individually.
7. IANA Considerations 8. IANA Considerations
7.1. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 8.1. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)
IANA has temporarily allocated the following in the "SMI Security for IANA has temporarily allocated the following in the "SMI Security for
S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry: S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry:
+=========+============================+=====================+ +=========+============================+=====================+
| Decimal | Description | References | | Decimal | Description | References |
+=========+============================+=====================+ +=========+============================+=====================+
| 51 | id-ct-rpkiSignedPrefixList | draft-ietf-sidrops- | | 51 | id-ct-rpkiSignedPrefixList | draft-ietf-sidrops- |
| | | rpki-prefixlist | | | | rpki-prefixlist |
+---------+----------------------------+---------------------+ +---------+----------------------------+---------------------+
Table 1 Table 1
7.2. RPKI Signed Objects 8.2. RPKI Signed Objects
IANA is requested to register two OIDs in the "RPKI Signed Objects" IANA is requested to register the following OID in the "RPKI Signed
registry [RFC6488] as follows: Objects" registry [RFC6488]:
+=============+============================+=====================+ +=============+============================+=====================+
| Name | OID | Reference | | Name | OID | Reference |
+=============+============================+=====================+ +=============+============================+=====================+
| Signed | 1.2.840.113549.1.9.16.1.51 | draft-ietf-sidrops- | | Signed | 1.2.840.113549.1.9.16.1.51 | draft-ietf-sidrops- |
| Prefix List | | rpki-prefixlist | | Prefix List | | rpki-prefixlist |
+-------------+----------------------------+---------------------+ +-------------+----------------------------+---------------------+
Table 2 Table 2
7.3. RPKI Repository Name Schemes 8.3. RPKI Repository Name Schemes
IANA is requested to add the Signed Prefix List file extension to the IANA is requested to add the Signed Prefix List file extension to the
"RPKI Repository Name Schemes" registry [RFC6481] as follows: "RPKI Repository Name Schemes" registry [RFC6481] as follows:
+===========+=============+====================================+ +===========+=============+====================================+
| Filename | RPKI Object | Reference | | Filename | RPKI Object | Reference |
| Extension | | | | Extension | | |
+===========+=============+====================================+ +===========+=============+====================================+
| .spl | Signed | draft-ietf-sidrops-rpki-prefixlist | | .spl | Signed | draft-ietf-sidrops-rpki-prefixlist |
| | Prefix List | | | | Prefix List | |
+-----------+-------------+------------------------------------+ +-----------+-------------+------------------------------------+
Table 3 Table 3
7.4. SMI Security for S/MIME Module Identifier 8.4. SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0) (1.2.840.113549.1.9.16.0)
IANA is requested to allocate the following in the "SMI Security for IANA is requested to allocate the following in the "SMI Security for
S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry: S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:
+=========+==================================+=====================+ +=========+==================================+=====================+
| Decimal | Description | References | | Decimal | Description | References |
+=========+==================================+=====================+ +=========+==================================+=====================+
| TBD | id-mod-rpkiSignedPrefixList-2024 | draft-ietf-sidrops- | | TBD | id-mod-rpkiSignedPrefixList-2024 | draft-ietf-sidrops- |
| | | rpki-prefixlist | | | | rpki-prefixlist |
+---------+----------------------------------+---------------------+ +---------+----------------------------------+---------------------+
Table 4 Table 4
7.5. Media Types 8.5. Media Types
IANA is requested to register the media type "application/rpki- IANA is requested to register the media type "application/rpki-
prefixlist" in the "Media Types" registry as follows: prefixlist" in the "Media Types" registry as follows:
7.5.1. Signed Prefix List Media Type 8.5.1. Signed Prefix List Media Type
Type name: application Type name: application
Subtype name: rpki-prefixlist Subtype name: rpki-prefixlist
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: binary Encoding considerations: binary
Security considerations: Carries a Signed Prefix List. This media Security considerations: Carries a Signed Prefix List. This media
type contains no active content. See Section 4 of draft-ietf- type contains no active content. See Section 5 of draft-ietf-
sidrops-rpki-prefixlist for further information. sidrops-rpki-prefixlist for further information.
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: draft-ietf-sidrops-rpki-prefixlist Published specification: draft-ietf-sidrops-rpki-prefixlist
Applications that use this media type: RPKI operators Applications that use this media type: RPKI operators
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Content: This media type is a signed Content: This media type is a signed
object, as defined in [RFC6488], which contains a list of object, as defined in [RFC6488], which contains a list of
prefixes as defined in draft-ietf-sidrops-rpki-prefixlist. prefixes as defined in draft-ietf-sidrops-rpki-prefixlist.
Magic number(s): N/A Magic number(s): N/A
File extension(s): .spl File extension(s): .spl
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person & email address to contact for further information: Job Person & email address to contact for further information: Job
Snijders (job@fastly.com) Snijders (job@fastly.com)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: Job Snijders (job@fastly.com) Author: Job Snijders (job@fastly.com)
Change controller: IETF Change controller: IETF
8. References 9. References
8.1. Normative References 9.1. Normative References
[I-D.ietf-sidrops-rfc6482bis] [I-D.ietf-sidrops-rfc6482bis]
Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S.
Kent, "A Profile for Route Origin Authorizations (ROAs)", Kent, "A Profile for Route Origin Authorizations (ROAs)",
Work in Progress, Internet-Draft, draft-ietf-sidrops- Work in Progress, Internet-Draft, draft-ietf-sidrops-
rfc6482bis-09, 14 December 2023, rfc6482bis-09, 14 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops- <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rfc6482bis-09>. rfc6482bis-09>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 10, line 29 skipping to change at page 11, line 33
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622, "Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999, DOI 10.17487/RFC2622, June 1999,
<https://www.rfc-editor.org/info/rfc2622>. <https://www.rfc-editor.org/info/rfc2622>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012, DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>. <https://www.rfc-editor.org/info/rfc6481>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
skipping to change at page 10, line 52 skipping to change at page 12, line 14
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>. <https://www.rfc-editor.org/info/rfc6488>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 9.2. Informative References
[RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key
Infrastructure Operational Protocols: Certificate Store Infrastructure Operational Protocols: Certificate Store
Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February
2006, <https://www.rfc-editor.org/info/rfc4387>. 2006, <https://www.rfc-editor.org/info/rfc4387>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
skipping to change at page 11, line 29 skipping to change at page 12, line 40
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>. <https://www.rfc-editor.org/info/rfc6811>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <https://www.rfc-editor.org/info/rfc7454>. February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[rpki-client]
Jeker, C., Dzonsons, K., Buehler, T., and J. Snijders,
"rpki-client", February 2024,
<https://www.rpki-client.org/>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors wish to thank Russ Housley for feedback. The authors wish to thank Russ Housley, Theo Buehler, Sriram
Kotikalapudi, and Ties de Kock for much appreciated feedback.
Appendix B. Example payloads Appendix B. Example payloads
B.1. Example Signed Prefix List eContent Payload B.1. Example Signed Prefix List eContent Payload
Below an example of a DER-encoded Signed Prefix List eContent is Below an example of a DER-encoded Signed Prefix List eContent is
provided with annotation following the '#' character. provided with annotation following the '#' character.
$ cat << EOF | xxd -r -ps | openssl asn1parse -inform DER -i -dump $ cat << EOF | xxd -r -ps | openssl asn1parse -inform DER -i -dump
3081b102023cca3081aa307304020001306d03040043ddf5030400a5fee1 3081b102023cca3081aa307304020001306d03040043ddf5030400a5fee1
skipping to change at page 12, line 38 skipping to change at page 13, line 45
127:d=2 hl=2 l= 51 cons: SEQUENCE 127:d=2 hl=2 l= 51 cons: SEQUENCE
129:d=3 hl=2 l= 2 prim: OCTET STRING 129:d=3 hl=2 l= 2 prim: OCTET STRING
0000 - 00 02 # AFI IPv6 0000 - 00 02 # AFI IPv6
133:d=3 hl=2 l= 45 cons: SEQUENCE 133:d=3 hl=2 l= 45 cons: SEQUENCE
135:d=4 hl=2 l= 7 prim: BIT STRING 135:d=4 hl=2 l= 7 prim: BIT STRING
0000 - 01 20 01 04 18 14 4e # 2001:418:144e::/47 0000 - 01 20 01 04 18 14 4e # 2001:418:144e::/47
144:d=4 hl=2 l= 7 prim: BIT STRING 144:d=4 hl=2 l= 7 prim: BIT STRING
0000 - 00 20 01 06 7c 20 8c # 2001:67c:208c::/48 0000 - 00 20 01 06 7c 20 8c # 2001:67c:208c::/48
... snip ... ... snip ...
Appendix C. Implementation status
This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
* Example .spl files were created by Job Snijders.
* A validator implementation [rpki-client], written in C was
provided by Job Snijders from Fastly.
Authors' Addresses Authors' Addresses
Job Snijders Job Snijders
Fastly Fastly
Amsterdam Amsterdam
Netherlands Netherlands
Email: job@fastly.com Email: job@fastly.com
Geoff Huston Geoff Huston
APNIC APNIC
 End of changes. 46 change blocks. 
90 lines changed or deleted 195 lines changed or added

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