On Tue, Aug 25, 2026 at 04:09:30PM +0000, James Bensley wrote:
The funny thing here is;
* Any RTBH provider today is taking your route(6) objects, which are for say a /24, and building a prefix filter for up to /32 (or /128).
Route/route6 objects are unsigned information. I'd like the industry to move away from using plain-text information in mission-critical automation.
* Then applying logic similar to the following: "if RTBH community is attached, and prefix size is /32, and prefix matches prefix filter -> then allow".
The resource holder did not authorize this interpretation.
* This happens for all prefixes of all customers all the way down their AS-SET tree.
Indeed, and all those resource holders did not authorize such an interpretation.
* The customer (or customer's customer, etc) get's no say in this prefix length expansion (the up to /32 and up to /128).
Exactly.
* As we know, anyone can add anything they want to their AS-SET.
So for networks which don't use / don't want RTBH, somewhere upstream of them, a provider, without their approval, is allowing more specifics than what that networks announces and has defined in IRR. And they're relying on the non-existing security of AS-SETs.
(I should know, we do it!)
If you moved that into ROA maxLength you would actually improve on the status quo because only networks that want to use RTBH need to increase their maxLength (stopping providers from doing it without asking you, and proving you with a way to opt out).
It is recommended to avoid using the maxLength attribute in ROAs. See BCP 185. https://www.rfc-editor.org/info/rfc9319/ BCP 185 also contains a section on RTBH filtering: https://www.rfc-editor.org/info/rfc9319/#section-6 BCP 185 literally states that ROA-based RPKI-ROV [RFC6811] is a poor fit for the validation of RTBH routes. Thusly, we should investigate the design of a new RPKI-based object type fit for purpose of validation of RTBH routes. The idea of the DOA concept is that the resource holder can issue explicit authorization for more-specifics (and also disallow less-specifics) to exist in BGP RIBs for purposes of blackholing if-and-only-if certain conditions are met (conditions related to AS_PATH and BGP community attribute attached to the route). The DOA object allows resource holders to specify a narrow set of circumstances (much narrower than you'd be able to achieve by misusing ROAs) in which blackholing is deemed permissive by the resource holder. A general note -- We as operator community really are not stuck with ROAs for every imaginable purpose. (See https://en.wikipedia.org/wiki/Law_of_the_instrument) It _is_ possible to extend the RPKI and innovate on manageable time scales. Innovating based on RPKI technology has several benefits: cryptographic assurances and strong object security, a transportation channel to convey information reasonably fast into BGP routers (RTR protocol), efficiency due to binary encodings, quite rapid (but not real-time) global information distribution, etc. I understand ASN.1 syntax can appear offputting and the barriers to define & deploy new RPKI object types may seem insurmountable because of all the binary encodings & cryptography (rather naieve extensions in the simpler plain-text key/value like RPSL offers), but I'd like to assure everyone that on-the-wire encoding actually is the easy part. The harder part (and this is where input from the broader community is super welcome!) is defining the semantic data model: what information do operators believe to be useful to validate RTBH signals? Who needs to authorize what? Just tell me (even expressed as JSON, or RPSL) and I can quite easily flip it into an ASN.1 structure and wire it up to the RPKI authorization model. As an table-top example: should the DOA contain the BGP speaker's IP address so that RTBH requests can be validated by matching on the NEXT_HOP? Easy to add such a field! Personally I don't think putting NEXT_HOP addresses in RPKI objects will operationally spark joy, but I bring this up to show that there is flexibility in what a DOA could look like. We as community decide what a DOA should look like. The objective here is to provide digitally signed means to automatically validate an incoming EBGP route announcement (containing BGP community attribute, an AS_PATH attribute, etc) for purposes of blackholing; so which of that route's data fields should be matched against the hierarchical authorization structure that the RPKI provides? Kind regards, Job