| Internet-Draft | BMP-RPKI-MON-REQS | October 2025 |
| Wang, et al. | Expires 22 April 2026 | [Page] |
This document outlines requirements for extending the BGP Monitoring Protocol (BMP) to provide comprehensive monitoring of RPKI-related processes on routers on routers, including RPKI data acquisition, RPKI-related policy configuration, route validation, and the impact of validation on routing decisions. The proposed extensions aim to standardize router-side monitoring on RPKI within BMP, addressing scalability and interoperability limitations in existing implementations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2026.¶
Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) 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.¶
The Resource Public Key Infrastructure (RPKI) enhances BGP security by enabling cryptographic validation of route origins [RFC6483] [RFC6811] and AS paths [I-D.ietf-sidrops-aspa-verification]. Despite growing adoption of RPKI, standard implementations of the BGP Monitoring Protocol (BMP) [RFC7854] do not natively support monitoring of RPKI-related data. This limitation hampers visibility into RPKI validation processes and their impact on network operations.¶
While existing proposals aim to extend BMP for specific aspects of RPKI monitoring, such as reporting invalid routes [I-D.ietf-grow-bmp-path-marking-tlv] [I-D.ietf-grow-bmp-rel] or providing validation statistics [I-D.ietf-grow-bmp-bgp-rib-stats], a comprehensive and end-to-end monitoring framework for RPKI lifecycle on the router is still lacking. This document defines requirements and extensions for BMP to monitor four key stages:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
The BMP extension for RPKI monitoring SHOULD:¶
Consequently, this document identifies four key stages in the RPKI lifecycle on routers which necessitate detailed monitoring and reporting:¶
To ensure accurate and timely acquisition of RPKI data, network administrators require BMP to provide real-time, consistent monitoring on the health and status of all RPKI data sources. These sources include connections to RPKI caches, local static configurations, and i/eBGP peers. This enables rapid detection and response to faults or outages in data provisioning. Accordingly, BMP SHOULD report the connection parameters, synchronization states, and error metrics for each source.¶
Routing policies on the router may change dynamically, therefore real-time monitoring is necessary to ensure correct implementation and prompt misconfiguration detection of RPKI-based policies. To achieve this, BMP SHOULD report global RPKI enforcement status, RPKI-related validation rules and policies for each peer.¶
Routers from different vendors implement RPKI-based route validation—including origin validation and path validation —with varying approaches. To facilitate accurate troubleshooting against validation outcomes, BMP SHOULD report the RPKI validation state as well as the related rules that contribute to the state.¶
A router may implement numerous routing policies, resulting in complex routing behavior that obscures the influence of RPKI validation on decision-making. To provide visibility into this impact, BMP should report both intended outcomes and unintended side effects that are caused by the RPKI validation process.¶
BMP SHOULD enumerate all sources of RPKI data on the monitored router. These sources include the RPKI-to-Router (RTR) protocol with RPKI cache servers, static configurations, iBGP sessions with the other router within the same AS, and eBGP sessions with the other ASes (mostly upstream providers). For each source, BMP SHOULD report the following relevant information:¶
For RTR sources:¶
For iBGP sources:¶
For eBGP sources:¶
For static configuration sources:¶
To convey this information, a new BMP message type RPKI_SOURCE (Type = TBD1) SHOULD be defined. This message SHALL use the standard BMP common header followed by Type-Length-Value (TLV) elements per [I-D.ietf-grow-bmp-tlv]. TLVs SHALL be grouped per RPKI data source. Each group SHALL use a Group TLV to index Stateless parsing TLVs containing the above fields. A dedicated TLV within each group SHOULD specify the source type to ensure consistency and scalability.¶
BMP SHOULD report the RPKI-related policy configuration, which may be applied globally (uniformly applied across all peers) or on a per-peer basis (For example, only applied to the provider). The reported information SHOULD include:¶
To convey this information, a new BMP message type RPKI_POLICY (Type = TBD2) SHOULD be defined. For global policy configurations, this message SHALL comprise the BMP common header followed by TLVs that specify the validation rules and the actions associated with each non-valid state (i.e., Invalid and Not-Found), such as filtering, priority reduction, tagging, etc. For per-peer policy configurations, the message SHALL include an additional per-peer header, followed by TLVs that detail the RPKI rules and policies specific to each peer.¶
Note that since the size of the total validation rule set could be really large, BMP could only convey the route features of enabled validation rules. These features could be logical combination (AND/OR) of a series of conditions (the origin ASes should be within a certain set, the origin ASes should be a certain role such as the customer, the rule source should only be static or iBGP, etc). The network administrator could combine the features and per-route specific information in the next section to obtain the total validation rules.¶
BMP SHOULD be extended to report both statistical summaries of validation results on a per-peer basis and detailed validation information for each route. For each peer, BMP messages SHOULD include counts of received routes categorized by their RPKI validation states. To improve clarity and emphasize RPKI-specific data, it is RECOMMENDED that a dedicated RPKI Statistics Message RPKI_STAT(Type = TBD3) be introduced by enhancing the original Statistics Report Message.This message specifically report the following RPKI-related statistics:¶
This separation enhances readability and could easily extend to support any future RPKI-related objects.¶
For any individual route, since it may go through multiple types of validations, and may hit multiple validation rules, BMP SHOULD report not only the overall validation state, but also every validation rule which is hit. Therefore, for per-route validation report, it is RECOMMENDED that a dedicated Validation Report Message RPKI_VALIDATION (Type = TBD4) be defined, by enhancing the original Route Monitoring Message with additional TLVs. These TLVs should describe:¶
Note that if the overall validation state is Valid, the specific validation state for every relevant validation rule should be valid; if the overall validation state is Unknown, there shouldn't be any relevant validation rule; if the overall validation state is Invalid, there should be at least one relevant validation rule whose specific validation state is Invalid.¶
BMP SHOULD report the consequences of RPKI validation on route selection, with a particular focus on routes whose selection status is altered by RPKI validation:¶
For each route affected by RPKI validation, the BMP extension SHOULD report:¶
Furthermore, the BMP message SHOULD include information about the alternate best route:¶
This facilitates a direct comparison of routing decisions with and without RPKI, thereby enhancing the understanding of RPKI's influence on BGP path selection.¶
To enable per-route reporting of RPKI's impact on BGP routing, it is RECOMMENDED that a dedicated Validation Impact Message RPKI_IMPACT (Type = TBD5) be defined, by enhancing the original Route Monitoring Message with additional TLVs, to capture changes in route handling due to RPKI validation and policies. When a route is affected—such as being dropped, deprioritized, or superseded by another route-due to RPKI validation, such message could be triggered to report the incident. This message SHOULD include:¶
To ensure the integrity and authenticity of the transmitted monitoring data on RPKI, BMP MUST support the following requirements:¶
To ensure the extended BMP aligns with router's original configuration, BMP MUST support the followign requirements:¶
This document requires IANA to assign values for new BMP message types (TBD1-TBD5) and their associated TLVs. The registration procedures for these assignments SHALL follow the policy outlined in [RFC7854].¶