deploying RPKI based Origin Validation

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

ACK

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

*facePALM*

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.

Yep.

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;

Fair.

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

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: <http://mailman.nanog.org/pipermail/nanog/attachments/20180713/5c94939f/attachment.bin>