Re: deploying RPKI based Origin Validation

[Job Snijders <job () instituut net>]

On Fri, Jul 13, 2018 at 4:25 PM, Christopher Morrow
<morrowc.lists () 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
[...]
~