Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)
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
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
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
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.
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.
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 <green@qrator.net> 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.
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 <green@qrator.net> 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+ <http://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.
On Thu, Jan 25, 2024 at 6:11 PM Maria Matejka <maria.matejka@nic.cz> 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 <green@qrator.net> 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.
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.
On 2024-01-25 18:23, Alexander Zubkov wrote:
On Thu, Jan 25, 2024 at 6:11 PM Maria Matejka<maria.matejka@nic.cz> 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<green@qrator.net> 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. 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.
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
participants (4)
-
Alexander Zubkov -
Erin Shepherd -
Job Snijders -
Maria Matejka