a lot of new text to respond to hilliard and maddison
This commit is contained in:
parent
3d02593371
commit
f6b743e810
1 changed files with 92 additions and 32 deletions
|
|
@ -10,7 +10,9 @@
|
|||
<?rfc compact="yes"?>
|
||||
<?rfc subcompact="no"?>
|
||||
|
||||
<rfc category="info" docName="draft-ymbk-sidrops-rov-no-rr-01" ipr="trust200902">
|
||||
<rfc category="std" consensus="true"
|
||||
docName="draft-ymbk-sidrops-rov-no-rr-02"
|
||||
ipr="trust200902" updates="8481">
|
||||
|
||||
<front>
|
||||
|
||||
|
|
@ -119,47 +121,106 @@
|
|||
Invalidated paths so the 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="related" title="Related Work">
|
||||
<section anchor="experience" title="ROV Experience">
|
||||
|
||||
<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>
|
||||
<t>
|
||||
As Route Origin Validation dropping Invalids has depoyed, 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>
|
||||
|
||||
</section>
|
||||
<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.
|
||||
</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 chosn 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>
|
||||
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 this
|
||||
specification.
|
||||
Routers MUST either keep the full Adj-RIB-In or implement the
|
||||
specification in <xref target="rib"/>.
|
||||
</t>
|
||||
|
||||
<t>
|
||||
Operators deploying ROV SHOULD ensure that the router
|
||||
implementation is not causing unnecessary Route Refresh requests
|
||||
to neighbors.
|
||||
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 the recommendations here, the
|
||||
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 ensure that this stops
|
||||
unnecessary Route Refresh requests to neighbors.
|
||||
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.
|
||||
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 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.
|
||||
</t>
|
||||
|
||||
</section>
|
||||
|
|
@ -167,9 +228,9 @@
|
|||
<section anchor="Security" title="Security Considerations">
|
||||
|
||||
<t>
|
||||
This document describes a denial of service Route Origin
|
||||
Validation may place on a BGP neighbor, and describes how it may
|
||||
be ameliorated.
|
||||
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>
|
||||
|
|
@ -194,27 +255,26 @@
|
|||
<references title="Normative References">
|
||||
<?rfc include="reference.RFC.2119.xml"?>
|
||||
<?rfc include="reference.RFC.4271.xml"?>
|
||||
<?rfc include="reference.RFC.6482.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"?>
|
||||
<?rfc include="reference.I-D.ietf-sidrops-8210bis.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"?>
|
||||
</references>
|
||||
|
||||
<!--
|
||||
<section anchor="Acknowledgements" title="Acknowledgements">
|
||||
|
||||
<t>
|
||||
The authors wish to thank Philip Smith and Mark Tinka.
|
||||
The authors wish to thank Ben Maddison and Nick Hilliard.
|
||||
</t>
|
||||
|
||||
</section>
|
||||
-->
|
||||
|
||||
</back>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue