(Sorry for the top post, my ipad seems to hate inline-replies) For my own point of view, we’re currently accepting all routes, even invalid.
We’re using a BGP community so that when we sync things back to our central collector (which is just for research, like a looking glass) so we can send a report that says “at this site we got NN routes, YY invalid”. The community is not used in any way to make any decisions (on the fly decisions, I mean), nor is it passed on to any neighbors that route anything (only the collector). But my question about the user-defined attribute was that I’d like to be able to do more drill-down on the node itself. I’m seeing evidence where some of our peers claim to be rejecting RPKI invalid, but seem to be passing them on to us. -Dan Sent from my iPad > On May 30, 2022, at 10:20, Job Snijders <[email protected]> wrote: > > > Hi! > >> On Mon, 30 May 2022 at 15:35, Ondrej Zajicek <[email protected]> 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
