Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Maria Matejka via Bird-users]

On 2024-01-25 18:23, Alexander Zubkov wrote:

On Thu, Jan 25, 2024 at 6:11 PM Maria Matejka  wrote:

On 2024-01-25 17:08, Alexander Zubkov wrote:

But I think the problem with no filters is bigger when the RTR server is out. 
It is not just the short period of time when the peer can announce anything. If 
rpki autoreload is on it will cause all bad announces that was rejected before 
to pass the filter now. And if we turn rpki autoreload off, it might work like 
a classical filter, but than we cannot do additional actual origin validation 
using rpki.

On Thu, Jan 25, 2024, 14:41 Alexander Zubkov  wrote:

AFAIK in RPKI AS0 means implicit invalid.

On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users 
 wrote:

On 2024-01-25 11:55, Erin Shepherd wrote:

Spitballing slightly here, but could you avoid this problem by adding 
0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?

Obviously the disadvantage here is that if your IRR RTR server goes down you're 
basically unfiltered, but it at least avoids the availability problem

With this, you can just go like

 if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr, net, peerasn) != 
ROA_VALID then reject;

which should do the work, iirc.

I may have not written it completely. I would add the "::/0+ as 0", or "::/0+ as 
65535" if AS0 is too shady, to the IRR RTR feed itself, not as a static record.

This way, if the RTR feed fails, the first roa_check fails and the second one 
is not performed at all, therefore nothing is rejected. OTOH, if the RTR feed 
works, the first roa_check is always true and the second one matters.

Do I miss something?

I think the idea was that (::/0+ AS0) is addet to RTR. Then every
valid tuple (prefix, ASN) will return VALID, and others will fall at
least under ::/0+ and because of AS0 will return INVALID. When the
feed is off, the rpki check will return UNKNOWN.


Oh yes, that should work as well, good idea!

Maria



On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:


On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:

a quick stab at generating the slurm file:

why use SLURM though? SLURM doesn't have a 'maxLength' field like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json  - which might help with
aggregation.

More importantly, a risk I perceive with overloading RTR functionality
to load IRR data into routers is in the realm of fail-safes:

For RPKI-derived data, most ISPs do something along the lines of:

if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;

For IRR-derived data, you'd have to do:

if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;

The above means that suddenly your EBGP routers/route servers have a
very hard dependency on the IRR RTR session being up in order to accept
routes (fail closed), whereas how the RPKI-derived data is used is in a
'fail open' fashion.

The above friction goes back to RPKI ROAs being defined as "if ROAs
exist, all BGP routes that do not match any of the ROAs are invalid"
(following the RFC 6811 algorithm), but for IRR route/route6 objects
such a definition was never established, those predate the RFC 6811
algorithm.

Kind regards,

Job

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Alexander Zubkov via Bird-users]

On Thu, Jan 25, 2024 at 6:11 PM Maria Matejka  wrote:
>
> On 2024-01-25 17:08, Alexander Zubkov wrote:
>
> But I think the problem with no filters is bigger when the RTR server is out. 
> It is not just the short period of time when the peer can announce anything. 
> If rpki autoreload is on it will cause all bad announces that was rejected 
> before to pass the filter now. And if we turn rpki autoreload off, it might 
> work like a classical filter, but than we cannot do additional actual origin 
> validation using rpki.
>
> On Thu, Jan 25, 2024, 14:41 Alexander Zubkov  wrote:
>>
>> AFAIK in RPKI AS0 means implicit invalid.
>>
>> On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users 
>>  wrote:
>>>
>>> On 2024-01-25 11:55, Erin Shepherd wrote:
>>>
>>> Spitballing slightly here, but could you avoid this problem by adding 
>>> 0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?
>>>
>>> Obviously the disadvantage here is that if your IRR RTR server goes down 
>>> you're basically unfiltered, but it at least avoids the availability problem
>>>
>>> With this, you can just go like
>>>
>>> if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr, net, peerasn) 
>>> != ROA_VALID then reject;
>>>
>>> which should do the work, iirc.
>
> I may have not written it completely. I would add the "::/0+ as 0", or "::/0+ 
> as 65535" if AS0 is too shady, to the IRR RTR feed itself, not as a static 
> record.
>
> This way, if the RTR feed fails, the first roa_check fails and the second one 
> is not performed at all, therefore nothing is rejected. OTOH, if the RTR feed 
> works, the first roa_check is always true and the second one matters.
>
> Do I miss something?

I think the idea was that (::/0+ AS0) is addet to RTR. Then every
valid tuple (prefix, ASN) will return VALID, and others will fall at
least under ::/0+ and because of AS0 will return INVALID. When the
feed is off, the rpki check will return UNKNOWN.

>
> Maria
>
>
>
>
>>>
>>> - Erin
>>>
>>> On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:
>>>
>>> On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users 
>>> wrote:
>>> > a quick stab at generating the slurm file:
>>>
>>> why use SLURM though? SLURM doesn't have a 'maxLength' field like the
>>> regular JSON input formatted in this style has:
>>> https://console.rpki-client.org/rpki.json - which might help with
>>> aggregation.
>>>
>>> More importantly, a risk I perceive with overloading RTR functionality
>>> to load IRR data into routers is in the realm of fail-safes:
>>>
>>> For RPKI-derived data, most ISPs do something along the lines of:
>>>
>>>if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;
>>>
>>> For IRR-derived data, you'd have to do:
>>>
>>>if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;
>>>
>>> The above means that suddenly your EBGP routers/route servers have a
>>> very hard dependency on the IRR RTR session being up in order to accept
>>> routes (fail closed), whereas how the RPKI-derived data is used is in a
>>> 'fail open' fashion.
>>>
>>> The above friction goes back to RPKI ROAs being defined as "if ROAs
>>> exist, all BGP routes that do not match any of the ROAs are invalid"
>>> (following the RFC 6811 algorithm), but for IRR route/route6 objects
>>> such a definition was never established, those predate the RFC 6811
>>> algorithm.
>>>
>>> Kind regards,
>>>
>>> Job
>>>
>>> --
>>> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>
> --
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Maria Matejka via Bird-users]

On 2024-01-25 17:08, Alexander Zubkov wrote:
But I think the problem with no filters is bigger when the RTR server 
is out. It is not just the short period of time when the peer can 
announce anything. If rpki autoreload is on it will cause all bad 
announces that was rejected before to pass the filter now. And if we 
turn rpki autoreload off, it might work like a classical filter, but 
than we cannot do additional actual origin validation using rpki.


On Thu, Jan 25, 2024, 14:41 Alexander Zubkov  wrote:

AFAIK in RPKI AS0 means implicit invalid.

On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users
 wrote:

On 2024-01-25 11:55, Erin Shepherd wrote:

Spitballing slightly here, but could you avoid this problem
by adding 0.0.0.0/0+  ::0/0+ AS0 RoAs to
the table and accepting ROA Unknowns?

Obviously the disadvantage here is that if your IRR RTR
server goes down you're basically unfiltered, but it at least
avoids the availability problem


With this, you can just go like

    if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr,
net, peerasn) != ROA_VALID then reject;

which should do the work, iirc.

I may have not written it completely. I would add the "::/0+ as 0", or 
"::/0+ as 65535" if AS0 is too shady, to the IRR RTR feed itself, not as 
a static record.


This way, if the RTR feed fails, the first roa_check fails and the 
second one is not performed at all, therefore nothing is rejected. OTOH, 
if the RTR feed works, the first roa_check is always true and the second 
one matters.


Do I miss something?

Maria






- Erin

On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:

On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via
Bird-users wrote:
> a quick stab at generating the slurm file:

why use SLURM though? SLURM doesn't have a 'maxLength' field
like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json - which might help
with
aggregation.

More importantly, a risk I perceive with overloading RTR
functionality
to load IRR data into routers is in the realm of fail-safes:

For RPKI-derived data, most ISPs do something along the
lines of:

   if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID)
then reject;

For IRR-derived data, you'd have to do:

   if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;

The above means that suddenly your EBGP routers/route
servers have a
very hard dependency on the IRR RTR session being up in
order to accept
routes (fail closed), whereas how the RPKI-derived data is
used is in a
'fail open' fashion.

The above friction goes back to RPKI ROAs being defined as
"if ROAs
exist, all BGP routes that do not match any of the ROAs are
invalid"
(following the RFC 6811 algorithm), but for IRR route/route6
objects
such a definition was never established, those predate the
RFC 6811
algorithm.

Kind regards,

Job

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.



--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Alexander Zubkov via Bird-users]

But I think the problem with no filters is bigger when the RTR server is
out. It is not just the short period of time when the peer can announce
anything. If rpki autoreload is on it will cause all bad announces that was
rejected before to pass the filter now. And if we turn rpki autoreload off,
it might work like a classical filter, but than we cannot do additional
actual origin validation using rpki.

On Thu, Jan 25, 2024, 14:41 Alexander Zubkov  wrote:

> AFAIK in RPKI AS0 means implicit invalid.
>
> On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users <
> bird-users@network.cz> wrote:
>
>> On 2024-01-25 11:55, Erin Shepherd wrote:
>>
>> Spitballing slightly here, but could you avoid this problem by adding
>> 0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?
>>
>> Obviously the disadvantage here is that if your IRR RTR server goes down
>> you're basically unfiltered, but it at least avoids the availability problem
>>
>> With this, you can just go like
>>
>> if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr, net,
>> peerasn) != ROA_VALID then reject;
>>
>> which should do the work, iirc.
>>
>> Maria
>>
>>
>>
>>
>> - Erin
>>
>> On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:
>>
>> On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users
>> wrote:
>> > a quick stab at generating the slurm file:
>>
>> why use SLURM though? SLURM doesn't have a 'maxLength' field like the
>> regular JSON input formatted in this style has:
>> https://console.rpki-client.org/rpki.json - which might help with
>> aggregation.
>>
>> More importantly, a risk I perceive with overloading RTR functionality
>> to load IRR data into routers is in the realm of fail-safes:
>>
>> For RPKI-derived data, most ISPs do something along the lines of:
>>
>>if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;
>>
>> For IRR-derived data, you'd have to do:
>>
>>if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;
>>
>> The above means that suddenly your EBGP routers/route servers have a
>> very hard dependency on the IRR RTR session being up in order to accept
>> routes (fail closed), whereas how the RPKI-derived data is used is in a
>> 'fail open' fashion.
>>
>> The above friction goes back to RPKI ROAs being defined as "if ROAs
>> exist, all BGP routes that do not match any of the ROAs are invalid"
>> (following the RFC 6811 algorithm), but for IRR route/route6 objects
>> such a definition was never established, those predate the RFC 6811
>> algorithm.
>>
>> Kind regards,
>>
>> Job
>>
>> --
>> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>>
>>

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Alexander Zubkov via Bird-users]

AFAIK in RPKI AS0 means implicit invalid.

On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users <
bird-users@network.cz> wrote:

> On 2024-01-25 11:55, Erin Shepherd wrote:
>
> Spitballing slightly here, but could you avoid this problem by adding
> 0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?
>
> Obviously the disadvantage here is that if your IRR RTR server goes down
> you're basically unfiltered, but it at least avoids the availability problem
>
> With this, you can just go like
>
> if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr, net, peerasn)
> != ROA_VALID then reject;
>
> which should do the work, iirc.
>
> Maria
>
>
>
>
> - Erin
>
> On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:
>
> On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users
> wrote:
> > a quick stab at generating the slurm file:
>
> why use SLURM though? SLURM doesn't have a 'maxLength' field like the
> regular JSON input formatted in this style has:
> https://console.rpki-client.org/rpki.json - which might help with
> aggregation.
>
> More importantly, a risk I perceive with overloading RTR functionality
> to load IRR data into routers is in the realm of fail-safes:
>
> For RPKI-derived data, most ISPs do something along the lines of:
>
>if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;
>
> For IRR-derived data, you'd have to do:
>
>if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;
>
> The above means that suddenly your EBGP routers/route servers have a
> very hard dependency on the IRR RTR session being up in order to accept
> routes (fail closed), whereas how the RPKI-derived data is used is in a
> 'fail open' fashion.
>
> The above friction goes back to RPKI ROAs being defined as "if ROAs
> exist, all BGP routes that do not match any of the ROAs are invalid"
> (following the RFC 6811 algorithm), but for IRR route/route6 objects
> such a definition was never established, those predate the RFC 6811
> algorithm.
>
> Kind regards,
>
> Job
>
> --
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>
>

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Maria Matejka via Bird-users]

On 2024-01-25 11:55, Erin Shepherd wrote:
Spitballing slightly here, but could you avoid this problem by adding 
0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?


Obviously the disadvantage here is that if your IRR RTR server goes 
down you're basically unfiltered, but it at least avoids the 
availability problem


With this, you can just go like

    if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr, net, 
peerasn) != ROA_VALID then reject;


which should do the work, iirc.

Maria





- Erin

On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:
On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via 
Bird-users wrote:

> a quick stab at generating the slurm file:

why use SLURM though? SLURM doesn't have a 'maxLength' field like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json - which might help with
aggregation.

More importantly, a risk I perceive with overloading RTR functionality
to load IRR data into routers is in the realm of fail-safes:

For RPKI-derived data, most ISPs do something along the lines of:

   if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;

For IRR-derived data, you'd have to do:

   if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;

The above means that suddenly your EBGP routers/route servers have a
very hard dependency on the IRR RTR session being up in order to accept
routes (fail closed), whereas how the RPKI-derived data is used is in a
'fail open' fashion.

The above friction goes back to RPKI ROAs being defined as "if ROAs
exist, all BGP routes that do not match any of the ROAs are invalid"
(following the RFC 6811 algorithm), but for IRR route/route6 objects
such a definition was never established, those predate the RFC 6811
algorithm.

Kind regards,

Job


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Job Snijders via Bird-users]

On Thu, Jan 25, 2024 at 11:55:14AM +0100, Erin Shepherd wrote:
> Spitballing slightly here, but could you avoid this problem by adding
> 0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?
> 
> Obviously the disadvantage here is that if your IRR RTR server goes
> down you're basically unfiltered, but it at least avoids the
> availability problem

That's an interesting approach, thanks for sharing this.

Kind regards,

Job

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Job Snijders via Bird-users]

On Thu, Jan 25, 2024 at 11:41:25AM +0100, Job Snijders wrote:
> On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:
> > a quick stab at generating the slurm file:
> 
> why use SLURM though? SLURM doesn't have a 'maxLength' field like the
> regular JSON input formatted in this style has:
> https://console.rpki-client.org/rpki.json - which might help with
> aggregation.

Err... scratch that, SLURM does have a field for that, but it's called
"maxPrefixLength". Anyway, using the 'normal' JSON format as input for
the IRR RTR server should make for a more concise smaller JSON file
compared to using SLURM prefixAssertions, but both could be used.

Kind regards,

Job

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Erin Shepherd]

Spitballing slightly here, but could you avoid this problem by adding 
0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?

Obviously the disadvantage here is that if your IRR RTR server goes down you're 
basically unfiltered, but it at least avoids the availability problem

- Erin 

On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:
> On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:
> > a quick stab at generating the slurm file:
> 
> why use SLURM though? SLURM doesn't have a 'maxLength' field like the
> regular JSON input formatted in this style has:
> https://console.rpki-client.org/rpki.json - which might help with
> aggregation.
> 
> More importantly, a risk I perceive with overloading RTR functionality
> to load IRR data into routers is in the realm of fail-safes:
> 
> For RPKI-derived data, most ISPs do something along the lines of:
> 
>if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;
> 
> For IRR-derived data, you'd have to do:
> 
>if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;
> 
> The above means that suddenly your EBGP routers/route servers have a
> very hard dependency on the IRR RTR session being up in order to accept
> routes (fail closed), whereas how the RPKI-derived data is used is in a
> 'fail open' fashion.
> 
> The above friction goes back to RPKI ROAs being defined as "if ROAs
> exist, all BGP routes that do not match any of the ROAs are invalid"
> (following the RFC 6811 algorithm), but for IRR route/route6 objects
> such a definition was never established, those predate the RFC 6811
> algorithm.
> 
> Kind regards,
> 
> Job
> 

Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Job Snijders via Bird-users]

On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:
> a quick stab at generating the slurm file:

why use SLURM though? SLURM doesn't have a 'maxLength' field like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json - which might help with
aggregation.

More importantly, a risk I perceive with overloading RTR functionality
to load IRR data into routers is in the realm of fail-safes:

For RPKI-derived data, most ISPs do something along the lines of:

   if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;

For IRR-derived data, you'd have to do:

   if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;

The above means that suddenly your EBGP routers/route servers have a
very hard dependency on the IRR RTR session being up in order to accept
routes (fail closed), whereas how the RPKI-derived data is used is in a
'fail open' fashion.

The above friction goes back to RPKI ROAs being defined as "if ROAs
exist, all BGP routes that do not match any of the ROAs are invalid"
(following the RFC 6811 algorithm), but for IRR route/route6 objects
such a definition was never established, those predate the RFC 6811
algorithm.

Kind regards,

Job

Re: Defines for mixed IPv6/IPv4

[Jeroen Massar via Bird-users]

> On 25 Jan 2024, at 09:23, Maria Matejka  wrote:
> 
> 
> 
> On 25 January 2024 08:34:36 CET, Jeroen Massar  wrote:
>> 
>> 
>>> On 24 Jan 2024, at 11:08, Maria Matejka  wrote:
>>> 
>>> 
>>> 
>>> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users 
>>>  wrote:
 
 
> On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users 
>  wrote:
> 
> 
> Hello bird users,
> 
> I am wondering how you handle matching both IPv6 and IPv4 prefixes
> efficiently.
> 
> We have tons of blocks in our config like these:
 
 Generate the configs.
>>> 
>>> Not only that, please split IPv6 and IPv4 filters, at least if these are 
>>> prone to frequent changes.
>>> 
 Especially when doing IRR filtering, one simply lets bgpq4 generate the 
 filters
 and then drop those definitions into a bird include file, and generate the 
 peers parts too.
>>> 
>>> When doing IRR filtering, please export it as JSON and load it through RTR 
>>> mechanism. We support multiple ROA tables and this is exactly the use case 
>>> for it
>> 
>> Mmm... do you mean IRR data (what bgpq4 generates from RPSL) or RPKI data 
>> (what rpki-client generates from ROAs) ?
>> 
>> As yes, RPKI data we generate into a JSON file and then pass that to a RTR 
>> which serves it up to bird; but IRR data becomes filter statements ("bgpq4 
>> -b" ;) )
> 
> Of course I mean IRR data. You setup two caches, one for actual RPKI data, 
> and another one for IRR data, feed it by SLURM, load both by two "protocol 
> rpki" instances into two different "roa[64] table"s and call "roa_check()" 
> twice.

Took a bit to wrap my mind around, but yes, I gotcha!


The clue in the tutorial was that 'protocol rpki' should have been 'protocol 
rtr' ;)


Thus the idea is to produce a "IRR" SLURM file with:

```
{
  "slurmVersion": 1,
  "validationOutputFilters": {
"locallyAddedAssertions": {
  "prefixAssertions": [
{
  "asn": ,
  "prefix": "",
  "comment": "IRR-data"
},
```

and instead of RPKI where we check:

```
roa_check(rpki4, 192.0.2.0/24, originasn)  # (where ', originasn' is default 
and thus normally omitted)
```

we check:
```
roa_check(irr4, 192.0.2.0/24, peerasn)
```

which means every peer is more or less the same as the peerasn is a parameter 
to whatever peer check function one calls and that then just calls the above 
roa_check(...peerasn), thus a lot less config and thus more readable and 
maintainable. (even if generated, as it gets repetitive).



a quick stab at generating the slurm file:

```
#!/bin/bash

set -e

cat <

Re: Defines for mixed IPv6/IPv4

[Maria Matejka via Bird-users]

On 25 January 2024 08:34:36 CET, Jeroen Massar  wrote:
>
>
>> On 24 Jan 2024, at 11:08, Maria Matejka  wrote:
>> 
>> 
>> 
>> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users 
>>  wrote:
>>> 
>>> 
 On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users 
  wrote:
 
 
 Hello bird users,
 
 I am wondering how you handle matching both IPv6 and IPv4 prefixes
 efficiently.
 
 We have tons of blocks in our config like these:
>>> 
>>> Generate the configs.
>> 
>> Not only that, please split IPv6 and IPv4 filters, at least if these are 
>> prone to frequent changes.
>> 
>>> Especially when doing IRR filtering, one simply lets bgpq4 generate the 
>>> filters
>>> and then drop those definitions into a bird include file, and generate the 
>>> peers parts too.
>> 
>> When doing IRR filtering, please export it as JSON and load it through RTR 
>> mechanism. We support multiple ROA tables and this is exactly the use case 
>> for it
>
>Mmm... do you mean IRR data (what bgpq4 generates from RPSL) or RPKI data 
>(what rpki-client generates from ROAs) ?
>
>As yes, RPKI data we generate into a JSON file and then pass that to a RTR 
>which serves it up to bird; but IRR data becomes filter statements ("bgpq4 -b" 
>;) )

Of course I mean IRR data. You setup two caches, one for actual RPKI data, and 
another one for IRR data, feed it by SLURM, load both by two "protocol rpki" 
instances into two different "roa[64] table"s and call "roa_check()" twice.

This way, you don't have to reload BIRD config every so often, and what is 
more, as soon as BIRD 3 comes out, when something changes in IRR, only the 
possibly affected routes are actually going to be reloaded.

If you wanna know a bit more, there is a tutorial talk at the last RIPE where I 
speak (not only) about that. And it still was just the tip of the iceberg. If 
you wish to get more tips, tricks, optimization help and much more, contact me 
off-list for paid support options.

Have a nice day!
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.