Expiration for ROA tables until when the VRP is valid?

[Job Snijders]

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

For completeness sake, the compagnion changeset for OpenBGPD is at
https://github.com/openbsd/src/commit/fc51cb501dd3aa311d9b11d159f41d7b1e5cf33e

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