<?xmlversion="1.0" encoding="utf-8"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">zwsp "​"> <!ENTITYRFC6480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6480.xml">nbhy "‑"> <!ENTITYRFC6481 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6481.xml"> <!ENTITY RFC6487 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6487.xml"> <!ENTITY RFC6488 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6488.xml"> <!ENTITY RFC6489 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6489.xml"> <!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml"> <!ENTITY RFC8182 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8182.xml"> <!ENTITY RFC8630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8630.xml"> <!ENTITY RFC8488 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8488.xml"> <!ENTITY RFC9286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9286.xml">wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc strict="yes" ?> <?rfc toc="yes"?> <?rfc tocdepth="3"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-sidrops-manifest-numbers-09" number="9981" ipr="trust200902" updates="9286"consensus="true">consensus="true" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="RPKI Manifest Number Handling">Resource Public Key Infrastructure (RPKI) Manifest Number Handling</title> <seriesInfo name="RFC" value="9981"/> <author initials="T." surname="Harrison" fullname="Tom Harrison"> <organization abbrev="APNIC">Asia Pacific Network Information Centre</organization> <address> <postal> <street>6 Cordelia St</street> <city>South Brisbane</city> <code>4101</code> <country>Australia</country> <region>QLD</region> </postal> <email>tomh@apnic.net</email> </address> </author> <author fullname="George G. Michaelson" initials="G." surname="Michaelson"> <organization abbrev="APNIC">Asia-Pacific Network Information Centre</organization> <address> <postal> <street>6 Cordelia St</street> <city>South Brisbane</city> <region>QLD</region> <code>4101</code> <country>Australia</country> </postal> <email>ggm@apnic.net</email> </address> </author> <author fullname="Job Snijders" initials="J." surname="Snijders"><organization></organization><organization abbrev="BSD">BSD Software Development</organization> <address> <postal><street/> <city>Amsterdam</city> <region/> <country>Netherlands</country><postalLine>Amsterdam</postalLine> <postalLine>The Netherlands</postalLine> </postal><email>job@sobornost.net</email><email>job@bsd.nl</email> <uri>https://www.bsd.nl</uri> </address> </author><date/> <area>General</area> <workgroup>Internet Engineering Task Force</workgroup> <keyword>template</keyword><date month="May" year="2026"/> <area>OPS</area> <workgroup>sidrops</workgroup> <abstract> <t> The Resource Public Key Infrastructure (RPKI) makes use of signed objects calledmanifests,"manifests", each of which includes a "manifest number". This document updatesRFC9286RFC 9286 by specifying issuer andRPRelying Party (RP) behaviour when a manifest number reaches the largest possible value, a situation not considered inRFC9286.RFC 9286. </t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t> The Resource Public Key Infrastructure (RPKI) <xref target="RFC6480"/>format="default"/> makes use of signed objects <xref target="RFC6488"/>format="default"/> calledmanifests"manifests" <xref target="RFC9286"/>.format="default"/>. A manifest lists each file that an issuer intends to include within an RPKI repository <xref target="RFC6481"/>, andformat="default"/>. Manifests can also be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which an issuer must increment by one whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that anewly-retrievednewly retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than thepreviously-validatedpreviously validated manifest (<xref target="RFC9286" sectionFormat="of" section="4.2.1"/>).format="default"/>). </t> <t> However, the manifestNumber field is 20 octets in length (i.e., bounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value (2<sup>159</sup>-1). When that value is reached, some RP implementations will accept a new manifest for the CA only once the current manifest has expired, while others will not accept a new manifest at all. </t> <t> While it is practically impossible for an issuer to reach the largest possible value under normal operating conditions (it would require that the issuer issue one manifest per second for 23,171,956,451,847,141,650,870 quintillion years), there is still a chance that it could be reached due to bugs in the issuance or publication systems or incorrect/inadvertent use of those systems. For example: </t> <ul> <li>Incrementing by large values when issuing manifests, such that the time to reach that largest value is reduced.</li> <li>Reissuing new manifests in an infinite delay-free loop, such that the manifestNumber increases by a large value in a comparatively short period of time.</li> <li>Inadvertently setting the manifestNumber to the largest possible value, such that the issuer will no longer be able to publish usable manifests for that repository.</li> </ul> <t> These scenarios might also arise in combination and be more severe as a result. For example, a CA might increase the manifestNumber by a large value onreissuance,reissuance and also reissue the manifest more frequently than is necessary. </t> <t> For a subordinate CA, the risk of repository invalidation due to such a problem can be addressed by the issuer using the key rollover process <xref target="RFC6489"/>format="default"/> to get a new CA certificate. RPs will treat this new certificate as though it represents a distinctCA, andCA; the manifestNumber can be reset at that point. </t> <t> However, this option is not available for RPKI Trust Anchors (TAs). If a TA publishes a manifest with the largest-possible manifestNumber value, then it is difficult to rely on the TA after that point, since (as described previously) some RPs will not accept a new manifest until the current one has expired, while others will reject all new manifests indefinitely. Particularly in the case of TAs, the manifest validity period may be quite long, too. Issuing a new TA and distributing the associated Trust Anchor Locator (TAL) <xreftarget="RFC8630"/>target="RFC8630" format="default"/> to clients would involve a large amount of work for TA operators and RPs. Additionally, depending on the RP implementation being used, there would be a limited degree of RPKI protection by way of that TA for the time between the issuance of the problematic manifest and the installation of the new TAL. </t> <t> In order to avoid these problems, this document updates <xreftarget="RFC9286"/>target="RFC9286" format="default"/> by defining how issuers and RPs can handle this scenario in order to facilitate ongoing use of an affected repository. </t> <sectiontitle="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section anchor="manifest-number-handling"title="Manifestnumbered="true" toc="default"> <name>Manifest NumberHandling">Handling</name> <t> For a given CA, an RPMUST NOT<bcp14>MUST NOT</bcp14> reject a new manifest issued by that CA on the basis of it not having a higher manifestNumber than apreviously-validatedpreviously validated manifest if the new manifest has a different filename from that of thepreviously-validatedpreviously validated manifest. In other words, an RP has to reset its stored manifestNumber for a given CA if the CA changes the filename of its manifest. This is an update to the requirements set out in <xref target="RFC9286" sectionFormat="of" section="4.2.1"/>.format="default"/>. </t> <t> With this behaviour, it is possible for a CA to be configured suchthatthat, any time it issues a new manifest, it uses a new filename for that manifest. If a CA were configured in this way, the manifestNumber validation set out in <xref target="RFC9286" sectionFormat="of" section="4.2.1"/>format="default"/> would have no purpose. To avoid this outcome, CAsSHOULD NOT<bcp14>SHOULD NOT</bcp14> use new filenames for manifests except in situations where such a change is necessary to address the invalidity problem described in this document. Similarly, an RPMUST<bcp14>MUST</bcp14> alert its operators when a manifest filename changes for a given CA. </t> <t anchor="replay"> <xreftarget="RFC9286"/>target="RFC9286" format="default"/> requires that RPs perform two replay-related checks onnewly-retrieved manifests: firstly,newly retrieved manifests:</t> <ol> <li>Check that the purported new manifest has a greater manifestNumber than the cached manifest,and secondly,and</li> <li>Check that the purported new manifest has a more recent thisUpdate than the cachedmanifest. Anmanifest.</li> </ol> <t>An RP that implements the behaviour in this section will momentarily omit the manifestNumber check following a manifest filename change. So long as the RP still performs the second check described above, it will be protected against replay attacks. </t> </section> <section anchor="manifest-filenames"title="Manifest Filenames">numbered="true" toc="default"> <name>Manifest Filenames</name> <t> A CA specifies its manifest URI by way ofan SIAa Subject Information Access (SIA) entry with an accessMethod of id-ad-rpkiManifest (<xref target="RFC6487" section="4.8.8.1"/>).format="default"/>). For the purposes of this document, the manifest filename is the final segment of the path of the accessLocation URI from that SIA entry. </t> <t> <xref target="RFC6487" sectionFormat="of" section="4.8.8.1"/>format="default"/> states that a CA may include in its certificate multiple id-ad-rpkiManifest SIA entries. For comparisons, an RP may use the filename from any one of the id-ad-rpkiManifest SIA entries in thepreviously-validatedpreviously validated CA certificate. If that filename does not appear in any of the id-ad-rpkiManifest SIA entries in the CA certificate that is currently being validated, then the manifest filename has changed for the purposes of this document. </t> <t> The corollary of the behaviour defined in the previous paragraph is that a CA that includes multiple id-ad-rpkiManifest SIA entries in its certificate and wants to rely on the behaviour defined in this documentMUST<bcp14>MUST</bcp14> ensure that none of the manifest filenames in the previous CA certificate appear in thenewly-issuednewly issued CA certificate. If one of the manifest filenames from the previous CA certificate appears in thenewly-issuednewly issued CA certificate, then an RP that is using that manifest filename for comparisons will determine that the manifest filename for the CA has notchanged,changed and will therefore not reset its stored manifestNumber for the CA. </t> </section> <section anchor="manifest-sia-check"title="Manifestnumbered="true" toc="default"> <name>Manifest SIAVerification">Verification</name> <t> To avoid certain forms of replay attack, RPsMUST<bcp14>MUST</bcp14> verify that the URI in the accessLocation in one of the id-ad-signedObject accessMethod instances in the manifest'sSubject Information Access (SIA)SIA extension exactly matches the URI presented in the RPKI Repository Delta Protocol (RRDP) <xref target="RFC8182"/>format="default"/> "publish" element or the path presented by remote rsync servers. If this verification check is unsuccessful, then the fetch has failed, and the RPMUST<bcp14>MUST</bcp14> proceed per <xref target="RFC9286" sectionFormat="of" section="6.6"/>.format="default"/>. </t> </section> <section anchor="rfc8488"title="RFC8488 Comparison">numbered="true" toc="default"> <name>Comparison with RFC 8488</name> <t> <xref target="RFC8488" sectionFormat="of"section="3.2.1"/>section="3.2.1" format="default"/> describes amanifest selectionmanifest-selection approach for RPs that involves collecting allunexpired,unexpired valid manifests for aCA,CA and then selecting from that collection the manifest that has the highest manifestNumber. The approach set out in this document is different from that approach. </t> </section> <section anchor="general-repository-handling"title="Generalnumbered="true" toc="default"> <name>General RepositoryHandling">Handling</name> <t> <xref target="manifest-number-handling"/>format="default"/> contains a specific update to <xref target="RFC9286"/>format="default"/> for the handling of manifest numbers, in order to address one potential permanent invalidity scenario. RPs that encounter other permanent invalidity scenarios should also consider how those can be addressed such that the scenario does not require the relevant CA or TA to perform a key rollover operation. For example, in the event that an RP recognises that a permanent invalidity scenario has occurred, the RP could alert the operator and provide an option to the operator to stop relying on cached data for the affectedrepository,repository so that the CA can rectify the problem. </t> </section> <sectiontitle="Operational Considerations">numbered="true" toc="default"> <name>Operational Considerations</name> <t> CA software may opt to support the manifest number reset functionality in various ways. For example, it could change the manifest filename when the manifestNumber reaches a certain threshold, or it could alert the operator in this scenario and request confirmation that the filename should be changed. </t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> The RPKI primarily exists to support and improve security of the global Internet routing system. Reliability improvements to the RPKI itself, such as outlined in this document, strengthen its dependability (see <xref target="RFC6480" section="8"/>).format="default"/>). </t> <t> See <xref target="replay"/>format="default"/> regarding the effect of skipping the manifestNumber check with respect to replay attacks. To protect against replay attacks in the absence of this check, RPs should ensure that they are verifying the thisUpdate value per the requirements of <xreftarget="RFC9286"/>.target="RFC9286" format="default"/>. </t> <t> <xref target="manifest-sia-check"/>format="default"/> describes an additional protection against certain forms of replay attack. </t> <t> Although this document updates <xreftarget="RFC9286"/>,target="RFC9286" format="default"/>, the security considerations from <xreftarget="RFC9286"/>target="RFC9286" format="default"/> remain relevant. </t> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t> This document has noactions for IANA. </t> </section> <section removeInRFC="true"> <name>Implementation status</name> <t> 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 <xref target="RFC7942" />. 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. </t> <t> According to <xref target="RFC7942" />, "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".IANA actions. </t><section anchor="impl-rpki-client" title="rpki-client"> <t><list style="none" spacing="compact"> <t>Responsible Organization: OpenBSD<vspace blankLines='1' /></t> <t>Location: https://www.rpki-client.org<vspace blankLines='1' /></t> <t>Description: This implementation supports the behaviour described in this document.<vspace blankLines='1' /></t> <t>Level of Maturity: This is a production implementation.<vspace blankLines='1' /></t> <t>Coverage: This implementation includes all of the features described in this specification.<vspace blankLines='1' /></t> <t>Contact Information: Job Snijders, job@sobornost.net</t> </list></t> </section> <section anchor="impl-routinator" title="Routinator"> <t><list style="none" spacing="compact"> <t>Responsible Organization: NLNetLabs<vspace blankLines='1' /></t> <t>Location: https://github.com/NLnetLabs/routinator<vspace blankLines='1' /></t> <t>Description: This implementation supports the behaviour described in this document.<vspace blankLines='1' /></t> <t>Level of Maturity: This is a production implementation.<vspace blankLines='1' /></t> <t>Coverage: This implementation supports the manifest number handling changes described in this specification.<vspace blankLines='1' /></t> <t>Contact Information: NLNetLabs, labs@nlnetlabs.nl</t> </list></t> </section></section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8182.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9286.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6489.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8630.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8488.xml"/> </references> </references> <section anchor="Acknowledgements"title="Acknowledgements">numbered="false" toc="default"> <name>Acknowledgements</name> <t> The authors would like to thank <contact fullname="Theo Buehler"/>, <contact fullname="BenMaddison" />,Maddison"/>, <contact fullname="RobAustein" />,Austein"/>, <contact fullname="TimBruijnzeels" />,Bruijnzeels"/>, <contact fullname="RussHousley" />,Housley"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="LuigiIannone" />,Iannone"/>, <contact fullname="DanieleCeccarelli" />,Ceccarelli"/>, <contact fullname="DarrenDukes" />,Dukes"/>, <contactfullname="Ines Robles" />,fullname="Maria Ines Robles"/>, <contact fullname="BarryLeiba" />,Leiba"/>, <contact fullname="ÉricVyncke" />,Vyncke"/>, <contact fullname="GorryFairhurst" />,Fairhurst"/>, <contact fullname="AndyNewton" />,Newton"/>, <contact fullname="RomanDanyliw" />,Danyliw"/>, <contact fullname="MikeBishop" />,Bishop"/>, and <contact fullname="DebCooley" />Cooley"/> for their review and feedback on this document. </t> </section></middle> <back> <references title="Normative References"> &RFC2119; &RFC6487; &RFC6488; &RFC8174; &RFC8182; &RFC9286; </references> <references title="Informative References"> &RFC6480; &RFC6481; &RFC6489; &RFC7942; &RFC8630; &RFC8488; </references></back> </rfc>