347 lines
11 KiB
XML
347 lines
11 KiB
XML
<?xml version="1.0" encoding="US-ASCII"?>
|
|
|
|
<?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">
|
|
RPKI-Based Policy Without Route Refresh
|
|
</title>
|
|
|
|
<author fullname="Randy Bush" initials="R." surname="Bush">
|
|
<organization>IIJ Research Lab & Arrcus, Inc.</organization>
|
|
<address>
|
|
<postal>
|
|
<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">
|
|
<organization>Arrcus, Inc.</organization>
|
|
<address>
|
|
<postal>
|
|
<street>2077 Gateway Place, Suite #400</street>
|
|
<city>San Jose</city>
|
|
<region>CA</region>
|
|
<code>95119</code>
|
|
<country>United States of America</country>
|
|
</postal>
|
|
<email>keyur@arrcus.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Philip Smith" initials="P." surname="Smith">
|
|
<organization>PFS Internet Development Pty Ltd</organization>
|
|
<address>
|
|
<postal>
|
|
<street>PO Box 1908</street>
|
|
<city>Milton</city>
|
|
<region>QLD</region>
|
|
<code>4064</code>
|
|
<country>Australia</country>
|
|
</postal>
|
|
<email>pfsinoz@gmail.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Mark Tinka" initials="M." surname="Tinka">
|
|
<organization>SEACOM</organization>
|
|
<address>
|
|
<postal>
|
|
<street>Building 7, Design Quarter District, Leslie Avenue, Magaliessig</street>
|
|
<city>Fourways, Gauteng</city>
|
|
<code>2196</code>
|
|
<country>South Africa</country>
|
|
</postal>
|
|
<email>mark@tinka.africa</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date />
|
|
|
|
<abstract>
|
|
|
|
<t>
|
|
A BGP Speaker performing RPKI-based policy should not issue Route
|
|
Refresh to its neighbors because it has received new RPKI data.
|
|
This document updates <xref target="RFC8481"/> by describing how
|
|
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
|
|
reevaluated with respect to new RPKI data.
|
|
</t>
|
|
|
|
</abstract>
|
|
|
|
<note title="Requirements Language">
|
|
|
|
<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>
|
|
As Route Origin Validation dropping Invalids has deployed, some
|
|
BGP speaker implementations have been found which, when receiving new
|
|
RPKI data (VRPs, see <xref target="I-D.ietf-sidrops-8210bis"/>)
|
|
issue a BGP Route Refresh <xref target="RFC7313"/> to all sending
|
|
BGP peers so that it can reevaluate the received paths against the
|
|
new data.
|
|
</t>
|
|
|
|
<t>
|
|
In actual deployment this has been found to be very destructive,
|
|
transferring a serious resource burden to the unsuspecting peers.
|
|
In reaction, RPKI based Route Origin Validation (ROV) has been
|
|
turned off. There have been actual de-peerings.
|
|
</t>
|
|
|
|
<t>
|
|
As RPKI registration and ROA creation have steadily increased,
|
|
this problem has increased, not just proportionally, but on the
|
|
order of the in-degree of ROV implementing BGP speakers. As ASPA
|
|
(<xref target="I-D.ietf-sidrops-aspa-verification"/>) becomes
|
|
used, the problem will increase.
|
|
</t>
|
|
|
|
<t>
|
|
Other mechanisms, such as automated policy provisioning, which
|
|
have flux rates similar to ROV (i.e. on the order of minutes),
|
|
could very well cause similar problems.
|
|
</t>
|
|
|
|
<t>
|
|
Therefore this document updates <xref target="RFC8481"/> by
|
|
describing how to avoid this problem.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="rib" title="Keeping Partial Adj-RIB-In Data">
|
|
|
|
<t>
|
|
If new RPKI data arrive which cause operator policy to invalidate
|
|
the best route, and the BGP speaker did not keep the dropped
|
|
routes, then it would issue a route refresh, which this feature
|
|
aims to prevent.
|
|
</t>
|
|
|
|
<t>
|
|
A route that is dropped by operator policy due to ROV is, by
|
|
nature, considered ineligible to compete for best route, and MUST
|
|
be kept in the Adj-RIB-In for potential future evaluation.
|
|
</t>
|
|
|
|
<t>
|
|
Ameliorating the Route Refresh problem by keeping a full
|
|
Adj-RIB-In can be a problem for resource constrained BGP speakers.
|
|
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
|
|
routes dropped due to ROV, for potential future evaluation.
|
|
</t>
|
|
|
|
<t>
|
|
As storing these routes could cause problems in resource
|
|
constrained devices, there MUST be a global operation, CLI, YANG,
|
|
etc. allowing the operator to enable this feature, storing the
|
|
dropped routes. Such an operator control MUST NOT be per peer, as
|
|
this could cause inconsistent behavior.
|
|
</t>
|
|
|
|
<t>
|
|
As a side note: policy which may drop routes due to RPKI-based
|
|
checks such as ROV (and ASPA, BGPsec <xref target="RFC8205"/>,
|
|
etc. in the future) MUST be run, and the dropped routes saved per
|
|
this section, before non-RPKI policies are run, as the latter may
|
|
change path attributes.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="ops" title="Operational Recommendations">
|
|
|
|
<t>
|
|
Operators deploying ROV and/or other RPKI based policies should
|
|
ensure that the BGP speaker implementation is not causing
|
|
Route Refresh requests to neighbors.
|
|
</t>
|
|
|
|
<t>
|
|
BGP Speakers MUST either keep the full Adj-RIB-In or implement the
|
|
specification in <xref target="rib"/>. Conformance to this
|
|
behavior is a additional, mandatory capability for BGP speakers
|
|
performing ROV.
|
|
</t>
|
|
|
|
<t>
|
|
If the BGP speaker does not implement these recommendations, the
|
|
operator should enable the vendor's control to keep the full
|
|
Adj-RIB-In, sometimes referred to as "soft reconfiguration
|
|
inbound". The operator should then measure to ensure that there
|
|
are no unnecessary Route Refresh requests sent to neighbors.
|
|
</t>
|
|
|
|
<t>
|
|
If the BGP speaker's equipment has insufficient resources to
|
|
support either of the two proposed options (keeping a full
|
|
AdjRibIn or at least the dropped routes), the equipment SHOULD
|
|
either be replaced with capable equipment or SHOULD NOT be used
|
|
for ROV.
|
|
</t>
|
|
|
|
<t>
|
|
The configuration setting in <xref target="rib"/> should only be
|
|
used in very well known and controlled circumstances where the
|
|
scaling issues are well understood and anticipated.
|
|
</t>
|
|
|
|
<t>
|
|
Operators using the specification in <xref target="rib"/> should
|
|
be aware that a misconfigured neighbor might erroneously send a
|
|
massive number of paths, thus consuming a lot of memory. Hence
|
|
pre-policy filtering such as described in <xref
|
|
target="I-D.sas-idr-maxprefix-inbound"/> could be used to reduce
|
|
this exposure.
|
|
</t>
|
|
|
|
<t>
|
|
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
|
|
route selection and in outbound signaling.
|
|
</t>
|
|
|
|
<t>
|
|
Internet Exchange Points (IXPs) which provide <xref
|
|
target="RFC7947"/> Route Servers should be aware that some members
|
|
could be causing an undue Route Refresh load on the Route Servers
|
|
and take appropriate administrative and/or technical measures.
|
|
IXPs using BGP speakers as route servers should ensure that they
|
|
are not generating excessive route refresh requests.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="Security" title="Security Considerations">
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
<t>
|
|
Otherwise, this document adds no additional security considerations
|
|
to those already described by the referenced documents.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="IANA" title="IANA Considerations">
|
|
|
|
<t>
|
|
None
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="acks" title="Acknowledgements">
|
|
|
|
<t>
|
|
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>
|
|
|
|
</middle>
|
|
|
|
<back>
|
|
|
|
<references title="Normative References">
|
|
<?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">
|
|
<?rfc include="reference.RFC.6480.xml"?>
|
|
<?rfc include="reference.RFC.6482.xml"?>
|
|
<?rfc include="reference.RFC.7947.xml"?>
|
|
<?rfc include="reference.RFC.8205.xml"?>
|
|
<?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?>
|
|
<?rfc include="reference.I-D.ietf-sidrops-aspa-verification.xml"?>
|
|
<?rfc include="reference.I-D.sas-idr-maxprefix-inbound.xml"?>
|
|
</references>
|
|
|
|
</back>
|
|
|
|
</rfc>
|