On Sep 19, 2018, at 00:44 , Job Snijders <job@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