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
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