Policy Based on the Resource Public Key Infrastructure (RPKI) without Route RefreshIIJ Research Lab & Arrcus, Inc.1856 SW Edgewood DrPortlandOR97210United States of Americarandy@psg.comArrcus, Inc.2077 Gateway Place, Suite #400San JoseCA95119United States of Americakeyur@arrcus.comPFS Internet Development Pty LtdPO Box 1908MiltonQLD4064Australiapfsinoz@gmail.comSEACOMBuilding 7, Design Quarter DistrictLeslie Avenue, MagaliessigFourways, Gauteng2196South Africamark@tinka.africa
ops
sidrops
A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKI) should not issue route
refresh to its neighbors because it has received new RPKI data.
This document updates RFC 8481 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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Requirements Language
. Related Work
. ROV Experience
. Keeping Partial Adj-RIB-In Data
. Operational Recommendations
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
Introduction
Memory constraints in early BGP speakers caused classic BGP
implementations to not keep a full Adj-RIB-In
(). When doing
RPKI-based Route Origin Validation (ROV) 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 from its
neighbors to recover the paths that 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.
Requirements Language
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
when, and only when, they appear in all capitals, as shown here.
Related Work
It is assumed that the reader understands BGP ,
route refresh ,
the RPKI ,
Route Origin Authorizations (ROAs) ,
the Resource Public Key Infrastructure (RPKI) to Router Protocol ,
RPKI-Based Prefix Validation ,
and Origin Validation Clarifications .
Note that the term "RPKI-based Route Origin Validation" in this document
means the same as the term "Prefix Origin Validation" used in .
ROV Experience
As Route Origin Validation dropping Invalids has deployed, some
BGP speaker implementations have been found that, when receiving new
RPKI data (Validated ROA Payloads (VRPs) ),
issue a BGP route refresh to all sending
BGP peers so that they can reevaluate the received paths against the
new data.
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.
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 Autonomous System Provider Authorization (ASPA)
becomes
used, the problem will increase.
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.
Therefore, this document updates by
describing how to avoid this problem.
Keeping Partial Adj-RIB-In Data
If new RPKI data arrive that cause operator policy to invalidate
the best route and the BGP speaker did not keep the dropped
routes, then the BGP speaker would issue a route refresh, which this feature
aims to prevent.
A route that is dropped by operator policy due to ROV is, by
nature, considered ineligible to compete for the best route and MUST
be kept in the Adj-RIB-In for potential future evaluation.
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.
As storing these routes could cause problems in resource-constrained
devices, there MUST be a global operation, CLI, YANG, or
other mechanism that allows the operator to enable this feature and
store the dropped routes. Such an operator control MUST NOT be per peer, as this could cause inconsistent behavior.
As a side note, policy that may drop routes due to RPKI-based
checks such as ROV (and ASPA, BGPsec ,
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.
Operational Recommendations
Operators deploying ROV and/or other RPKI-based policies should
ensure that the BGP speaker implementation is not causing
route refresh requests to neighbors.
BGP speakers MUST either keep the full Adj-RIB-In or implement the
specification in . Conformance to this
behavior is an additional, mandatory capability for BGP speakers
performing ROV.
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.
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.
The configuration setting in should only be
used in very well-known and controlled circumstances where the
scaling issues are well understood and anticipated.
Operators using the specification in 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 could be used to reduce
this exposure.
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 outbound signaling.
Internet Exchange Points (IXPs) that provide 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.
Security Considerations
This document describes a denial of service that Route Origin
Validation or other RPKI policy may place on a BGP neighbor and
describes how it may be ameliorated.
Otherwise, this document adds no additional security considerations
to those already described by the referenced documents.
IANA Considerations
This document has no IANA actions.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Route Refresh Capability for BGP-4This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. [STANDARDS-TRACK]A Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]BGP Prefix Origin ValidationTo help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]Enhanced Route Refresh Capability for BGP-4In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner. This document updates RFC 2918.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration.Informative ReferencesBGP AS_PATH Verification Based on Resource Public Key Infrastructure (RPKI) Autonomous System Provider Authorization (ASPA) ObjectsYandexQrator LabsInternet Initiative Japan & Arrcus, Inc.ArrcusFastlyUSA National Institute of Standards and Technology This document defines the semantics of an Autonomous System Provider
Authorization object in the Resource Public Key Infrastructure to
verify the Border Gateway Protocol (BGP) AS_PATH attribute of
advertised routes. This type of AS_PATH verification is primarily
intended for detection and mitigation of route leaks. It also to
some degree provides protection against forged-origin prefix hijacks.
Work in ProgressBGP Maximum Prefix Limits InboundJuniper NetworksIndependentFastlyWork in ProgressAn Infrastructure to Support Secure Internet RoutingThis document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.A Profile for Route Origin Authorizations (ROAs)This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK]Internet Exchange BGP Route ServerThis document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers.BGPsec Protocol SpecificationThis document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2IIJ, Arrcus, & DRLDragon Research Labs In order to verifiably validate the origin Autonomous Systems and
Autonomous System Paths of BGP announcements, routers need a simple
but reliable mechanism to receive Resource Public Key Infrastructure
(RFC 6480) prefix origin data and router keys from a trusted cache.
This document describes a protocol to deliver them.
This document describes version 2 of the RPKI-Router protocol. RFC
6810 describes version 0, and RFC 8210 describes version 1. This
document is compatible with both.
Work in ProgressAcknowledgements
The authors wish to thank , , , , , , ,
, and .
Authors' AddressesIIJ Research Lab & Arrcus, Inc.1856 SW Edgewood DrPortlandOR97210United States of Americarandy@psg.comArrcus, Inc.2077 Gateway Place, Suite #400San JoseCA95119United States of Americakeyur@arrcus.comPFS Internet Development Pty LtdPO Box 1908MiltonQLD4064Australiapfsinoz@gmail.comSEACOMBuilding 7, Design Quarter DistrictLeslie Avenue, MagaliessigFourways, Gauteng2196South Africamark@tinka.africa