295 lines
9 KiB
XML
295 lines
9 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"
|
|
docName="draft-ymbk-sidrops-rov-no-rr-03"
|
|
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 routers 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 but 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
|
|
router 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 routers. 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 routers. In reality, only some
|
|
data need be retained.
|
|
</t>
|
|
|
|
<t>
|
|
When RPKI data cause one or more paths to be dropped, withdrawn,
|
|
or merely not chosen as best path due to RPKI-based policy (ROV,
|
|
ASPA, etc.), those paths MUST be saved and marked so that later
|
|
VRPs can reevaluate them against then current policy.
|
|
</t>
|
|
|
|
<t>
|
|
Policy which may drop paths due to RPKI-based checks such as ROV,
|
|
ASPA, BGPsec, 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>
|
|
|
|
</section>
|
|
|
|
<section anchor="ops" title="Operational Recommendations">
|
|
|
|
<t>
|
|
Routers MUST either keep the full Adj-RIB-In or implement the
|
|
specification in <xref target="rib"/>.
|
|
</t>
|
|
|
|
<t>
|
|
Operators deploying ROV and/or other RPKI based policies SHOULD
|
|
ensure that the router implementation is not causing unnecessary
|
|
Route Refresh requests to neighbors.
|
|
</t>
|
|
|
|
<t>
|
|
If the router 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 router has insufficient resources to support this, 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>
|
|
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 routers 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, John Heasley, Nick
|
|
Hilliard, and John Scudder.
|
|
</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"?>
|
|
</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.8481.xml"?>
|
|
<?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?>
|
|
<?rfc include="reference.I-D.ietf-sidrops-aspa-verification.xml"?>
|
|
</references>
|
|
|
|
</back>
|
|
|
|
</rfc>
|