A profile for Signed Prefix Lists for Use in the Resource Public Key Infrastructure (RPKI)

Status of This Memo

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 20 March 2025.¶

Copyright Notice

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

Table of Contents

1. Introduction

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 subject AS). The list of prefixes describes the maximal set of prefixes that the subject AS MAY announce to any of its routing peers. The content is signed by the holder of the RPKI private key associated with the subject AS.¶

RPKI Signed Prefix Lists allow other RPKI-validating routing entities to audit the collection of announcements that have the subject AS 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 the subject AS.¶

Signed Prefix List objects follow the Signed Object Template for the RPKI [RFC6488].¶

3. The Signed Prefix List eContent

The content of a Signed Prefix List is a single ASN and a list of IP address prefixes. A 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) 51 }

RpkiSignedPrefixList ::= SEQUENCE {
  version [0]     INTEGER (0..MAX) DEFAULT 0,
  asID            INTEGER (1..4294967295),
  prefixBlocks    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{ub-IPv4}
IPv6Prefixes ::= SEQUENCE (SIZE(1..MAX)) OF AddressPrefix{ub-IPv6}

ub-IPv4 INTEGER ::= 32
ub-IPv6 INTEGER ::= 128

AddressPrefix {INTEGER: ub} ::= BIT STRING (SIZE(0..ub))

END

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 validation checks specified in [RFC6488]. In addition, the RP MUST perform the following validation steps:¶

1. The contents of the CMS eContent field MUST conform to all the constraints described in Section 3.¶
2. The Autonomous System Identifier Delegation extension [RFC3779] 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 contained in the AS Identifiers present in the certificate extension.¶
4. The Autonomous System Identifier Delegation extension MUST NOT contain "inherit" elements.¶
5. The IP Address Delegation Extension [RFC3779] is not used in Signed Prefix List, and MUST NOT be present in the EE certificate.¶

7. Security Considerations

Relying Parties are warned that the data in a Signed Prefix List is self-asserted by the AS holder. There is no implied authority in a Signed Prefix List that any IP prefix holder has granted the AS permission to originate a route for any of the listed prefixes. Such an authority is separately conveyed in the RPKI as a ROA.¶

While one-time-use EE certificates and their associated key pairs are supposed to be used in an ephemeral manner; CAs are not technically restricted from generating and signing multiple different objects with the same key pair, or using the same EE certificate for different objects. Any RPKI objects, including Signed Prefix List objects, that share the same EE certificate cannot be revoked individually.¶

8. IANA Considerations

Appendix A. Acknowledgements

The authors wish to thank Russ Housley, Theo Buehler, Sriram Kotikalapudi, and Ties de Kock for much appreciated feedback.¶

Authors' Addresses