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

[Dan Mahoney]

(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 <job at fastly.com> wrote:
> 
> 
> 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/11b8b69e/attachment.htm>