Extent of specifying validation
igorlord opened this issue · comments
@ksriram25 comment: The general guidance regarding RPKI repository outage, MFT/CRL expiry,
staleness, etc. is that we should simply refer to the document where
guidance is already provided (e.g., rfc 9286) about such things. We should not paraphrase as that
can potentially distort things. If somethings need to be done differently in the ASPA context
in comparison to what has been stated in another RFC related to, say, ROA (as an example),
then we need to state that and state our reasons clearly.
Also, I think we need not state that we'll use MFTs, etc. even if they are stale.
The expiry time is 2 to 3 days out and the RPKI repository outage will rarely last more
than a few to several hours.
I agree that most of the cases we are covering here are very unlikely -- outages that last past expiration times of objects, local cache corruption, needed objects mysteriously disappearing from repositories. However, these are exactly the questions that SIDROPs was most concerned with. Implementations that neglect careful and thoughtful treatment of these black swan events cause significant disruptions when these events inevitably happen.
So I agree that we need not paraphrase details of RFC 9286 (although summarizing its overall behavior/purpose is a good style so the reader knows what they can find in RFC 9286). But we should highlight details that are not obvious from RFC 9286 and maybe extend beyond what RFC 9286 deals with (using expired objects when cache refreshes keep failing, and ignoring the objects is likely to result in an incident), when this is important to make applications robust against highly unlikely events.
I think we can publish a v-01 at this point with the refined new sections. If improvements, especially in the implementation section, are needed, the WG will likely help us out (some people wanting to contribute and join as co-author). If you can commit and add all the edits so far in the main, I'll take another look.
One follow-up comment about RPKI unreachability, etc. is as follows: at some point of time (e.g., perhaps when objects (say, MFTs) have expired and there is no refresh/restoration of RPKI, then we do the fail open thing, i.e., let go the BARSAV filter, say, by downgrading it to a simple 'loose uRPF' scheme which permits all prefixes that are in RIBs. In this, the bogons, unallocated, etc. prefixes are not included (i.e., filtered).
Updated fail open mode to use uRPF in #1
The update looks fine.