Failure and Recovery Scenarios¶
Publication Point Expired¶
Issue |
---|
The manifest or CRL of your CA expired |
Consequences |
---|
Your published objects are no longer valid |
Your routes become “not found” in most cases |
When your manifest or CRL become expired your RPKI objects will become invalid. This problem can occur if your CA is down, or if your CA cannot publish updated objects at its publication server, for a prolonged period of time.
Krill uses a default validity time of 24 hours for manifests and CRLs, and replaces them 8 hours before they would expire. This means that from the moment of the outage you have 8-24 hours to prevent that your objects will be invalidated.
It is possible to change these defaults if you want to have more time to deal with potential issues. However, we recommend that you avoid using long validity times because in theory they could make you vulnerable to replay attacks where a malicious actor feeds old objects to RPKI validators. This attack is not trivial, but it’s not impossible either.
A reasonable compromise could be to use a validity time of 36 hours, and have Krill reissue manifests and CRLs 24 hours before they would expire. You can achieve this by adding the following directives to your configuration file:
timing_publish_next_hours = 36
timing_publish_hours_before_next = 24
When your objects, most importantly ROAs, become invalid your routes will usually become “not found”, rather than “invalid”. Meaning that your routes will no longer benefit from Route Origin Validation, but they will still be accepted.
For a route to become RPKI “invalid” it would need to be covered by one or more valid ROA objects which include this prefix, none of which allow the possibly more specific prefix and ASN.
In the set up we see today this is unlikely to happen as most Krill CAs will operate directly under a parent RIR or NIR, and will not delegate prefixes to children. RIRs and NIRs do not issue ROAs for delegated prefixes, so in case your publication point would be rejected there would be no remaining valid ROA objects for your announcement. The result is that they then get an RPKI validity state “not found”.
However, in complicated setups your routes can become invalid. For example if your organisation operates a main CA under an RIR, and it publishes ROAs, while delegating some resources covered by those ROAs to you (e.g. a business unit or customer), and your publication point is expired while your parent’s publication point is still current.. then your routes can become “invalid”.
If it can be helped it would therefore be advisable that your parent does not delegate resources for which they also manage ROAs.
Parent Publication Point Expired¶
Issue |
---|
The manifest or CRL of your parent CA expired |
Consequences |
---|
Your published objects are no longer valid |
Your routes become “not found” in most cases |
If your parent CA’s publication point is expired, then its objects will become invalid. This includes the certificate for the delegation done to you, and therefore your objects will also no longer be considered valid by RPKI validators.
As described above this will typically mean that your routes end up with the RPKI validity state “not found”. The chances of them becoming “invalid” are actually somewhat lower still becuase any possible ROAs issued by your parent or siblings (other children under the same parent) covering your resources would also be invalid.