Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)
updated by
- rfc-9324 — Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh
updates
- rfc-6811 — BGP Prefix Origin Validation
Extracted elements (10)
All prefixes must have their validation state evaluated because if any source is excluded, operators lose the ability to drop Invalid routes from every potential source, making them liable for propagating Invalid routes to neighbors.
The design separates the act of setting validation state from the act of applying policy: routers set state on all routes unconditionally, but policy actions are only taken when the operator explicitly configures them. This prevents unexpected route drops due to implicit default behavior.
This document updates RFC 6811 to clarify that all prefixes (regardless of source) must have their validation state set, and that no policy action may be taken based on that state without explicit operator configuration. Divergent implementations prompted these clarifications.
A router MUST evaluate and set the validation state of all routes in BGP coming from any source (eBGP, iBGP, or redistribution from static or connected routes), unless specifically configured otherwise by the operator.
Absent specific operator configuration, policy based on RPKI origin validation state MUST NOT be applied automatically.
Automatic origin validation policy actions such as those described in RFC 8097 (BGP Prefix Origin Validation State Extended Community) MUST NOT be carried out unless specifically configured by the operator.
If the AS to use during redistribution is ambiguous (e.g., due to confederation, AS migration, or multi-AS configuration), the router configuration MUST provide a means of specifying the AS to be used, either per redistribution or globally.
When redistributing into BGP from any source where there is no AS_PATH, the router MUST use the AS of the router's BGP configuration for RPKI origin validation.
RPKI-based BGP origin validation assigns one of three states to each route: NotFound (no matching ROA), Valid (route matches a ROA), or Invalid (route contradicts a ROA), as defined in RFC 6811.
This document does not create security considerations beyond those of RFC 6811; it only clarifies implementation requirements to ensure consistent behavior across BGP origin validation deployments.