Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export
updates
- rfc-6811 — BGP Prefix Origin Validation
Extracted elements (11)
Egress policy handling can provide more robust protection for outbound eBGP than relying solely on ingress (iBGP, eBGP, connected, static, etc.) redistribution being configured and working correctly — i.e., better support for the robustness principle.
This document does not change the protocol or semantics of RFC 6811; it clarifies that implementations must use the effective origin AS (post-egress-policy) rather than the RIB origin AS when performing egress RPKI origin validation.
The effective origin AS used for egress validation may differ from the route's origin AS in the RIB due to commonly applied knobs such as removal of private ASes, AS path manipulation, confederation handling (RFC 5065), and AS migration (RFC 7705).
A validating BGP speaker MUST apply Route Origin Validation policy semantics after applying any egress configuration and policy, using the effective origin AS of the UPDATE to be sent.
An implementation SHOULD be able to list announcements that were not sent to a peer (e.g., because they were marked Invalid), as long as the router still has them in memory.
Any AS_PATH modifications resulting in an effective origin AS change MUST be taken into account when performing egress origin validation.
BGP implementations supporting RPKI-based origin validation MUST provide the same policy configuration primitives for validation-state-based decisions in ingress, redistribution, and egress policies.
It SHOULD be possible to specify a selective origin validation policy to be applied after any existing non-validating outbound policies, to handle complex configurations where the effective origin AS may not be easily determined early.
When applied to egress policy, validation state MUST be determined using the effective origin AS of the route as it will (or would) be announced to the peer, not the origin AS stored in the RIB.
The 'effective origin AS' is the Route Origin Autonomous System Number of the UPDATE to be sent to neighboring BGP speakers, as determined by configuration and outbound policy — which may differ from the origin AS in the RIB due to private AS removal, confederation handling, AS migration, or other AS_PATH modifications.
This document does not create security considerations beyond those of RFC 6811 and RFC 8481. By facilitating more correct validation using the effective origin AS at egress, it attempts to improve BGP reliability.