<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">(Sorry for the top post, my ipad seems to hate inline-replies)<div><br></div><div>For my own point of view, we’re currently accepting all routes, even invalid.</div><div><br></div><div>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”.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>-Dan</div><div><br><div dir="ltr">Sent from my iPad</div><div dir="ltr"><br><blockquote type="cite">On May 30, 2022, at 10:20, Job Snijders <job@fastly.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto">Hi!</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 30 May 2022 at 15:35, Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto">
If one border router receives invalid route, but due to RPKI issues mark<br>
it as 'not-found', while some other border router receives a valid route<br>
and mark it as 'valid' (does not matter whether by communities or directly<br>
by local_pref), then internal routers would prefer the valid route,<br>
while if there is no marking they can switch to the invalid.</blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.)</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto"><br></div><div dir="auto">Job</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"></blockquote></div></div>
</div></blockquote></div></body></html>