rfc9324xml2.original.xml   rfc9324.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" consensus="true"
submissionType="IETF"
docName="draft-ietf-sidrops-rov-no-rr-08"
ipr="trust200902" updates="8481">
<front>
<title abbrev="RPKI-Based Policy Without Route Refresh"> <!DOCTYPE rfc [
RPKI-Based Policy Without Route Refresh <!ENTITY nbsp "&#160;">
</title> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<author fullname="Randy Bush" initials="R." surname="Bush"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<organization>IIJ Research Lab &amp; Arrcus, Inc.</organization> std" consensus="true" docName="draft-ietf-sidrops-rov-no-rr-08" number="9324" ip
<address> r="trust200902" updates="8481" obsoletes="" sortRefs="true" symRefs="true" tocIn
<postal> clude="true" tocDepth="3" xml:lang="en" version="3">
<street>1856 SW Edgewood Dr</street>
<city>Portland</city>
<region>Oregon</region>
<code>97210</code>
<country>United States of America</country>
</postal>
<email>randy@psg.com</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K." surname="Patel"> <front>
<organization>Arrcus, Inc.</organization> <title abbrev="RPKI-Based Policy without Route Refresh">Policy Based on the
<address> Resource Public Key Infrastructure (RPKI) without Route Refresh</title>
<postal> <seriesInfo name="RFC" value="9324"/>
<street>2077 Gateway Place, Suite #400</street> <author fullname="Randy Bush" initials="R." surname="Bush">
<city>San Jose</city> <organization>IIJ Research Lab &amp; Arrcus, Inc.</organization>
<region>CA</region> <address>
<code>95119</code> <postal>
<country>United States of America</country> <street>1856 SW Edgewood Dr</street>
</postal> <city>Portland</city>
<email>keyur@arrcus.com</email> <region>OR</region>
<code>97210</code>
<country>United States of America</country>
</postal>
<email>randy@psg.com</email>
</address> </address>
</author> </author>
<author fullname="Keyur Patel" initials="K." surname="Patel">
<author fullname="Philip Smith" initials="P." surname="Smith"> <organization>Arrcus, Inc.</organization>
<organization>PFS Internet Development Pty Ltd</organization> <address>
<address> <postal>
<postal> <street>2077 Gateway Place, Suite #400</street>
<street>PO Box 1908</street> <city>San Jose</city>
<city>Milton</city> <region>CA</region>
<region>QLD</region> <code>95119</code>
<code>4064</code> <country>United States of America</country>
<country>Australia</country> </postal>
</postal> <email>keyur@arrcus.com</email>
<email>pfsinoz@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Philip Smith" initials="P." surname="Smith">
<author fullname="Mark Tinka" initials="M." surname="Tinka"> <organization>PFS Internet Development Pty Ltd</organization>
<organization>SEACOM</organization> <address>
<address> <postal>
<postal> <street>PO Box 1908</street>
<street>Building 7, Design Quarter District, Leslie Avenue, Magaliessig</ <city>Milton</city>
street> <region>QLD</region>
<city>Fourways, Gauteng</city> <code>4064</code>
<code>2196</code> <country>Australia</country>
<country>South Africa</country> </postal>
</postal> <email>pfsinoz@gmail.com</email>
<email>mark@tinka.africa</email>
</address> </address>
</author> </author>
<author fullname="Mark Tinka" initials="M." surname="Tinka">
<organization>SEACOM</organization>
<address>
<postal>
<extaddr>Building 7, Design Quarter District</extaddr>
<street>Leslie Avenue, Magaliessig</street>
<city>Fourways, Gauteng</city>
<code>2196</code>
<country>South Africa</country>
</postal>
<email>mark@tinka.africa</email>
</address>
</author>
<date year="2022" month="December" />
<date /> <area>ops</area>
<workgroup>sidrops</workgroup>
<abstract>
<t> <abstract>
A BGP Speaker performing RPKI-based policy should not issue Route <t>
Refresh to its neighbors because it has received new RPKI data. A BGP speaker performing policy based on the Resource Public Key Infrastru
This document updates <xref target="RFC8481"/> by describing how cture (RPKI) should not issue route
refresh to its neighbors because it has received new RPKI data.
This document updates RFC 8481 by describing how
to avoid doing so by either keeping a full Adj-RIB-In or saving to avoid doing so by either keeping a full Adj-RIB-In or saving
paths dropped due to ROV (Route Origin Validation) so they may be paths dropped due to ROV (Route Origin Validation) so they may be
reevaluated with respect to new RPKI data. reevaluated with respect to new RPKI data.
</t> </t>
</abstract>
</abstract> </front>
<middle>
<note title="Requirements Language"> <section anchor="intro">
<name>Introduction</name>
<t>
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 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Memory constraints in early BGP speakers caused classic <xref
target="RFC4271"/> BGP implementations to not keep a full
Adj-RIB-In (Sec. 1.1). When doing RPKI-based Route Origin
Validation (ROV) (<xref target="RFC6811"/> and <xref
target="RFC8481"/>), and similar RPKI-based policy, if such a BGP
speaker receives new RPKI data, it might not have kept paths
previously marked as Invalid etc. Such an implementation must
then request a Route Refresh, <xref target="RFC2918"/> and <xref
target="RFC7313"/>, from its neighbors to recover the paths which
might be covered by these new RPKI data. This will be perceived
as rude by those neighbors as it passes a serious resource burden
on to them. This document recommends implementations keep and
mark paths affected by RPKI-based policy, so Route Refresh is no
longer needed.
</t>
</section>
<section anchor="related" title="Related Work">
<t>
It is assumed that the reader understands BGP, <xref
target="RFC4271"/> and Route Refresh <xref target="RFC7313"/>, the
RPKI <xref target="RFC6480"/>, Route Origin Authorizations (ROAs),
<xref target="RFC6482"/>, The Resource Public Key Infrastructure
(RPKI) to Router Protocol <xref
target="I-D.ietf-sidrops-8210bis"/>, RPKI-based Prefix Validation,
<xref target="RFC6811"/>, and Origin Validation Clarifications,
<xref target="RFC8481"/>.
</t>
</section>
<section anchor="experience" title="ROV Experience">
<t> <t>
Memory constraints in early BGP speakers caused classic BGP
implementations <xref target="RFC4271"/> to not keep a full Adj-RIB-In
(<xref target="RFC4271" sectionFormat="of" section="1.1"/>). When doing
RPKI-based Route Origin Validation (ROV) <xref target="RFC6811"/>
<xref target="RFC8481"/> and similar RPKI-based policy, if such a BGP
speaker receives new RPKI data, it might not have kept paths previously
marked as Invalid, etc. Such an implementation must then request a
route refresh <xref target="RFC2918"/> <xref target="RFC7313"/> from its
neighbors to recover the paths that might be covered by these new RPKI
data. This will be perceived as rude by those neighbors as it passes a
serious resource burden on to them. This document recommends
implementations keep and mark paths affected by RPKI-based policy, so
route refresh is no longer needed.
</t>
<section>
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section anchor="related">
<name>Related Work</name>
<t>
It is assumed that the reader understands BGP <xref target="RFC4271"/>,
route refresh <xref target="RFC7313"/>,
the RPKI <xref target="RFC6480"/>,
Route Origin Authorizations (ROAs) <xref target="RFC6482"/>,
the Resource Public Key Infrastructure (RPKI) to Router Protocol <xref targe
t="I-D.ietf-sidrops-8210bis"/>,
RPKI-Based Prefix Validation <xref target="RFC6811"/>,
and Origin Validation Clarifications <xref target="RFC8481"/>.
</t>
<t> Note that the term "RPKI-based Route Origin Validation" in this document
means the same as the term "Prefix Origin Validation" used in <xref
target="RFC6811"/>.
</t>
</section>
<section anchor="experience">
<name>ROV Experience</name>
<t>
As Route Origin Validation dropping Invalids has deployed, some As Route Origin Validation dropping Invalids has deployed, some
BGP speaker implementations have been found which, when receiving new BGP speaker implementations have been found that, when receiving new
RPKI data (VRPs, see <xref target="I-D.ietf-sidrops-8210bis"/>) RPKI data (Validated ROA Payloads (VRPs) <xref target="I-D.ietf-sidrops-82
issue a BGP Route Refresh <xref target="RFC7313"/> to all sending 10bis"/>),
BGP peers so that it can reevaluate the received paths against the issue a BGP route refresh <xref target="RFC7313"/> to all sending
BGP peers so that they can reevaluate the received paths against the
new data. new data.
</t> </t>
<t>
<t> In actual deployment, this has been found to be very destructive,
In actual deployment this has been found to be very destructive,
transferring a serious resource burden to the unsuspecting peers. transferring a serious resource burden to the unsuspecting peers.
In reaction, RPKI based Route Origin Validation (ROV) has been In reaction, RPKI-based Route Origin Validation (ROV) has been
turned off. There have been actual de-peerings. turned off. There have been actual de-peerings.
</t> </t>
<t>
<t>
As RPKI registration and ROA creation have steadily increased, As RPKI registration and ROA creation have steadily increased,
this problem has increased, not just proportionally, but on the this problem has increased, not just proportionally, but on the
order of the in-degree of ROV implementing BGP speakers. As ASPA order of the in-degree of ROV implementing BGP speakers. As Autonomous Sy
(<xref target="I-D.ietf-sidrops-aspa-verification"/>) becomes stem Provider Authorization (ASPA)
<xref target="I-D.ietf-sidrops-aspa-verification"/> becomes
used, the problem will increase. used, the problem will increase.
</t> </t>
<t>
<t>
Other mechanisms, such as automated policy provisioning, which Other mechanisms, such as automated policy provisioning, which
have flux rates similar to ROV (i.e. on the order of minutes), have flux rates similar to ROV (i.e., on the order of minutes),
could very well cause similar problems. could very well cause similar problems.
</t> </t>
<t>
<t> Therefore, this document updates <xref target="RFC8481"/> by
Therefore this document updates <xref target="RFC8481"/> by
describing how to avoid this problem. describing how to avoid this problem.
</t> </t>
</section>
</section> <section anchor="rib">
<name>Keeping Partial Adj-RIB-In Data</name>
<section anchor="rib" title="Keeping Partial Adj-RIB-In Data"> <t>
If new RPKI data arrive that cause operator policy to invalidate
<t> the best route and the BGP speaker did not keep the dropped
If new RPKI data arrive which cause operator policy to invalidate routes, then the BGP speaker would issue a route refresh, which this featu
the best route, and the BGP speaker did not keep the dropped re
routes, then it would issue a route refresh, which this feature
aims to prevent. aims to prevent.
</t> </t>
<t>
<t>
A route that is dropped by operator policy due to ROV is, by A route that is dropped by operator policy due to ROV is, by
nature, considered ineligible to compete for best route, and MUST nature, considered ineligible to compete for the best route and <bcp14>MUS T</bcp14>
be kept in the Adj-RIB-In for potential future evaluation. be kept in the Adj-RIB-In for potential future evaluation.
</t> </t>
<t>
<t> Ameliorating the route refresh problem by keeping a full
Ameliorating the Route Refresh problem by keeping a full Adj-RIB-In can be a problem for resource-constrained BGP speakers.
Adj-RIB-In can be a problem for resource constrained BGP speakers.
In reality, only some data need be retained. If an implementation In reality, only some data need be retained. If an implementation
chooses not to retain the full Adj-RIB-In, it MUST retain at least chooses not to retain the full Adj-RIB-In, it <bcp14>MUST</bcp14> retain a
routes dropped due to ROV, for potential future evaluation. t least
</t> routes dropped due to ROV for potential future evaluation.
</t>
<t> <t>
As storing these routes could cause problems in resource As storing these routes could cause problems in resource-constrained
constrained devices, there MUST be a global operation, CLI, YANG, devices, there <bcp14>MUST</bcp14> be a global operation, CLI, YANG, or
etc. allowing the operator to enable this feature, storing the other mechanism that allows the operator to enable this feature and
dropped routes. Such an operator control MUST NOT be per peer, as store the dropped routes. Such an operator control <bcp14>MUST
this could cause inconsistent behavior. NOT</bcp14> be per peer, as this could cause inconsistent behavior.
</t> </t>
<t>
<t> As a side note, policy that may drop routes due to RPKI-based
As a side note: policy which may drop routes due to RPKI-based
checks such as ROV (and ASPA, BGPsec <xref target="RFC8205"/>, checks such as ROV (and ASPA, BGPsec <xref target="RFC8205"/>,
etc. in the future) MUST be run, and the dropped routes saved per etc., in the future) <bcp14>MUST</bcp14> be run and the dropped routes sav ed per
this section, before non-RPKI policies are run, as the latter may this section, before non-RPKI policies are run, as the latter may
change path attributes. change path attributes.
</t> </t>
</section>
</section> <section anchor="ops">
<name>Operational Recommendations</name>
<section anchor="ops" title="Operational Recommendations"> <t>
Operators deploying ROV and/or other RPKI-based policies should
<t>
Operators deploying ROV and/or other RPKI based policies should
ensure that the BGP speaker implementation is not causing ensure that the BGP speaker implementation is not causing
Route Refresh requests to neighbors. route refresh requests to neighbors.
</t> </t>
<t>
<t> BGP speakers <bcp14>MUST</bcp14> either keep the full Adj-RIB-In or implem
BGP Speakers MUST either keep the full Adj-RIB-In or implement the ent the
specification in <xref target="rib"/>. Conformance to this specification in <xref target="rib"/>. Conformance to this
behavior is a additional, mandatory capability for BGP speakers behavior is an additional, mandatory capability for BGP speakers
performing ROV. performing ROV.
</t> </t>
<t>
<t>
If the BGP speaker does not implement these recommendations, the If the BGP speaker does not implement these recommendations, the
operator should enable the vendor's control to keep the full operator should enable the vendor's control to keep the full
Adj-RIB-In, sometimes referred to as "soft reconfiguration Adj-RIB-In, sometimes referred to as "soft reconfiguration
inbound". The operator should then measure to ensure that there inbound". The operator should then measure to ensure that there
are no unnecessary Route Refresh requests sent to neighbors. are no unnecessary route refresh requests sent to neighbors.
</t> </t>
<t>
<t>
If the BGP speaker's equipment has insufficient resources to If the BGP speaker's equipment has insufficient resources to
support either of the two proposed options (keeping a full support either of the two proposed options (keeping a full
AdjRibIn or at least the dropped routes), the equipment SHOULD AdjRibIn or at least the dropped routes), the equipment <bcp14>SHOULD</bcp
either be replaced with capable equipment or SHOULD NOT be used 14>
either be replaced with capable equipment or <bcp14>SHOULD NOT</bcp14> be
used
for ROV. for ROV.
</t> </t>
<t>
<t>
The configuration setting in <xref target="rib"/> should only be The configuration setting in <xref target="rib"/> should only be
used in very well known and controlled circumstances where the used in very well-known and controlled circumstances where the
scaling issues are well understood and anticipated. scaling issues are well understood and anticipated.
</t> </t>
<t>
<t>
Operators using the specification in <xref target="rib"/> should Operators using the specification in <xref target="rib"/> should
be aware that a misconfigured neighbor might erroneously send a be aware that a misconfigured neighbor might erroneously send a
massive number of paths, thus consuming a lot of memory. Hence massive number of paths, thus consuming a lot of memory. Hence,
pre-policy filtering such as described in <xref pre-policy filtering such as described in <xref target="I-D.sas-idr-maxpre
target="I-D.sas-idr-maxprefix-inbound"/> could be used to reduce fix-inbound"/> could be used to reduce
this exposure. this exposure.
</t> </t>
<t>
<t> If route refresh has been issued toward more than one peer, the
If Route Refresh has been issued toward more than one peer, the
order of receipt of the refresh data can cause churn in both best order of receipt of the refresh data can cause churn in both best
route selection and in outbound signaling. route selection and outbound signaling.
</t> </t>
<t>
<t> Internet Exchange Points (IXPs) that provide route servers <xref target="R
Internet Exchange Points (IXPs) which provide <xref FC7947"/> should be aware that some members
target="RFC7947"/> Route Servers should be aware that some members could be causing an undue route refresh load on the route servers
could be causing an undue Route Refresh load on the Route Servers
and take appropriate administrative and/or technical measures. and take appropriate administrative and/or technical measures.
IXPs using BGP speakers as route servers should ensure that they IXPs using BGP speakers as route servers should ensure that they
are not generating excessive route refresh requests. are not generating excessive route refresh requests.
</t> </t>
</section>
</section> <section anchor="Security">
<name>Security Considerations</name>
<section anchor="Security" title="Security Considerations"> <t>
This document describes a denial of service that Route Origin
<t> Validation or other RPKI policy may place on a BGP neighbor and
This document describes a denial of service which Route Origin
Validation or other RPKI policy may place on a BGP neighbor, and
describes how it may be ameliorated. describes how it may be ameliorated.
</t> </t>
<t>
<t>
Otherwise, this document adds no additional security considerations Otherwise, this document adds no additional security considerations
to those already described by the referenced documents. to those already described by the referenced documents.
</t> </t>
</section>
</section> <section anchor="IANA">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <t>
This document has no IANA actions.
<t> </t>
None </section>
</t> </middle>
<back>
</section> <displayreference target="I-D.ietf-sidrops-8210bis" to="RPKI-ROUTER-PROT-v2"/>
<displayreference target="I-D.ietf-sidrops-aspa-verification" to="AS_PATH-VER"/>
<displayreference target="I-D.sas-idr-maxprefix-inbound" to="MAXPREFIX-INBOUND"/
>
<section anchor="acks" title="Acknowledgements"> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
918.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
811.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
313.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
481.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
482.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
947.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
205.xml"/>
<t> <!-- [I-D.ietf-sidrops-8210bis] in MISSREF state as of 09/22/22 -->
The authors wish to thank Alvaro Retana, Ben Maddison, Derek
Yeung, John Heasley, John Scudder, Matthias Waehlisch, Nick
Hilliard, Saku Ytti, and Ties de Kock.
</t>
</section> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-sidrops-8210bis.xml"/>
</middle> <!-- [I-D.ietf-sidrops-aspa-verification] IESG state I-D Exists. xi:include miss ing editor role -->
<back> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-sidrops-aspa-verification.xml"/>
<references title="Normative References"> <!-- [I-D.sas-idr-maxprefix-inbound] IESG state Expired -->
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2918.xml"?>
<?rfc include="reference.RFC.4271.xml"?>
<?rfc include="reference.RFC.6811.xml"?>
<?rfc include="reference.RFC.7313.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.8481.xml"?>
</references>
<references title="Informative References"> <reference anchor="I-D.sas-idr-maxprefix-inbound" target="https://datatra
<?rfc include="reference.RFC.6480.xml"?> cker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-04">
<?rfc include="reference.RFC.6482.xml"?> <front>
<?rfc include="reference.RFC.7947.xml"?> <title>BGP Maximum Prefix Limits Inbound</title>
<?rfc include="reference.RFC.8205.xml"?> <author initials="M." surname="Aelmans" fullname="Melchior Aelmans">
<?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?> <organization>Juniper Networks</organization>
<?rfc include="reference.I-D.ietf-sidrops-aspa-verification.xml"?> </author>
<?rfc include="reference.I-D.sas-idr-maxprefix-inbound.xml"?> <author initials="M." surname="Stucchi" fullname="Massimiliano Stucch
</references> i">
<organization>Independent</organization>
</author>
<author initials="J." surname="Snijders" fullname="Job Snijders">
<organization>Fastly</organization>
</author>
<date month="January" day="19" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-sas-idr-maxprefix-inboun
d-04"/>
</reference>
</references>
</references>
</back> <section anchor="acks" numbered="false">
<name>Acknowledgements</name>
<t>
The authors wish to thank <contact fullname="Alvaro Retana"/>, <contact
fullname="Ben Maddison"/>, <contact fullname="Derek Yeung"/>, <contact
fullname="John Heasley"/>, <contact fullname="John Scudder"/>, <contact
fullname="Matthias Waehlisch"/>, <contact fullname="Nick Hilliard"/>,
<contact fullname="Saku Ytti"/>, and <contact fullname="Ties de Kock"/>.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 50 change blocks. 
283 lines changed or deleted 302 lines changed or added

This html diff was produced by rfcdiff 1.48.