bgp rpki

Pre-Alpha. This page describes behavior that may change.

RPKI origin validation via the RTR protocol (RFC 6811, RFC 8210) and ASPA path verification with policy enforcement (RTR v2, RFC 9582, draft-ietf-sidrops-aspa-verification). Connects to RTR cache servers, downloads Validated ROA Payloads (VRPs) and ASPA records, applies origin validation (RFC 6811) and upstream path verification to received routes. ASPA policy enforcement supports reject/log-only/accept actions.

Configuration

plugin {
    internal rpki       { use bgp-rpki }
    internal adj-rib-in { use bgp-adj-rib-in }
}

bgp {
    rpki {
        cache-server 192.0.2.1 { port 323; }
        action { invalid reject; }
    }

    peer upstream {
        process rpki       { receive [ update ] }
        process adj-rib-in { receive [ update state ] }
    }
}

Full reference on the RPKI configuration page.

Behaviour

For every received UPDATE, the plugin extracts the origin AS (the rightmost AS in the final AS_SEQUENCE segment), looks up covering VRPs for each NLRI prefix, and computes one of three states per RFC 6811: Valid, Invalid, or NotFound. Invalid routes are rejected by default. NotFound and Valid routes are accepted.

When ASPA validation is enabled (aspa { validation true; }) and the RTR session negotiates v2, the plugin also verifies the AS_PATH against ASPA records. The path is normalized (consecutive duplicate removal, confederation stripping), and each adjacent hop pair is checked against the ASPA cache. The result (Valid, Invalid, or Unknown) is included as "aspa-state" in the RPKI event JSON. ASPA policy enforcement is configurable via rpki/aspa/action/invalid (reject/log-only/accept). The origin and ASPA action blocks can also be set per peer or per group.

The plugin holds routes in the bgp-adj-rib-in validation gate while it computes the state. If the plugin does not respond within validation-timeout seconds (default 30), pending routes are fail-open promoted to installed. When every RTR cache server disconnects, the existing VRP cache is retained until a connection comes back.

A prefix the plugin cannot parse gets Invalid, never NotFound: NotFound states that the VRP set was consulted, and the default not-found accept action would accept a route on that reading.

When the VRP set changes, every tracked route is re-validated (RFC 6811 Section 4) and the decision is applied to routes that are already INSTALLED, not only to routes still pending. An accept rewrites the state in place and keeps the sequence number; a reject removes the route.

Polling follows RFC 8210 Section 6: the Refresh Interval from the End Of Data PDU after a completed sync, and the Retry Interval after a failed query or before any query has ever succeeded.

show bgp rpki status separates two states that used to look like one. running says a cache server is CONFIGURED. synced says one completed a sync and delivered a VRP set. sessions-synced counts them, and each cache server entry carries its own synced.

show bgp rpki roa and show bgp rpki aspa, plus the ASPA customer lookup, answer a sorted, stable row order rather than the order a Go map happened to hand back, which used to differ on every call. Past the row limit show bgp rpki roa truncates at, this was not only an ordering problem: a map-ranging walk can break out at the limit anywhere in iteration order, so an operator diagnosing an RPKI problem could see a different VRP set on successive calls to the same command with nothing telling them so. ROAs now sort by prefix address, then prefix length, then by VRP max-length and origin AS, so the rows a limit keeps are the same on every call. show bgp rpki aspa also answers the same shape, a row set under entries, whether or not it is given a customer ASN, so a caller does not need to know the argument to read the answer.

Blackhole exemption

peer / rpki / blackhole-exempt (boolean, default false) keeps a route carrying a blackhole community when its only origin-validation fault is that the prefix is longer than a covering VRP allows. It is narrow by construction: the covering VRP must name the route's own origin AS, so a wrong origin AS stays Invalid. It reads the communities the SAME session agreed in its blackhole container, so a peer running RTBH on its own community gets the exemption for that community. See RPKI.

The plugin emits rpki events that other plugins can subscribe to. bgp-rpki-decorator consumes those events and produces merged update-rpki events that combine the UPDATE and the validation state in one envelope.

Metrics

Registered via ConfigureMetrics on the plugin registration.

Metric	Type	Meaning
`ze_rpki_vrps_cached`	gauge	VRPs currently in the ROA cache.
`ze_rpki_sessions_active`	gauge	Active RTR cache sessions.
`ze_rpki_validation_outcomes_total{result}`	counter	RPKI validation outcomes, labelled by `result` (valid / invalid / notfound).