Summary

  • Paweł Foremski's bgpipe can sit between BGP speakers, applying route-origin and ASPA stages to messages before they reach a router. RIPE 92 introduced his work as a way to add ROA and ASPA validation to existing routers.
  • The project's ASPA instructions require a peer role. If an operator chooses --role auto, a peer that omits the BGP Role capability causes ASPA validation to be skipped for that session. The project tells security users to configure the role explicitly.

The router upgrade queue is a convenient place to park a security problem. Paweł Foremski has a less comfortable answer: put a BGP-speaking proxy between existing routers and make the route check happen there. His bgpipe can take live sessions, apply a chain of stages and pass the resulting messages onward. No vendor release is needed to make the software available at that point in the path.

That removes one excuse and reveals another. Route-origin validation asks whether a prefix's origin AS fits a validated ROA payload. ASPA examines the AS path and provider relationships for a route leak. They are different questions. The project's ROV guide describes prefix-level origin states; the ASPA stage classifies a whole path as VALID, UNKNOWN or INVALID. An UNKNOWN path lacks enough attestation. It is not the same result as an invalid one.

ASPA also needs to know what kind of neighbor sent the route. The operator can set --role customer, provider, peer or a route-server role to match its actual BGP arrangement. Or it can use --role auto and take the role from the neighbor's OPEN message. The second choice moves a security decision to the very peer whose path is being checked. If that peer says nothing about its role, bgpipe warns and skips ASPA validation for the session. If it claims a provider or route-server role, different, more permissive checks apply. The project's own documentation says to set an explicit role for security use.

The proxy is therefore a place to enforce an operator's policy, not a substitute for knowing that policy. This is where Foremski's practical contribution gets interesting. A legacy router can keep forwarding while a separate program reads RPKI data, tags a path or withdraws an invalid update. Yet the operator still has to maintain the peer inventory, choose the role and decide what an INVALID result should do. The ASPA stage offers withdraw, drop and keep; keep records a finding without changing the update.

Pipeline order matters too. An earlier ROV stage configured to drop an update leaves nothing for a later ASPA stage to examine. A dashboard built from the latter's counters would then miss those messages. Putting ASPA first preserves its tags and measurements for the full stream. The details sound like plumbing because they are plumbing: an appealing security label on a box does not reveal where the water stopped.

No dated operator deployment, peer OPEN capture and forwarded-update record accompanies these project instructions. Those records would show whether a particular network actually enforced the intended role and prevented a leak. For now the exposed choice is clear: Foremski made validation installable beside old hardware, while the operator must refuse to let the neighbor write its own job description.

Sources: RIPE 92 RACI identification · bgpipe project introduction · official ASPA stage guide · official ROV stage guide.