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 1 August 2024.¶

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

3. The Signed Prefix List eContent

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) 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. 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 of 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 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 [RFC3779] is not used in Signed Prefix List, and MUST NOT be present in the EE certificate.¶

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

7. IANA Considerations

Appendix A. Acknowledgements

The authors wish to thank Russ Housley for feedback.¶

Authors' Addresses