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
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
I'm sure Job is aware, but I'm not. Anyone want to teach me the difference?
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.
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
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