Fastly

Amsterdam Netherlands job@fastly.com

APNIC

6 Cordelia St QLD 4101 South Brisbane Australia gih@apnic.net

ops sidrops security cryptography X.509 This document defines a "RPKI 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 RPKI 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.

Introduction This document defines an "RPKI Prefix List", a Cryptographic Message Syntax (CMS) protected content type to carry a list of IP 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 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 RPKI Prefix List SHOULD be regarded as invalid, 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 'route-set' class objects used in Internet Routing Registries (IRRs). The semantics of the route-set and the RPKI 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 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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

RPKI Signed Prefix List Profile RPKI Prefix List objects follow the Signed Object Template for the RPKI .

The Certification Authority (CA) MUST sign only one PrefixList with each EE certificate and MUST generate a new key pair for each new PrefixList or PrefixList Opt-Out Listing. This type of EE certificate is termed a "one-time-use" EE certificate (see ).

A guideline for naming PrefixList 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 ; 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 .

eContentType

The PrefixList eContentType The eContentType for an PrefixList 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 ).

eContent

The PrefixList eContent The content of an PrefixList is a list of IP address prefixes and a single ASN. An PrefixList is formally defined as follows: RpkiSignedPrefixList-2023 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiSignedPrefixList-2023(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 DEFAULT 0, asID ASID, prefixList SEQUENCE (SIZE(0..MAX)) OF AddressFamilyIPAddress } ASID ::= INTEGER (1..4294967295) AddressFamilyIPAddress ::= SEQUENCE { addressFamily ADDRESS-FAMILY.&afi ({AddressFamilySet}), prefix ADDRESS-FAMILY.&Prefix ({AddressFamilySet}{@addressFamily}) } ADDRESS-FAMILY ::= CLASS { &afi OCTET STRING (SIZE(2)) UNIQUE, &Prefix } WITH SYNTAX { AFI &afi PREFIX-TYPE &Prefix } AddressFamilySet ADDRESS-FAMILY ::= { addressFamilyIPv4 | addressFamilyIPv6 } addressFamilyIPv4 ADDRESS-FAMILY ::= { AFI afi-IPv4 PREFIX-TYPE AddressesIPv4 } addressFamilyIPv6 ADDRESS-FAMILY ::= { AFI afi-IPv6 PREFIX-TYPE AddressesIPv6 } afi-IPv4 OCTET STRING ::= '0001'H afi-IPv6 OCTET STRING ::= '0002'H AddressesIPv4 ::= Prefix{32} AddressesIPv6 ::= Prefix{128} Prefix {INTEGER: len} ::= SEQUENCE { address BIT STRING (SIZE(0..len)) } END

Version The version number of the RpkiSignedPrefixList MUST be 0.

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

prefixList This field contains a SEQUENCE of AddressFamilyIPAddress. The AddressFamilyIPAddress elements MUST be ordered in ascending order: first by numeric value of the addressFamily field, then by value of the prefix field.

Element AddressFamilyIPAddress This field contains a SEQUENCE which contains one instance of addressFamily and one instance of prefix.

addressFamily This field contains a OCTET STRING which is either '0001'H (IPv4) or '0002'H (IPv6).

prefix This field contains a BIT STRING, its length bounded through the addressFamily field. The type is a BIT STRING, see Section 2.2.3.8 of for more information.

PrefixList Validation To validate an PrefixList, the RP MUST perform all the validation checks specified in . In addition, the RP MUST perform the following validation steps:

1. The contents of the CMS eContent field MUST conform to all of the constraints described in .
2. The Autonomous System Identifier Delegation extension MUST be present in the EE certificate contained in the CMS certificates field.
3. The AS identifier present in the RpkiSignedPrefixList eContent 'asID' field MUST be a subset of the AS Indentifiers present in the certificate extension.
4. The Autonomous System Identifier Delegation extension MUST NOT contain "inherit" elements.
5. The IP Address Delegation Extension is not used in PrefixList, and MUST NOT be present in the EE certificate.

Operational Considerations Multiple valid PrefixList objects could exist which contain the same asID. 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 PrefixList for a given asID. If an AS holder publishes a PrefixList, 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 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 RPKI PrefixList(s) compliments best practises and rejecting RPKI-invalid BGP route announcements . In other words, if a given BGP route is covered by a RPKI PrefixList, but also is "invalid" from a Route Origin Validation perspective, it is RECOMMENDED to reject the route announcement.

Security Considerations Relying Parties are warned that the data in an PrefixList 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 PrefixList object, CAs technically are not restricted from generating and signing multiple different PrefixList objects with a single key pair. Any PrefixList objects sharing the same EE certificate cannot be revoked individually.

IANA Considerations

SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) 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-spaghetti-sidrops-rpki-prefixlist

RPKI Signed Objects IANA is requested to register two OIDs in the "RPKI Signed Objects" registry as follows:

Name	OID	Reference
Signed PrefixList	1.2.840.113549.1.9.16.1.TBD	draft-spaghetti-sidrops-rpki-prefixlist

RPKI Repository Name Schemes IANA is requested to add the Signed PrefixList file extension to the "RPKI Repository Name Schemes" registry as follows:

Filename Extension	RPKI Object	Reference
.pfx	Signed PrefixList	draft-spaghetti-sidrops-rpki-prefixlist

SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) 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-2023	draft-spaghetti-sidrops-rpki-prefixlist

Media Types IANA is requested to register the media type "application/rpki-prefixlist" in the "Media Types" registry as follows:

PrefixList Media Type

Type name:

application

Subtype name:

rpki-prefixlist

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary

Security considerations:

Carries an RPKI Signed PrefixList. This media type contains no active content. See of draft-spaghetti-sidrops-rpki-prefixlist for further information.

Interoperability considerations:

N/A

Published specification:

draft-spaghetti-sidrops-rpki-prefixlist

Applications that use this media type:

RPKI operators

Fragment identifier considerations:

N/A

Additional information:

Content:

This media type is a signed object, as defined in [RFC6488], which contains a payload of a list of checksums as defined in draft-spaghetti-sidrops-rpki-prefixlist.

Magic number(s):

N/A

File extension(s):

.pfx

Macintosh file type code(s):

N/A

Person & email address to contact for further information:

Job Snijders (job@fastly.com)

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

Job Snijders (job@fastly.com)

Change controller:

IETF

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK] This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK] This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.

Acknowledgements The authors wish to thank for feedback.

Example payloads

Example PrefixList eContent Payload Below an example of a DER encoded PrefixList eContent is provided with annotation following the '#' character. ... snip ... 121:d=2 hl=2 l= 33 cons: SEQUENCE 123:d=3 hl=2 l= 2 prim: OCTET STRING 0000 - 00 02 .. 127:d=3 hl=2 l= 27 cons: SEQUENCE 129:d=4 hl=2 l= 7 prim: BIT STRING 0000 - 01 20 01 04 18 14 4e . ....N # 2001:418:144e::/47 138:d=4 hl=2 l= 7 prim: BIT STRING 0000 - 00 20 01 06 7c 20 8c . ..| . # 2001:67c:208c::/48 147:d=4 hl=2 l= 7 prim: BIT STRING 0000 - 00 20 01 07 fb fd 04 . ..... # 2001:7fb:fd04::/48 156:d=4 hl=2 l= 7 prim: BIT STRING 0000 - 00 26 07 fa e0 02 45 .&....E # 2607:fae0:245::/48 ]]>

Implementation status 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 .pfx files were created by Job Snijders with the use of asn1c and OpenSSL.