ferrix/docs/content/docs/guides/rpki.md

+++ title = "RPKI Origin Validation and ASPA" description = "Describes route origin validation (RFC 6811) and AS path verification with ASPA, using data received from RPKI caches over the RPKI-to-Router protocol." weight = 4

[extra] nav = "RPKI and ASPA" +++

The Resource Public Key Infrastructure (RPKI) allows the holders of IP address space and AS numbers to publish signed authorizations. Ferrix uses two kinds of authorization:

• A Route Origin Authorization (ROA) specifies which AS can originate routes for a prefix.
• An Autonomous System Provider Authorization (ASPA) specifies the transit providers of an AS.

RPKI validators, such as Routinator, rpki-client with StayRTR, and FORT, retrieve and verify these objects. A router receives the result from the validator's cache over the RPKI-to-Router (RTR) protocol (RFC 8210). Ferrix includes an RTR client.

Configuring RPKI Caches

The rpki statement specifies one or more RPKI caches:

rpki {
  caches { address: "127.0.0.1" port: 3323 }
  caches { address: "192.0.2.53" port: 3323 }
}

Ferrix connects to one cache at a time, in the order in which they are configured, and connects to the next cache if the current one fails. The port is required.

Ferrix requests RTR version 2 (draft-ietf-sidrops-8210bis), which includes ASPA data. If the cache supports only version 1 or 0, Ferrix uses that version. The status page displays the version in use, and displays a warning if the version does not include ASPA data.

Timers

By default, Ferrix uses the refresh, retry, and expire intervals that the cache provides. You can configure them as follows:

rpki {
  caches { address: "127.0.0.1" port: 3323 }
  refresh_seconds: 3600
  retry_seconds: 600
  expire_seconds: 7200
}

Statement	Description	Default
refresh_seconds	Interval at which Ferrix requests updates from the cache	Cache value, or 3600 seconds
retry_seconds	Interval after which Ferrix retries a failed request	Cache value, or 600 seconds
expire_seconds	Time after which Ferrix discards data that no cache has confirmed	Cache value, or 7200 seconds

When the data expires, Ferrix discards it, and no route is considered invalid until new data is received.

A validator that has just started reports that it has no data available until its first validation run is complete, which takes several minutes. Ferrix then asks again after 30 seconds, or after retry_seconds if that is shorter, rather than after the retry interval.

Running a Validator

The following command starts Routinator with an RTR server on port 3323:

routinator server --rtr 127.0.0.1:3323

Caution

The RTR connection uses plain TCP, without authentication or integrity protection. Run the validator on the same host or on a trusted network. An attacker who can modify RTR data can cause valid routes to be rejected, or can disable ASPA verification by negotiating an older protocol version.

Route Origin Validation

Route origin validation (ROV) compares the origin AS and prefix length of a route with the Validated ROA Payloads (VRPs) received from the cache (RFC 6811). Ferrix validates every route from an EBGP neighbor. The result is one of the following states:

• Invalid: a VRP covers the prefix, but no VRP authorizes the origin AS for the prefix length. Ferrix rejects the route with the reason RPKI invalid, unless the neighbor's import policy includes accept_rpki_invalid: true.
• Valid: a VRP authorizes the origin AS for the prefix length. Ferrix accepts the route.
• Not found: no VRP covers the prefix. Ferrix accepts the route.

The validation state does not otherwise affect best path selection.

AS Path Verification with ASPA

Route origin validation verifies only the origin AS. It does not detect a route leak, or a forged AS path that ends with the correct origin AS. ASPA verification (draft-ietf-sidrops-aspa-verification, version 24) checks that each AS in the path is permitted to advertise the route to the next AS, according to the ASPAs of the ASs in the path.

ASPA verification requires the following:

• An RPKI cache that supports RTR version 2.
• A role for the neighbor, because the permitted shape of an AS path depends on the direction from which the route is received. Table 1 lists the verification that applies to each role.

Role	Verification
CUSTOMER	Upstream: the path must consist of customer-to-provider hops only.
PEER	Upstream.
ROUTE_SERVER	Upstream. The path need not begin with the route server's AS number.
ROUTE_SERVER_CLIENT	Upstream.
PROVIDER	Downstream: the path can contain upstream hops, one peering hop, and downstream hops.

Ferrix does not verify the AS paths of routes from a neighbor without a role; it performs only route origin validation for them.

The result is one of the following states:

• Invalid: Ferrix rejects the route with the reason ASPA invalid, unless the neighbor's import policy includes accept_aspa_invalid: true. An AS path that contains an AS_SET is invalid. An AS path that does not begin with the neighbor's AS number is invalid, except for routes from a route server.
• Valid: Ferrix accepts the route.
• Unknown: Ferrix accepts the route. Most AS paths are unknown while ASPA deployment is limited.

Revalidation

RPKI data changes continuously. Ferrix revalidates affected routes when the data changes, without requiring the neighbor to readvertise them:

• A route in the routing table that becomes invalid is removed.
• A route that was rejected as invalid is retained as a held route. When the route is no longer invalid, Ferrix accepts it.

The status page displays the number of held routes for each neighbor.

Verifying RPKI Validation

The status page displays the cache, the RTR version, the age of the data, and the validation state of each received route. The HTTP API provides the same information at /api/rpki. Table 2 lists the related metrics.

Metric	Description
bgp_rpki_vrps{family}	Number of VRPs in use, by address family
bgp_rpki_aspas	Number of customer ASs with an ASPA in use
bgp_rpki_updates_total	Number of times the VRPs or ASPAs changed
bgp_routes_rejected_total{reason="RPKI invalid"}	Routes rejected by route origin validation
bgp_routes_rejected_total{reason="ASPA invalid"}	Routes rejected by ASPA verification

Limitations

• Routes from IBGP neighbors and originated routes are not validated.
• The validation state is not used as a step in best path selection.
• The AS paths of advertised routes are not verified.
• RTR is supported over plain TCP only; SSH, TLS, TCP-MD5, and TCP-AO are not supported.