IRRD & exceptions to RPKI-filtering
Dear all, At NANOG 90, Merit presented on their IRRd v4 deployment. At the microphone Geoff Huston raised a comment which I interpreted as: "Can an exception be made for my research prefixes?" There are two sides to this: INSERTING RPKI-invalid route/route6 objects =========================================== By default, IRRd v4 rejects submitted route/route6 objects if the system detects the objects to be RPKI-invalid. This helps guard against typos, mistakes, and some forms of adversarial actions. However, some researchers find this protection annoying, because the 'noise filtering' mechanism interfers with their ability to insert noise to measure noise. ;-) In order to allow users to insert RPKI-invalid route/route6 objects into the database, the IRRD operator needs to make use of a so-called SLURM file. SLURM is an IETF-standardized JSON format to describe 'rules' to be applied to RPKI-derived information passing through a pipeline. RADB would need to adjust their configuration to point to a SLURM, and add the prefixes of researchers to the 'prefixFilter' section. https://irrd.readthedocs.io/en/stable/admins/rpki/#slurm-support Of course, RADB (or any IRRd v4 operator) will need to vet whether the researchers actually have some authority to make requests on behalf of the Resource Holder! I wouldn't like it if some random person could ask for ROAs related to my employer to be ignored! :-) It is up to each IRRD operator as to what their policy is on assisting researchers and making exceptions to the RPKI-filtering mechanism. QUERYING for RPKI-invalid route/route6 objects ============================================== By default, IRRd v4 returns RPKI-filter responses for WHOIS queries related to routes. This is done to help safe guard the ecosystem. Users can disable filtering of objects by issuing '!fno-rpki-filter' in the WHOIS connection. This is intended as a debugging aid. See this page for more information on the various WHOIS queries that IRRD v4 supports: https://irrd.readthedocs.io/en/stable/users/queries/whois/ Kind regards, Job
On 12 Feb 2024, at 3:14 pm, Job Snijders via NANOG <nanog@nanog.org> wrote:
Dear all,
At NANOG 90, Merit presented on their IRRd v4 deployment. At the microphone Geoff Huston raised a comment which I interpreted as:
"Can an exception be made for my research prefixes?"
no - I was making an observation that the presentation material was referring to "RPKI-Invalid" while their implementation was using "ROA-Invalid" There is a difference between these two terms, as I'm sure you're aware. cheers, Geoff
On Mon, Feb 12, 2024 at 04:07:52PM -0500, Geoff Huston wrote:
On 12 Feb 2024, at 3:14 pm, Job Snijders via NANOG <nanog@nanog.org> wrote: At NANOG 90, Merit presented on their IRRd v4 deployment. At the microphone Geoff Huston raised a comment which I interpreted as:
[snip]
no - I was making an observation that the presentation material was referring to "RPKI-Invalid" while their implementation was using "ROA-Invalid" There is a difference between these two terms, as I'm sure you're aware.
Thanks for the clarification! I guess I somehow got very confused watching the webstream as to what your comment or ask was. In any regard, - researchers, please just talk to IRRD operators if your experiment requires the existence of RPKI/ROA-invalid route/route6 objects! There are ways to make it happen, but the default of course is to keep things as tidy as possible :-) Greetings from the Netherlands & sorry to miss N90, Job
On 2024-02-12 15:18, Job Snijders via NANOG wrote:
On Mon, Feb 12, 2024 at 04:07:52PM -0500, Geoff Huston wrote:
I was making an observation that the presentation material was referring to "RPKI-Invalid" while their implementation was using "ROA-Invalid" There is a difference between these two terms, as I'm sure you're aware.
I'm sure Job is aware, but I'm not. Anyone want to teach me the difference? -- Richard
On Mon, Feb 12, 2024 at 05:01:35PM -0600, Richard Laager wrote:
On 2024-02-12 15:18, Job Snijders via NANOG wrote:
On Mon, Feb 12, 2024 at 04:07:52PM -0500, Geoff Huston wrote:
I was making an observation that the presentation material was referring to "RPKI-Invalid" while their implementation was using "ROA-Invalid" There is a difference between these two terms, as I'm sure you're aware.
I'm sure Job is aware, but I'm not. Anyone want to teach me the difference?
I'll try, but please bear with me as terminology throughout the years has shifted and perhaps wasn't entirely consistent from the start, and maybe I missed some bits. :-) The word "invalid" in context of RPKI and BGP has a lot of additional context: RFC 6811 ("BGP Prefix Origin Validation") introduced the concept of a given BGP route being "NotFound", "Valid", or "Invalid". In later years many people referred to "Prefix Origin Validation" as "Route Origin Validation" or "RPKI-based Origin Validation" (both variants abbreviated to "ROV"). Other variants also exist. Before one can conduct the RFC 6811 "Prefix Origin Validation" (née "Route Origin Validation") process, the operator (in an automated fashion, using a RPKI validator) will ascertain the validity of the ROAs (Route Origin Authorizations) by checking the cryptographic signatures, validity time windows, and other properties (See RFC 6488 and https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rfc6482bis) In order for the RFC 6811 validation process to arrive at a "Valid" or "Invalid" outcome, first of all a *valid* ROA needs to exist (as in cryptographically valid). So, to designate a BGP route as 'invalid', one needs at least one 'valid' ROA covering the IP address prefix at hand. The concept of validating BGP routes (or, as some call it 'verifying BGP routes'), using RPKI derived information, has been transposed to IRR data as well. For example, in 2018 RIPE NCC started using RPKI data to untangle and cleanup the "RIPE-NONAUTH" IRR database, as per policy https://www.ripe.net/publications/docs/ripe-731/ And the NTT Global IP Network (GIN/AS2914) used the same methodology on its IRRd server 'rr.ntt.net' (the default host used in bgpq4). Now RADB uses the same methodology (and software) as NTT does. A ROA can be invalid (for example, because its X.509 EE certificate expired); a BGP route can be invalid (because no valid RPKI ROA attest that the route could originate from the ASN at hand), and an IRR object can be invalid (because no Valid ROA attest the route object's "origin:" could originate the prefix at hand). Kind regards, Job
On 2024-02-12 18:12, Job Snijders wrote:
On Mon, Feb 12, 2024 at 05:01:35PM -0600, Richard Laager wrote:
On 2024-02-12 15:18, Job Snijders via NANOG wrote:
On Mon, Feb 12, 2024 at 04:07:52PM -0500, Geoff Huston wrote:
I was making an observation that the presentation material was referring to "RPKI-Invalid" while their implementation was using "ROA-Invalid" There is a difference between these two terms, as I'm sure you're aware.
I'm sure Job is aware, but I'm not. Anyone want to teach me the difference?
... more good explanation snipped ...
A ROA can be invalid (for example, because its X.509 EE certificate expired); a BGP route can be invalid (because no valid RPKI ROA attest that the route could originate from the ASN at hand), and an IRR object can be invalid (because no Valid ROA attest the route object's "origin:" could originate the prefix at hand).
Thanks! This makes perfect sense now that you say it. I just wasn't seeing it immediately before. I figured best to ask and learn something. :) -- Richard
On 12 Feb 2024, at 6:01 pm, Richard Laager <rlaager@wiktel.com> wrote:
On 2024-02-12 15:18, Job Snijders via NANOG wrote:
On Mon, Feb 12, 2024 at 04:07:52PM -0500, Geoff Huston wrote:
I was making an observation that the presentation material was referring to "RPKI-Invalid" while their implementation was using "ROA-Invalid" There is a difference between these two terms, as I'm sure you're aware.
I'm sure Job is aware, but I'm not. Anyone want to teach me the difference?
this is _my_ take: If the crypto leads to a validation failure (expired certificates, signature mismatch in the validation chain, number resource extension mismatch in the validation path, or similar then the X.509 certificate cannot be validated against a trust anchor and the object (a ROA in this case) is "RPKI-Invalid". RPKI validators discard such objects from consideration as they cannot convey any useful information. "ROA-Invalid" starts with a route object, not a ROA, and compares the route against the locally assembled collection of RPKI-valid ROAs. If it can find a RPKI-valid ROA that matches the route object then its "ROA-valid". If if can only find valid RPKI objects that match the prefix part of e ROA, but not the origin AS, or its a more specific prefix of a RPKI-valid ROA, then its "ROA-invalid". If no such match is found, then the route is "ROA-unknown" The distinction being made is: "RPKI-invalid" refers to a crypto object and the ability of a local party (a "relying party") to confirm its crypto-validity against a locally selected trust anchor (or set of trust anchors). "ROA-invalid" refers to a route object and a collection of RPKI-valid ROAs that have been assembled by an observer and refers to the outcome of the observer testing this route against this locally assembled collection of ROAs. Geoff
participants (3)
-
Geoff Huston -
Job Snijders -
Richard Laager