Internet-Draft | RPKI Signed Prefix List | January 2024 |
Snijders & Huston | Expires 27 July 2024 | [Page] |
This document defines a "Signed Prefix List", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry the complete list of prefixes which an Autonomous System (AS) may originate to all or any of its routing peers. The validation of a Signed Prefix List confirms that the holder of the listed ASN produced the object, and that this list is a current, accurate and complete description of address prefixes that may be announced into the routing system originated by this AS.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 July 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document defines a "Signed Prefix List", a Cryptographic Message Syntax (CMS) [RFC5652] [RFC6268] protected content type to carry a list of IP address prefixes and an Autonomous System Number. The list of prefixes describes the maximal set of prefixes that the Autonomous System MAY announce to any of its routing peers. The content is signed by the holder of the RPKI private key associated with the listed ASN.¶
RPKI Signed Prefix Lists allow other RPKI-validating remote routing entities to audit the collection of announcements that have the subject ASN as the originating AS. Any prefixes originated by this AS not contained in a validated Signed Prefix List SHOULD be regarded as ineligible, but ultimately their consequent handling by the local routing entity that performed the audit function is a matter of local policy.¶
The intent of this object is to offer a RPKI-based successor to the [RFC2622] 'route-set' class objects used in Internet Routing Registries (IRRs). The semantics of the route-set and the Signed Prefix List are similair. The difference is that the RPKI signature allows a relying party of be assured of the currency and authenticity 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 validated by the RPKI.¶
Signed Prefix List objects follow the Signed Object Template for the RPKI [RFC6488].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The eContentType for a Prefix List is defined as id-ct-rpkiSignedPrefixList, with Object Identifier (OID) 1.2.840.113549.1.9.16.1.TBD.¶
This OID MUST appear within both the eContentType in the encapContentInfo object and the ContentType signed attribute in the signerInfo object (see [RFC6488]).¶
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 follows:¶
RpkiSignedPrefixList-2024 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiSignedPrefixList-2024(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS CONTENT-TYPE FROM CryptographicMessageSyntax-2010 -- in [RFC6268] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; ct-rpkiSignedPrefixList CONTENT-TYPE ::= { TYPE RpkiSignedPrefixList IDENTIFIED BY id-ct-rpkiSignedPrefixList } id-ct-rpkiSignedPrefixList OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) TBD } RpkiSignedPrefixList ::= SEQUENCE { version [0] INTEGER (0..MAX) DEFAULT 0, asID INTEGER (1..4294967295), prefixes SEQUENCE (SIZE(0..2)) OF AddressFamilyAddressPrefixes } AddressFamilyAddressPrefixes ::= SEQUENCE { addressFamily ADDRESS-FAMILY.&afi ({AddressFamilySet}), addressPrefixes ADDRESS-FAMILY.&Prefixes ({AddressFamilySet}{@addressFamily}) } ADDRESS-FAMILY ::= CLASS { &afi OCTET STRING (SIZE(2)) UNIQUE, &Prefixes } WITH SYNTAX { AFI &afi PREFIXES &Prefixes } AddressFamilySet ADDRESS-FAMILY ::= { addressFamilyIPv4 | addressFamilyIPv6 } addressFamilyIPv4 ADDRESS-FAMILY ::= { AFI afi-IPv4 PREFIXES IPv4Prefixes } addressFamilyIPv6 ADDRESS-FAMILY ::= { AFI afi-IPv6 PREFIXES IPv6Prefixes } afi-IPv4 OCTET STRING ::= '0001'H afi-IPv6 OCTET STRING ::= '0002'H IPv4Prefixes ::= SEQUENCE (SIZE(1..MAX)) OF AddressPrefix{32} IPv6Prefixes ::= SEQUENCE (SIZE(1..MAX)) OF AddressPrefix{128} AddressPrefix {INTEGER: len} ::= BIT STRING (SIZE(0..len)) END¶
The version number of the RpkiSignedPrefixList MUST be 0.¶
The Autonomous System Number contained here MUST be a contained within the set of AS Identifier resources listed by the EE certificate carried in the CMS certificates field.¶
This field contains a SEQUENCE of AddressFamilyAddressPrefixes. The AddressFamilyAddressPrefixes elements MUST be ordered in ascending order by numeric value of the addressFamily field.¶
This field contains a SEQUENCE which contains one instance of addressFamily and one instance of addressPrefixes.¶
This field contains a OCTET STRING which is either '0001'H (IPv4) or '0002'H (IPv6).¶
This field contains a SEQUENCE of parameterized AddressPrefix instances. The canonicalization procedure specified in Section 4.3.3 of [I-D.ietf-sidrops-rfc6482bis] MUST be applied.¶
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 [RFC3779] for more information on encoding IP prefixes.¶
To validate a Signed Prefix List, the RP MUST perform all the validation checks specified in [RFC6488]. In addition, the RP MUST perform the following validation steps:¶
Multiple valid Signed Prefix List objects which contain the same asID could exist. In such cases the union of address prefix members forms the complete set of members. It is highly RECOMMENDED that a compliant CA maintains a single Signed Prefix List for a given asID.¶
If an AS holder publishes a Signed Prefix List, then relying parties 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 an address prefix that is not included in the Signed Prefix List implies that the route has been propagated within the routing system without the permission of the originating AS.¶
The construction of an 'allowlist' for a given EBGP session using Signed Prefix List(s) compliments both best current practises [RFC7454] and the practise of rejecting RPKI-ROV-invalid BGP route announcements [RFC6811]. In other words, if a given BGP route is covered by a Signed Prefix List, but also is "invalid" from a Route Origin Validation perspective, it is RECOMMENDED to reject the route announcement.¶
The Certificate Authority (CA) SHOULD sign only one Signed Prefix 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 MUST generate a new End Entity (EE) certificate for each signing of a particular Signed Prefix List. An associated EE certificate used in this fashion is termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]).¶
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 of the EE certificate. One such method of generating a publication 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 modified form of Base64 encoding, with an additional modification as proposed in Section 5, table 2, of [RFC4648].¶
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 any IP prefix holder that grants the AS permission to originate a route for any prefixes. Such 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 sign a single Signed Prefix List object, CAs are not technically restricted from generating and signing multiple different Signed Prefix List objects with a single key pair. Any Signed Prefix List objects sharing the same EE certificate cannot be revoked individually.¶
IANA is requested to allocated the following in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry:¶
Decimal | Description | References |
---|---|---|
TBD | id-ct-rpkiSignedPrefixList | draft-ietf-sidrops-rpki-prefixlist |
IANA is requested to register two OIDs in the "RPKI Signed Objects" registry [RFC6488] as follows:¶
Name | OID | Reference |
---|---|---|
Signed Prefix List | 1.2.840.113549.1.9.16.1.TBD | draft-ietf-sidrops-rpki-prefixlist |
IANA is requested to add the Signed Prefix List file extension to the "RPKI Repository Name Schemes" registry [RFC6481] as follows:¶
Filename Extension | RPKI Object | Reference |
---|---|---|
.spl | Signed Prefix List | draft-ietf-sidrops-rpki-prefixlist |
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:¶
Decimal | Description | References |
---|---|---|
TBD | id-mod-rpkiSignedPrefixList-2024 | draft-ietf-sidrops-rpki-prefixlist |
IANA is requested to register the media type "application/rpki-prefixlist" in the "Media Types" registry as follows:¶
The authors wish to thank Russ Housley for feedback.¶
Below an example of a DER-encoded Signed Prefix List eContent is provided with annotation following the '#' character.¶
$ cat << EOF | xxd -r -ps | openssl asn1parse -inform DER -i -dump 3081b102023cca3081aa307304020001306d03040043ddf5030400a5fee1 030506a5feff00030400c093a8030400c22047030400c63a03030401cc02 1e030400d11800030400d11801030400d11803030402d11804030403d118 08030400d11808030400d11809030404d11810030405d11820030406d118 40030407d11880303304020002302d03070120010418144e030700200106 7c208c030700200107fbfd040307002607fae002450307002a0eb2400000 EOF 0:d=0 hl=3 l= 177 cons: SEQUENCE 3:d=1 hl=2 l= 2 prim: INTEGER :3CCA # AS 15562 7:d=1 hl=3 l= 170 cons: SEQUENCE 10:d=2 hl=2 l= 115 cons: SEQUENCE 12:d=3 hl=2 l= 2 prim: OCTET STRING 0000 - 00 01 # AFI IPv4 16:d=3 hl=2 l= 109 cons: SEQUENCE 18:d=4 hl=2 l= 4 prim: BIT STRING 0000 - 00 43 dd f5 # 67.221.245.0/24 24:d=4 hl=2 l= 4 prim: BIT STRING 0000 - 00 a5 fe e1 # 165.254.225.0/24 30:d=4 hl=2 l= 5 prim: BIT STRING 0000 - 06 a5 fe ff # 165.254.255.0/26 0005 - <SPACES/NULS> ... snip ... 127:d=2 hl=2 l= 51 cons: SEQUENCE 129:d=3 hl=2 l= 2 prim: OCTET STRING 0000 - 00 02 # AFI IPv6 133:d=3 hl=2 l= 45 cons: SEQUENCE 135:d=4 hl=2 l= 7 prim: BIT STRING 0000 - 01 20 01 04 18 14 4e # 2001:418:144e::/47 144:d=4 hl=2 l= 7 prim: BIT STRING 0000 - 00 20 01 06 7c 20 8c # 2001:67c:208c::/48 ... snip ...¶