deploying RPKI based Origin Validation

Grant Taylor gtaylor at tnetconsulting.net
Fri Jul 13 15:18:07 UTC 2018


On 07/13/2018 06:53 AM, Mark Tinka wrote:
> But yes, the majority of the issue was with routes learned from peers
> and transit. That, though, still leaves the problem where you end up
> providing a partial routing table to your customers, while your
> competitors in the same market aren't. 

Ouch.

> Most customers that aren't keen on IPv6 or DNSSEC treat RPKI the same 
> way - as a nuisance.

I can see that.  :-(

> So trying to speak sense into them would be a more treacherous road to 
> take than just turning it off until we get wider support within the BGP 
> operational community.

Please forgive the n00b question:  But isn't that where carrying the 
prefixes through your network and conditionally advertising them to 
customers comes into play?

Or does that run into complications where you must also have the 
prefixes which don't validate routed in your core?

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.

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

-------------- 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/afe41d14/attachment.bin>


More information about the NANOG mailing list