Summary

  • An individual draft posted on 20 August proposes a Discard Origin Authorization, or DOA, that binds an address holder's signature to an origin AS, prefixes, length ranges, peer ASes and blackhole communities.
  • DOA status would remain separate from Route Origin Validation and would trigger no default routing action; the proposal is not an IETF decision, and its security, operational and RPKI-RTR work is incomplete.

Emergency traffic discard exposes a fault line in routing security. A network under attack may ask an upstream to accept a more-specific BGP route tagged for blackholing, so unwanted traffic is dropped before it fills the access link. Yet that more-specific route can be longer than the maxLength in the address holder's Route Origin Authorization. A validating network may therefore see an intentional blackhole route as RPKI-invalid.

The 20 August publication of draft-spaghetti-grow-rpki-doa-00 proposes a separate credential for that narrow purpose. A Discard Origin Authorization would be an RPKI signed object issued under the address resources it covers. It would state which origin AS may send the discard route, which prefix and prefix lengths are permitted, which BGP Communities identify the request and, optionally, which peer ASes may relay it.

That is a proposal, not a standards event. The IETF Datatracker labels the document an individual Internet-Draft and explicitly says it has no formal standing and is not endorsed by the IETF. The authors retargeted a 2022 SIDROPS-labelled draft to the GROW working group, but publication under the new name does not establish working-group adoption.

The operational problem is nevertheless concrete. An operator that rejects ROV-invalid routes has two awkward choices today. It can exempt blackhole routes from that decision, creating a policy exception around precisely the more-specific announcements most capable of diverting traffic. Or the resource holder can widen a ROA's allowed maximum length so the blackhole route becomes valid. That enlarges the ordinary origin authorization as well, contrary to RFC 9319's guidance against unnecessarily broad maxLength values.

DOA would create an independent answer. A BGP speaker could label a received path Matched, Unmatched or NotFound. A match would require the listed origin AS, a permitted prefix length, receipt from either that origin or an authorised peer AS, and at least one of the communities named in the object. The revised text resolves an open question in the 2022 draft by treating the community list as logical OR. It also allows signing software to insert RFC 7999's well-known BLACKHOLE community when the issuer supplies none.

The separation from ROV is deliberate. A legitimate discard route might be DOA Matched and ROV Invalid at the same time. The draft suggests evaluating the discard authorization early, while letting unmatched or missing cases continue through normal routing policy, including origin validation. It also says conforming implementations must not install, reject or discard a route by default solely because of either validation state. The operator still owns the consequential decision.

Propagation is constrained too. RFC 7999 generally says a blackhole route should not travel beyond the AS that receives it. The proposal preserves that boundary, with a narrow exception: a network may pass the request to a neighbour when its own AS is explicitly named in the DOA's optional peer list. That makes delegation inspectable, but only one hop is described and the route still has to satisfy the other match conditions.

The most important facts are the missing ones. RPKI-RTR delivery of DOA payloads is deferred to a separate document. The draft's Operational Considerations and Security Considerations sections remain unwritten. IANA identifiers remain unassigned. One Python signer is listed, but the text says implementation claims were supplied by contributors, were not independently verified and do not imply endorsement. There is no evidence here of a router, validator and repository completing an interoperable chain.

For network operators, the draft's value is therefore diagnostic before it is deployable. It identifies a genuine control mismatch: ROAs answer ordinary origin authority, while emergency discard needs a more-specific, purpose-limited authorization. DOA offers a way to separate those questions without turning a community tag into proof by itself. Whether that architecture improves safety will depend on revocation, stale-object handling, transport, audit logs and local policy—precisely the parts that now require further work.

Sources