A profile for RPKI Signed Lists of Prefixes

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

Copyright Notice

Copyright (c) 2023 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 an "RPKI Prefix List", a Cryptographic Message Syntax (CMS) [RFC5652] [RFC6268] 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 [RFC2622] '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.¶

2. RPKI Signed Prefix List Profile

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

3. eContentType

4. eContent

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(1..2)) OF IPAddressFamily }

IPAddressFamily ::= SEQUENCE {
  -- Note: addressFamily must be '0001'H (IPv4) or '0002'H (IPv6) --
  addressFamily    OCTET STRING (SIZE(2)),
  addresses        SEQUENCE (SIZE(1..MAX)) OF IPAddress
}

ASID ::= INTEGER (1..4294967295)

-- Note: if the ROAIPAddressFamily's addressFamily is IPv4, the  --
-- IPAddress' size cannot exceed 32; conversely if addressFamily --
-- is IPv6, size can't exceed 128.                               --
IPAddress ::= BIT STRING (SIZE(0..128))

END

5. PrefixList Validation

To validate an PrefixList, 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 4.¶
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 PrefixList, and MUST NOT be present in the EE certificate.¶

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

8. IANA Considerations

Appendix A. Acknowledgements

The authors wish to thank TBD TBD and TBD TBD for feedback.¶

Authors' Addresses