BGP Prefix Origin Validation
updated by
Extracted elements (18)
Although RPKI provides the context for this document, any other database able to map prefixes to their authorized origin ASes may be used instead. Each distinct database has its own operational and security characteristics, which are out of scope.
Like the DNS, the global RPKI presents only a loosely consistent view depending on timing, updating, and fetching. There is no fix for this; it is the nature of distributed data with distributed caches. Thus, one cache or router may have different validation data about a prefix than another.
Validation state is explicitly defined as a local property of the route and MUST NOT by default exclude routes from the Adj-RIB-In or the decision process. This design acknowledges that operators need flexibility to apply local policy rather than having the protocol automatically reject routes.
Each BGP speaker supporting prefix validation is expected to communicate with one or more RPKI caches via the protocol described in RFC 6810. The prefix-to-AS mappings are expected to be updated over time as the RPKI database changes.
When the BGP selection algorithm is influenced by route properties not propagated into IBGP, it may be necessary to propagate the validation state to IBGP peers by setting a community or extended community based on the validation state, and matching it on the receiving side.
An implementation MUST also support four-octet AS numbers (RFC 6793).
An implementation MUST NOT exclude a route from the Adj-RIB-In or from consideration in the decision process as a side effect of its validation state, unless explicitly configured to do so.
An implementation MUST provide the ability to match and set the validation state of routes as part of its route policy filtering function.
The validation state of a Route MUST be set to reflect the result of the lookup. If validation is not performed on a Route, the implementation SHOULD initialize the validation state of such a route to 'NotFound'.
When a BGP speaker receives an UPDATE from a neighbor, it SHOULD perform a prefix-to-AS lookup for each Route in the UPDATE message. The lookup SHOULD also be applied to routes redistributed into BGP from another source, such as another protocol or a locally defined static route.
When a prefix-to-AS mapping is added or deleted, the implementation MUST re-validate any affected prefixes and run the BGP decision process if needed. An 'affected prefix' is any prefix that was matched by a deleted or updated mapping, or could be matched by an added or updated mapping.
A Route Prefix is 'Covered' by a VRP when the VRP prefix length is less than or equal to the Route prefix length and the prefix addresses match for all bits specified by the VRP prefix length. A Route Prefix is 'Matched' by a VRP when it is Covered, the Route prefix length is at most the VRP maximum length, and the Route Origin ASN equals the VRP ASN.
A Validated ROA Payload (VRP) is a locally stored object with content (IP address, prefix length, maximum length, origin AS number), loaded by the BGP speaker from the RPKI cache. VRPs form the database against which BGP routes are validated.
Route Origin ASN is derived from the rightmost AS in the final AS_SEQUENCE segment of AS_PATH; the speaker's own AS if the final segment is AS_CONFED_SEQUENCE, AS_CONFED_SET, or AS_PATH is empty; or the distinguished value 'NONE' for any other final segment type.
The security properties of the validation database (RPKI or other) determine the overall security provided. If an attacker can inject or remove records in the validation database, otherwise valid routes could be marked as invalid, creating a potential denial-of-service vector.
This mechanism should be thought of more as a protection against misconfiguration than as true security in the strong sense. Complete path attestation against the AS_PATH attribute is outside the scope of this document.
This system provides only limited protection against a determined attacker: an attacker need only prepend the 'valid' source AS to a forged BGP route announcement to defeat the protection. It does not protect against AS-in-the-middle attacks or provide any path validation; it only verifies the origin AS.
Each BGP route is assigned one of three validation states: NotFound (no VRP covers the route prefix), Valid (at least one VRP matches the route prefix), or Invalid (at least one VRP covers the route prefix but none matches). The state is computed per the lookup procedure and is a local property of the route.