As routing-security lead for a regional transit AS, how would you weigh ROAs, BGPsec, ASPA, BGP Roles and MANRS by what each proves and costs?

## Five tools, four different claims Routing security is not one problem. A hijack lies about **who may originate** a prefix or **which path** leads to it; a leak sends a genuine route across the **wrong relationship**; and much of the damage depends on **operator practice**: whether anyone filters, answers the phone, or publishes what they intend to announce. Each tool answers one of those questions. | Tool | Proves | Status | Who must deploy before it helps | Misses | |---|---|---|---|---| | ROA + origin validation | origin AS is authorized for this prefix and length | RFCs 9582, 6811; RFC 9319 is BCP 185 | the holder signs; each validating network protects itself | forged origins, leaks | | BGP Roles + OTC | the route has not crossed a forbidden relationship | RFC 9234 | each compliant network protects itself and detects leaks multiple hops away | a deliberate leaker who strips OTC | | ASPA | the path climbs and descends only through registered customer-to-provider hops | IETF drafts at the time of writing | registering ASes and verifying ASes; benefits start with two | a provider forging paths for its own customers' prefixes | | BGPsec | every AS on the path authorized sending the update to the next | RFC 8205 | every AS on the path, with router keys | leaks; any hop without BGPsec ends the chain | | MANRS | nothing cryptographic: a public commitment to practices | operator programme | each member | everyone outside it | ## Origin: cheap, widespread, partial ROAs are the first step because the cost is small and the benefit is immediate. A minimal ROA (RFC 9319: authorize only what you announce, avoid `maxLength`) makes accidental mis-origination and sub-prefix hijacks of your space Invalid wherever Invalid is dropped. Dropping Invalid on your own sessions protects your customers in turn. The costs are operational: the RPKI becomes a dependency, and RFC 6811 warns that a wrong or missing record can make a good route Invalid, so ROA changes need the same care as routing changes. ## Path: BGPsec and why it barely deployed BGPsec replaces `AS_PATH` with a signed `BGPsec_PATH`. RFC 8205 gives a strong guarantee, but its price explains the near-absence of deployment: - A router that receives an unsigned update MUST NOT attach a `BGPsec_PATH` when propagating it, so one non-participating AS ends the signed chain. - Each update carries one prefix, and signatures cover the target AS, so a separate update per prefix and per neighbouring AS replaces normal update packing. - Every border router that sends BGPsec needs a key tied to an RPKI router certificate, and every update must be signed at each hop and verified on receipt. - It still does not detect leaks; the ASPA draft calls the two complementary. ## Relationships: Roles and ASPA BGP Roles with the `OTC` attribute are the best value for accidents: a per-session Role, confirmed with the neighbour at OPEN, makes your own routers refuse to leak and flags routes leaked to you by a customer or peer. ASPA reaches further: each AS registers its set of providers in the RPKI, and a verifying AS checks whether the path could have climbed only through registered providers. The draft notes that if two ISPs both register and verify, leaks between them through their customer cones are detected, and that it catches forged-origin hijacks, received from a customer or peer, whose fake neighbour of the origin is not one of the origin's registered providers. As a transit AS you should register early, including standby providers such as a DDoS-mitigation service, because the draft warns that a provider missing from an ASPA can make routes falsely Invalid later. Conversely, monitor that your customers list you in theirs. ## Practice: MANRS MANRS (Mutually Agreed Norms for Routing Security) is a programme, not an IETF document. Network operators commit to filtering what customers may announce, preventing spoofed source addresses, keeping contact data current for coordination, and publishing routing intentions in the RPKI or a routing registry. Its value is peer pressure and a checklist that auditors and customers can see. ## A sequencing you can defend 1. Filter customer announcements and publish minimal ROAs for your own space. 2. Drop RPKI-Invalid routes on every eBGP session; monitor what is dropped. 3. Configure BGP Roles on every eBGP session, starting without strict mode so an unsupported neighbour does not take a session down. 4. Register an ASPA covering every provider, then enable verification as implementations mature. 5. Join MANRS to make the commitments public. 6. Revisit BGPsec only if neighbours and the wider ecosystem deploy it. ## The trade-offs a lead owns - **Protection versus self-inflicted outage**: every validation step that drops routes can drop legitimate ones when data is wrong. - **Local versus collective benefit**: Roles, origin validation and ASPA pay off for early adopters; BGPsec pays off only collectively. - **Standards risk**: ASPA's details can still change while it is a draft.