Export of BGP Prefix Origin Validation in IP Flow Information Export (IPFIX)

Introduction The RPKI provides a cryptographic framework for validating the association between IP address blocks and Autonomous System (AS) numbers. BGP Prefix Origin Validation, as defined in , enables routers to verify whether the origin AS of a BGP route announcement is authorized to advertise the corresponding IP prefix, based on Route Origin Authorizations (ROAs) in the RPKI. When BGP Prefix Origin Validation is enabled on a router, the router maintains a local cache of Validated ROA Payloads (VRPs) obtained through the RPKI-to-Router protocol (RTR) . For each received BGP UPDATE message, the router extracts the announced IP prefix and its origin AS, compares this tuple against the local VRP cache, and assigns a validation state (valid, invalid, not-found) according to the algorithm specified in . This validation state can be attached as a local path attribute to the BGP route entry and influence subsequent routing decisions, such as route filtering and route preference adjustment. While this validation mechanism enhances BGP security, network operators currently lack standardized methods to monitor the validation states across their network infrastructure. IP Flow Information Export (IPFIX) provides a standard protocol for exporting flow information from network devices. This document defines a new IPFIX Information Element specifically designed for monitoring the state of RPKI-based BGP Prefix Origin Validation. The element enables network operators to collect, analyze, and monitor the validation states of BGP routes across their network infrastructure.

Terminology

Terms Used in This Document This document uses the following terms defined in . Validated ROA Payload (VRP): A locally stored object which contains the content (IP address, prefix length, maximum length, origin AS number). Prefix: (IP address, prefix length), interpreted as is customary (see ). Route: Data derived from a received BGP UPDATE, as defined in . Additionally, this document uses the terms defined in . Observation Point: An Observation Point is a location in the network where packets can be observed. Examples include a line to which a probe is attached; a shared medium, such as an Ethernet-based LAN; a single port of a router; or a set of interfaces (physical or logical) of a router. Exporter: A device that hosts one or more Exporting Processes is termed an Exporter. IPFIX Device: An IPFIX Device hosts at least one Exporting Process. It may host further Exporting Processes as well as arbitrary numbers of Observation Points and Metering Processes. Information Element: An Information Element is a protocol and encoding independent description of an attribute that may appear in an IPFIX Record. Information Elements are defined in the IANA "IPFIX Information Elements" registry (see IANA-IPFIX). The type associated with an Information Element indicates constraints on what it may contain and also determines the valid encoding mechanisms for use in IPFIX. Exporting Process: The Exporting Process sends IPFIX Messages to one or more Collecting Processes. The Flow Records in the Messages are generated by one or more Metering Processes. Collecting Process: A Collecting Process receives IPFIX Messages from one or more Exporting Processes. The Collecting Process might process or store Flow Records received within these Messages, but such actions are out of scope for this document.

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.

IPFIX IEs for BGP Prefix Origin Validation This section defines a new IPFIX Information Element for monitoring RPKI-based BGP Prefix Origin Validation.

bgpPrefixOriginValidationState

Name:: bgpPrefixOriginValidationState
ElementID:: TBD1
Description:: This element describes the result of comparing a BGP route prefix derived from a BGP UPDATE message against VRP obtained from RPKI server. The validation algorithm follows . The result of BGP Prefix Origin Validation is used for the active route of a specific BGP prefix. The validation state value is carried in an unsigned integer, using code points aligned with for the validation outcomes. 0: valid - At least one Validated ROA Payload (VRP) matches the route prefix and origin AS. 1: not found - No VRP covers the route prefix. 2: invalid - At least one VRP covers the route prefix, but no VRP matches it. Values 3 - 255 are reserved for future use. Exporting Processes MUST NOT send reserved values. Collecting Processes SHOULD ignore any received reserved values. Regarding the potential differences in RPKI validation states from various perspectives as discussed in RFC 8893, the state reported by this IE is derived from the local device's RPKI validation result and corresponds to the active route present in the LocRIB (Local Routing Information Base). The IE does not address state differences due to varying perspectives nor represents states conveyed via extended communities.
Abstract Data Type:: unsigned8
Data Type Semantics:: identifier
Additional Information:: See the definition of validation state of BGP route prefix.
Reference:: , , , this document.

Operational Considerations The Observation Point for monitoring BGP Prefix Origin Validation states is typically the router performing the validation. The router acting as an IPFIX Exporter is expected to have BGP Prefix Origin Validation enabled and properly configured. This includes establishing RTR sessions with RPKI cache servers and ensuring the local VRP cache is synchronized. When the observed route is non-active, or when BGP Prefix Origin Validation is not enabled or partially enabled, the IPFIX Collector may design different templates based on monitoring requirements to establish a complete routing context and enable accurate analysis. When network operators design a template for IPFIX export of BGP Prefix Origin Validation information export, which should combine with other context informations, such as sourceIPv4Prefix/sourceIPv6Prefix, sourceIPv4PrefixLength/sourceIPv6PrefixLength, bgpSourceAsNumber, as defined in . In scenarios of network changes or maintenance, frequent export of IPFIX records for BGP validation states may lead to considerable overhead on router resources and bandwidth. Operators should balance monitoring needs with performance impact by using thresholds, adjusted export intervals, or focused sampling, such as prioritizing invalid states, refer to for sampling and filtering strategies.

Security Considerations The security considerations for IPFIX in general discussed in , and those for RPKI and BGP Prefix Origin Validation discussed in apply to this document. The IPFIX data records containing BGP Prefix Origin Validation state SHOULD be transported using security protocols (such as TLS, DTLS) and satisfy the mutual authentication between IPFIX Exporting Processes and IPFIX Collecting Processes as specified in . An implementation may use BGP Prefix Origin Validation state as the information input for network routing policies. Network operators should ensure that the data collection and storage of BGP Prefix Origin Validation state comply with applicable privacy regulations.

IANA Considerations IANA is requested to assign a new Information Element ID in the IPFIX Information Elements registry. Information Element bgpPrefixOriginValidationState with Element ID TBD1.