deploying RPKI based Origin Validation

Fri Jul 13 16:25:21 UTC 2018

On Fri, Jul 13, 2018 at 11:19 AM Grant Taylor via NANOG <nanog at 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.
Perhaps Mark could send along ONLY the valid/unknown routes to his
customer, or some mix of the set based on what type of customer:
  super-sekure-customer - valid only
  sorta-sekure-customer - valid/unknown
  wild-wild-west-customer - all

it sounded like Mark didn't want to deal with that complexity in his
network, until more deployment and more requests from customers like;
  Customer: "Hey, why did my traffic get hijacked to paY(omlut)pal.com
yesterday?"
  Mark: "because you didn't ask for 'super-sekure-customer config? sorry?"

I could have misunderstood either mark or job or you.. of course.

> I would appreciate it if someone would be kind enough to explain what
> I'm misunderstanding.  Or better, point me to some better documentation
> to read myself.
>
> Thank you from the peanut gallery.
>
>
>
> --
> Grant. . . .
> unix || die
>
>