Way to store ROA info so we can accept but view?

[Job Snijders]

Hi!

On Mon, 30 May 2022 at 15:35, Ondrej Zajicek <santiago at crfreenet.org> wrote:

> If one border router receives invalid route, but due to RPKI issues mark
> it as 'not-found', while some other border router receives a valid route
> and mark it as 'valid' (does not matter whether by communities or directly
> by local_pref), then internal routers would prefer the valid route,
> while if there is no marking they can switch to the invalid.



You are of course right that the presence of a marker can be used to
facilitate route decision making, this generally holds true. However I
maintain that the most robust design pattern is to fix “the RPKI issue”,
rather than uppref valid routes in the other half of the network. (Or
accept the fact that one’s routers might select RPKI-invalid routes as best
path because a router isn’t aware that the path is RPKI-invalid.)

Modifying the local_pref of routes based on the RPKI validation state
introduces issues such as increased potential for BGP churn, but also makes
deploying RPKI in medium/large sized networks significantly harder.

Whether a temporary “RPKI issue” (crashing validator) causes an
inconsistent state in the overall network, or it being a slow moving
multi-month RPKI-ROV deployment where POPs are converted one-by-one, to me
it seems there isn’t really a material difference between the two
conditions.

Modifying BGP path attributes based on the validation state doesn’t seem
the best current practise. It’s too bad there is a ton of documentation out
there (outside the BIRD project) that says things like “instead of
rejecting, you can downpref invalid routes!” (which from a security point
of view because of LPM is futile).

Kind regards,

Job

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220530/717c363d/attachment.htm>