nanog mailing list archives
Re: deploying RPKI based Origin Validation
From: Grant Taylor via NANOG <nanog () nanog org>
Date: Fri, 13 Jul 2018 10:37:26 -0600
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 - invalidyour 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Current thread:
- deploying RPKI based Origin Validation Job Snijders (Jul 12)
- Re: deploying RPKI based Origin Validation Mark Tinka (Jul 13)
- Re: deploying RPKI based Origin Validation Job Snijders (Jul 13)
- Re: deploying RPKI based Origin Validation Mark Tinka (Jul 13)
- Re: deploying RPKI based Origin Validation Grant Taylor via NANOG (Jul 13)
- Re: deploying RPKI based Origin Validation Christopher Morrow (Jul 13)
- Re: deploying RPKI based Origin Validation Job Snijders (Jul 13)
- Re: deploying RPKI based Origin Validation Mark Tinka (Jul 13)
- Re: deploying RPKI based Origin Validation Grant Taylor via NANOG (Jul 13)
- Re: deploying RPKI based Origin Validation Christopher Morrow (Jul 13)
- Re: deploying RPKI based Origin Validation Mark Tinka (Jul 13)
- Re: deploying RPKI based Origin Validation Baldur Norddahl (Jul 14)
- Re: deploying RPKI based Origin Validation Mark Tinka (Jul 14)
- Re: deploying RPKI based Origin Validation Job Snijders (Jul 16)
- Re: deploying RPKI based Origin Validation Mark Tinka (Jul 17)
- Re: deploying RPKI based Origin Validation Job Snijders (Jul 17)
- Re: deploying RPKI based Origin Validation George Michaelson (Jul 17)
- Re: deploying RPKI based Origin Validation Mark Tinka (Jul 18)
- Re: deploying RPKI based Origin Validation Job Snijders (Jul 13)
- Re: deploying RPKI based Origin Validation Mark Tinka (Jul 13)
- RE: deploying RPKI based Origin Validation Michel Py (Jul 17)