On Fri, Jul 13, 2018 at 4:25 PM, Christopher Morrow <morrowc.li...@gmail.com> wrote: > On Fri, Jul 13, 2018 at 11:19 AM Grant Taylor via NANOG <nanog@nanog.org> > wrote: >> The reading I did on RPKI / OV yesterday made me think that it is >> possible to have validated routes preferred over unknown routes which >> are preferred over invalid routes. So I'd think that you could still >> have the routes through your core but conditionally advertise the >> prefixes to customers based on their desires. > > you get the option at input (from transit/peering edge say) to evaluate the > 'rpki status' of a particular route, then set normal bgp attributes based > on that evaluation, so yes you can: > valid == localopref 1000 && community-A > unknown == localpref 80 && community-B > invalid == localpref 1 && community-Z > > but given: > 192.168.0.0/16 - valid > 192.168.0.0/17 - unknown > 192.168.0.0/24 - invalid > > your routing system will still forward toward the 192.168.0.0/24 prefix > because 'longest prefix match'. > Job's plan, I think, is that you reject/drop/do-not-accept the 'invalid' > prefix(es) and hope that you follow another / proper path.
That is exactly what I mean. Because of the golden rule "most-specific always wins" (and parts of the AS_PATH are pretty easy to spoof) it only makes sense to me to completely reject invalid routes. Kind regards, Job In Junos speak: [...] set policy-options policy-statement IMPORT:PEER term RPKI-DROP-INVALID from protocol bgp set policy-options policy-statement IMPORT:PEER term RPKI-DROP-INVALID from validation-database invalid set policy-options policy-statement IMPORT:PEER term RPKI-DROP-INVALID then validation-state invalid set policy-options policy-statement IMPORT:PEER term RPKI-DROP-INVALID then reject [...] ~
