ietf -00 published
This commit is contained in:
parent
310791dbae
commit
e38d2c6d07
1 changed files with 312 additions and 0 deletions
312
draft-ietf-sidrops-rov-no-rr.xml
Normal file
312
draft-ietf-sidrops-rov-no-rr.xml
Normal file
|
|
@ -0,0 +1,312 @@
|
|||
<?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-i-sidrops-rov-no-rr-00"
|
||||
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 (to not be used
|
||||
for best path evaluation etc.) 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>
|
||||
|
||||
<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>
|
||||
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>
|
||||
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 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, John Scudder, Matthias Waehlisch, and Saku Ytti.
|
||||
</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.8481.xml"?>
|
||||
<?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?>
|
||||
<?rfc include="reference.I-D.ietf-sidrops-aspa-verification.xml"?>
|
||||
</references>
|
||||
|
||||
</back>
|
||||
|
||||
</rfc>
|
||||
Loading…
Add table
Add a link
Reference in a new issue