Expiration for ROA tables until when the VRP is valid?
Hello all, rpki-client recently implemented the "expires" instruction for roa-sets that OpenBGPD provides [1][2]. As of writing, BIRD does not seem to have something similar...any chance for it? From my understanding this only applies to included ROA files with VRP, not to RTR. [1] https://man.openbsd.org/bgpd.conf#roa-set [2] https://github.com/rpki-client/rpki-client-openbsd/commit/7bf63da6ec80f37bd7... Kind regards Robert Scheck
Hi all, On Sun, Sep 19, 2021 at 01:07:36AM +0200, Robert Scheck wrote:
rpki-client recently implemented the "expires" instruction for roa-sets that OpenBGPD provides [1][2]. As of writing, BIRD does not seem to have something similar...any chance for it? From my understanding this only applies to included ROA files with VRP, not to RTR.
[1] https://man.openbsd.org/bgpd.conf#roa-set [2] https://github.com/rpki-client/rpki-client-openbsd/commit/7bf63da6ec80f37bd7...
For completeness sake, the compagnion changeset for OpenBGPD is at https://github.com/openbsd/src/commit/fc51cb501dd3aa311d9b11d159f41d7b1e5cf3... background: One of the worst things for current BGP routing is to end up making routing decisions based on last year's RPKI state. For the RTR protocol Expiry timers already exist, but when using a 'staticly generated ROA config' (for example via 'rtrsub') no equivalent exists (yet). On the 'cryptographic side of the house' (in the RPKI validator) a number of expiration moments exist for each and every RPKI ROA. For example there is the ROA's own EE Certificate expiration date, the parent CA's expiration moment, the parent CA's CRL nextUpdate, the parent's parent's CA expiration, etc, etc. The OpenBSD RPKI validator (which can generate BIRD config snippets!) calculates the "transitive expiration moment". This is the 'nearest' moment a given ROA no longer should be considered when validating BGP routes. Every RPKI CA periodically refreshes/resigns data related to their ROAs, so every time the validation process runs, it'll output updated expiration moments: under normal circumstances ROAs don't drop out of the rotation because of expiration. I see two edge cases where it is useful for the BGP daemon itself to be aware of the expiration moment for each ROA: * BGP speakers that have been powered off for some time, and have RPKI-based configs on disk. The moment such a server powers back on, and reads config from disk, it is helpful if it ignores all ROA entries which had an expiry moment in the past * There is a pipeline issue: for one reason or another the file with the RPKI ROAs don't get updated (for example the stackstorm scheduler offline). In such a scenario it is better for the BGP speaker to not use stale RPKI data for route selection. The RPKI failure model is to 'fail open', not 'go stale'. Having a (moving) expiration moment specified for each ROA helps honor signed attestations about when to expire ROAs in end-to-end pipelines. I'm available to work on this with BIRD developers: I can provide real-world configs with accurate expiration moments, review, and test! Kind regards, Job
On Sun, Sep 19, 2021 at 12:38:28PM +0200, Job Snijders wrote:
The OpenBSD RPKI validator (which can generate BIRD config snippets!) calculates the "transitive expiration moment". This is the 'nearest' moment a given ROA no longer should be considered when validating BGP routes. Every RPKI CA periodically refreshes/resigns data related to their ROAs, so every time the validation process runs, it'll output updated expiration moments: under normal circumstances ROAs don't drop out of the rotation because of expiration.
To better illustrate the feature request, I'm now generating a new BIRD2 config snippet once an hour at this URL: http://kiera.meerval.net/bird.roa.conf.txt I've modified this rpki-client's instance to also emit the expires %lld. Each RPKI entry now contains an 'expires' timestamp as seconds since epoch, which signifies the "do not use after" date. Nobody wants to drink expired milk! :-) Imagine a workflow where someone put in crontab: wget -O /etc/bird/rpki.conf http://kiera.meerval.net/bird.roa.conf.txt birdc configure and in their /etc/bird/bird.conf a line like include "rpki.conf"; Now, if the kiera.meerval.net service would disappear for one reason or another, the BGP daemon won't receive new RPKI ROA information. In that scenario, having BIRD check every few minutes whether any ROAs it previously loaded by now have expired, can be very helpful! Kind regards, Job
On Sun, 19 Sep 2021, Robert Scheck wrote:
rpki-client recently implemented the "expires" instruction for roa-sets that OpenBGPD provides [1][2]. As of writing, BIRD does not seem to have something similar...any chance for it? From my understanding this only applies to included ROA files with VRP, not to RTR.
[1] https://man.openbsd.org/bgpd.conf#roa-set [2] https://github.com/rpki-client/rpki-client-openbsd/commit/7bf63da6ec80f37bd7...
Please let me kindly repeat my initial question from about 1.5 years ago: Is there any chance for getting this feature into BIRD, too? Job provided some more details and insights as part of the original thread: - https://bird.network.cz/pipermail/bird-users/2021-September/015725.html - https://bird.network.cz/pipermail/bird-users/2021-September/015726.html Thank you. Kind regards Robert Scheck
On Tue, Mar 07, 2023 at 01:01:36AM +0100, Robert Scheck wrote:
On Sun, 19 Sep 2021, Robert Scheck wrote:
rpki-client recently implemented the "expires" instruction for roa-sets that OpenBGPD provides [1][2]. As of writing, BIRD does not seem to have something similar...any chance for it? From my understanding this only applies to included ROA files with VRP, not to RTR.
[1] https://man.openbsd.org/bgpd.conf#roa-set [2] https://github.com/rpki-client/rpki-client-openbsd/commit/7bf63da6ec80f37bd7...
Please let me kindly repeat my initial question from about 1.5 years ago: Is there any chance for getting this feature into BIRD, too? Job provided some more details and insights as part of the original thread:
- https://bird.network.cz/pipermail/bird-users/2021-September/015725.html - https://bird.network.cz/pipermail/bird-users/2021-September/015726.html
Related, RPKI-To-Router implementation StayRTR recently received support for honoring configured expiration timers for individual RPKI VRPs. [1] When the expiration moment (noted as a unix timestamp) of a given RPKI ROA/VRP has arrived, the StayRTR daemon will emit RTR Withdraws towards its clients for that ROA/VRP. Indeed, OpenBGPD (when loading VRPs from on-disk configuration) also supports similar functionality, which has proven to make various deployment scenarios less prone to faults in configuration pipelines. I'd love it if BIRD also allows operators to specify the expiration moment of a given ROA/VRP in the on-disk configuration through a keyword + timestamp. Kind regards, Job [1]: https://github.com/bgp/stayrtr/commit/13659dd27e1b792dd2a7b9f439ef0a4159d862...
On Tue, Mar 07, 2023 at 01:01:36AM +0100, Robert Scheck wrote:
On Sun, 19 Sep 2021, Robert Scheck wrote:
rpki-client recently implemented the "expires" instruction for roa-sets that OpenBGPD provides [1][2]. As of writing, BIRD does not seem to have something similar...any chance for it? From my understanding this only applies to included ROA files with VRP, not to RTR.
[1] https://man.openbsd.org/bgpd.conf#roa-set [2] https://github.com/rpki-client/rpki-client-openbsd/commit/7bf63da6ec80f37bd7...
Please let me kindly repeat my initial question from about 1.5 years ago: Is there any chance for getting this feature into BIRD, too? Job provided some more details and insights as part of the original thread:
- https://bird.network.cz/pipermail/bird-users/2021-September/015725.html - https://bird.network.cz/pipermail/bird-users/2021-September/015726.html
Hi I completely missed/forgot about this. If i understand it correctly, it is relevant just for static ROA records? I assume these expiration records are based on wall-clock time instead of relative time? It is a question whether we should handle expiration of such static routes properly / dynamically, or just a one-time check during reconfiguration. That would be order of magnitude simpler, but it is also a thing that could be done by a trivial script preprocessing the included config file with static ROA records. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Tue, Mar 07, 2023 at 12:52:16PM +0100, Ondrej Zajicek wrote:
If i understand it correctly, it is relevant just for static ROA records?
Correct
I assume these expiration records are based on wall-clock time instead of relative time?
Correct, wall-clock time expressed as number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970 (Unix time).
It is a question whether we should handle expiration of such static routes properly / dynamically, or just a one-time check during reconfiguration. That would be order of magnitude simpler, but it is also a thing that could be done by a trivial script preprocessing the included config file with static ROA records.
For what its worth: OpenBGPD and StayRTR handle it 'dynamically', but not in absolute real time: both implementations walk a table every few (~3) minutes to check for newly expired entries. Kind regards, Job
On Tue, Mar 07, 2023 at 01:00:40PM +0100, Job Snijders wrote:
On Tue, Mar 07, 2023 at 12:52:16PM +0100, Ondrej Zajicek wrote:
If i understand it correctly, it is relevant just for static ROA records?
Correct
I assume these expiration records are based on wall-clock time instead of relative time?
Correct, wall-clock time expressed as number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970 (Unix time).
It is a question whether we should handle expiration of such static routes properly / dynamically, or just a one-time check during reconfiguration. That would be order of magnitude simpler, but it is also a thing that could be done by a trivial script preprocessing the included config file with static ROA records.
For what its worth: OpenBGPD and StayRTR handle it 'dynamically', but not in absolute real time: both implementations walk a table every few (~3) minutes to check for newly expired entries.
To follow up with a mock configuration example, please see below. The %lld after keyword 'expires' is calculated by OpenBSD's rpki-client by walking the chain of authorities and keeping tabs on the 'soonest' expiration moment. In other words, the 'expires' value is the moment a RTR server would send an IPv4/IPv6 Prefix RTR PDU with the 'withdraw' flag set. (rpki-client supports generating static ROA configurations in BIRD's format, if BIRD supports 'expires' I'll update rpki-client/output-bird.c) For a constantly up-to-date set of data, please download https://console.rpki-client.org/vrps.json (as often as you want), and transform it into BIRD's configuration format. The 'expires' key in the JSON objects is what one would use to instruct the BGP daemon or RTR server when to expire. I am happy to help with this project. Kind regards, Job -------- roa4 table ROAS4; roa6 table ROAS6; protocol static { roa4 { table ROAS4; }; route 1.0.0.0/24 max 24 as 13335 expires 1678717104; # Mon Mar 13 14:18:24 UTC 2023 route 1.0.4.0/24 max 24 as 38803 expires 1678751858; # Mon Mar 13 23:57:38 UTC 2023 route 1.7.142.0/24 max 24 as 132215 expires 1678789300; # Tue Mar 14 10:21:40 UTC 2023 # ... # left the thousands of other static entries out for brevity } protocol static { roa6 { table ROAS6; }; route 2001:200::/32 max 32 as 2500 expires 1678724530; route 2001:200:136::/48 max 48 as 9367 expires 1678724530; route 2001:200:1ba::/48 max 48 as 24047 expires 1678724530; # ... # left the thousands of other static entries out for brevity }
participants (3)
-
Job Snijders -
Ondrej Zajicek -
Robert Scheck