321 lines
10 KiB
XML
321 lines
10 KiB
XML
<?xml version="1.0" encoding="US-ASCII"?>
|
|
|
|
<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -->
|
|
|
|
<?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-02"
|
|
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 when receiving new RPKI data. A method
|
|
for avoiding doing so is described.
|
|
</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 (<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="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 aginst 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; and 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>
|
|
|
|
</section>
|
|
|
|
<section anchor="rib" title="Keeping Partial Adj-RIB-In Data">
|
|
|
|
<t>
|
|
Ameliorating this 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.
|
|
</t>
|
|
|
|
<t>
|
|
When RPKI data cause one or more paths to be dropped due to ROV,
|
|
those paths MUST NOT be evaluated for best path, but MUST be saved
|
|
(either separately or marked) so they may be reevaluated with
|
|
respect to new RPKI data.
|
|
</t>
|
|
|
|
<t>
|
|
If new RPKI data arrive which invalidate the best path, and the
|
|
BGP speaker did not keep all alternatives, then it MUST issue a
|
|
route refresh so those alternatives may be evaluated for best
|
|
path.
|
|
</t>
|
|
|
|
<t>
|
|
Policy which may drop paths due to RPKI-based checks such as ROV,
|
|
ASPA, BGPsec <xref target="RFC8205"/>, etc. MUST be run, and the
|
|
dropped paths saved per the above paragraph, before non-RPKI
|
|
policies are run, as the latter may change path attributes.
|
|
</t>
|
|
|
|
<t>
|
|
As storing these paths could cause problems in resource
|
|
constrained devices, there MUST be a knob allowing operator
|
|
control of this feature. Such a knob MUST NOT be per peer, as
|
|
this could cause inconsistent behavior.
|
|
</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
|
|
path selection and in outbound signaling.
|
|
</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
|
|
unnecessary 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"/>.
|
|
</t>
|
|
|
|
<t>
|
|
If the BGP speaker does not implement these recommendations, the
|
|
operator SHOULD enable the vendor's knob 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 has insufficient resources to support either of
|
|
the two proposed options, it MUST not be used for Route Origin
|
|
Validation. I.e. the knob in <xref target="rib"/> should only be
|
|
used in very well known and controlled circumstances.
|
|
</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.
|
|
Pre-policy filtering such as described in <xref
|
|
target="I-D.sas-idr-maxprefix-inbound"/> SHOULD be used to reduce
|
|
this exposure.
|
|
</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 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.4271.xml"?>
|
|
<?rfc include="reference.RFC.7313.xml"?>
|
|
<?rfc include="reference.RFC.8174.xml"?>
|
|
<?rfc include="reference.I-D.sas-idr-maxprefix-inbound.xml"?>
|
|
</references>
|
|
|
|
<references title="Informative References">
|
|
<?rfc include="reference.RFC.6480.xml"?>
|
|
<?rfc include="reference.RFC.6482.xml"?>
|
|
<?rfc include="reference.RFC.6811.xml"?>
|
|
<?rfc include="reference.RFC.7947.xml"?>
|
|
<?rfc include="reference.RFC.8205.xml"?>
|
|
<?rfc include="reference.RFC.8481.xml"?>
|
|
<?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?>
|
|
<?rfc include="reference.I-D.ietf-sidrops-aspa-verification.xml"?>
|
|
</references>
|
|
|
|
</back>
|
|
|
|
</rfc>
|