deploying RPKI based Origin Validation
gtaylor at tnetconsulting.net
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:
> 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'.
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)pal.com
> 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...
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
More information about the NANOG