Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage)
cjeker at diehard.n-r-g.com
Mon Oct 1 08:30:31 UTC 2018
On Mon, Oct 01, 2018 at 09:47:43AM +0200, Alex Band wrote:
> To avoid any misunderstanding in this discussion going forward, I would
> like to reiterate that an RPKI ROA is a positive attestation. An
> unavailable, expired or invalid ROA will result in a BGP announcement
> with the status NotFound. The announcement will *not* become INVALID,
> thereby being dropped.
> Please read Section 5 of RFC 7115 that John linked carefully:
> Bush Best Current Practice [Page 7]
> RFC 7115 RPKI-Based Origin Validation Op January 2014
> Announcements with NotFound origins should be preferred over those
> with Invalid origins.
> Announcements with Invalid origins SHOULD NOT be used, but may be
> used to meet special operational needs. In such circumstances, the
> announcement should have a lower preference than that given to Valid
> or NotFound.
> Thus, a continued outage of an RPKI CA (or publication server) will
> result in announcements with status NotFound. This means that the
> prefixes held by this CA will no longer benefit from protection by the
> RPKI. However, since only *invalid* announcements should be dropped,
> this should not lead to large scale outages in routing.
> It is important to be aware of the impact of such an outage when
> considering questions of liability.
This depends if the prefix in question is covered by another ROA. Because
in that case it is well possible that the prefix is marked INVALID.
This is especially an issue if a partial failure of a publication server
is taking out the more specifics but leaves a large covering ROA (maybe
even one with origin AS 0).
In the end from a security standpoint it is probably better to fail closed
because the alternative is no RPKI and then hijacks become possible and
MITM attacks or DNS spoofing can be done leaving every Internet user at risk.
Also consider that not using best common practice to protect a service is
also putting you at risk for liability charges. So ignoring RPKI because
of possible liability concerns may as fire back at you.
More information about the NANOG