Reaching out to ARIN members about their RPKI INVALID prefixes

Thu Sep 20 00:58:49 UTC 2018

> On Sep 19, 2018, at 00:44 , Job Snijders <job at ntt.net> wrote:
> 
> On Tue, Sep 18, 2018 at 06:18:00PM -0700, Owen DeLong wrote:
>> That depends. If you ONLY allow the maintainer of NET-192.159.10.0/24
>> to update the route objects for it, then the word ONLY is effectively
>> present by the lack of any other route objects.
> 
> Ah, so you are now applying the RPKI Origin Validation procedure to a
> non-existent flavor of IRR? :-)
> 
> Today I can create route-objects covering 192.159.10.0/24 in a number of
> IRR databases and there is nothing you can do to prevent that, this
> simply is not the case with RPKI. I prefer an existing system (RPKI)
> over hypotheticals (Owen's IRR). 
> 
> Secondly, I've also noticed you only emphasize an adversarial angle
> (origin spoofing), but there are other angles too.
> 
> The majority of today's BGP problems are attributable to operator
> mistakes (misconfigurations). Analysis has shown that most BGP incidents
> happen on weekdays rather than in the weekend. The number keys on our
> keyboards are quite close to each other and Origin Validation is very
> effective against typos. Another angle is bugs in BGP implementations:
> your neighbors doing origin validation reduces the impact and
> propagation of incorrect announcements from your network should you run
> into a software defect.

Sure, but given the email thread that started this all, if people start enforcing
RPKI based origin validation, do you think it will create fewer or more mistakes
in this regard?

It appears to me that the complexity of RPKI and other issues will lead to
RPKI causing more human-factors based routing accidents than it will
likely prevent.

>> So RPKI is great if we can just reduce the internet diameter to 1
> 
> Agreed, in other words: RPKI is offers tangible benefits to those that
> peer directly with each other, or use peerlock.

Agreed, noting the assumptions built into the theory that everyone can
use peerlock.

>> in which case MD5 passwords on your BGP sessions pretty much
>> accomplishes the same thing with a lot less kerfuffle.
> 
> Uhh... you may want to refresh your memory on what BGP is and how
> TCP-MD5 works.

Admittedly, it doesn’t cover the fat finger cases above, but, it does
cover the “know who you’re accepting the route from” issue for one
hop out and in a way that doesn’t allow you to create a time-bomb
that becomes visible on a delayed basis when you fat-finger it.

Owen