deploying RPKI based Origin Validation

Grant Taylor gtaylor at
Fri Jul 13 16:37:26 UTC 2018

On 07/13/2018 10:25 AM, Christopher Morrow wrote:
> 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:
> - valid
>  - unknown
> - invalid
> your routing system will still forward toward the prefix 
> because 'longest prefix match'.


Thank you.

So the information would be carried across the network, but it still 
suffers from the same problem.

> 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.


You would almost need separate logical networks / VRF to be able to 
prevent the longest prefix match winning issue that you reminded me of.

> 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

Yep.  That's what I was thinking of.

> 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) 
> 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.

You understood me correctly.

Thank you for explaining what I was missing.

Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the NANOG mailing list