On Tue, 12 Feb 2019 at 16:05, Nick Hilliard <nick@foobar.org> wrote:

Matthew Walster wrote on 12/02/2019 14:50:
> For initial deployment, this can seem attractive, but remember that one
> of the benefits an ROA gives is specifying the maximum prefix length.
> This means that someone can't hijack a /23 with a /24.

they can if they forge the source ASN. RPKI helps against misconfigs
rather than intentional hijackings.

As it stands today, RPKI is only useful to prevent fat-fingering of ebgp routing policies, where routes are leaked from a point of "legitimate" re-origination such as a web filter service. It's entirely unsuitable (at present) for anything where someone is re-originating the prefix somewhere else with the same origin ASN present (i.e. maliciously) and it doesn't protect against someone accidentally sending you a prefix they heard elsewhere that is valid.

My understanding is that part of that problem can be solved with https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03 but once again it's still only preventing fat-fingering and not malicious intent.

RPKI provides an additional layer of security, but it stands independent of the need for prefix list and AS_PATH filter generation (likely derived from IRR data). I'm actually of the opinion that the whole "PKI" part of RPKI is the bit that really needs to die. PKI certificates brought no real benefit to the solution. Embedding RFC 3779 (X.509 Extensions for IP Addresses and AS Identifiers) makes the data so much less accessible and difficult to process for all but the most technically competent system/network administrators, especially considering most existing tools and libraries for X.509 certificate operations just don't support doing anything reasonable with them in a way that doesn't involve several hours afterwards in a candle-lit bath with a Pink Floyd CD playing in the background.

Personally, I'd like to see BMP (RFC 7854, unidirectional flow of information) bolted on to an extended version of the RTR protocol (RFC8210) or a stripped down unidirectional BGP session, and have the whole policy engine offloaded from the border router to some kind of daemon running, potentially on a distributed controller of sorts, that:

Pulled in all this raw data and processed it, using the compute power available in servers after the invention of the Cyrix 200.
Asserted the veracity of the data it has received (real-time updates of prefix-lists, paths, trustworthiness, advertised "directionality" akin to peerlock etc) without having to periodically push new configuration to your routers.
Applied policy decisions, including mapping traffic for that destination into a FEC / MPLS tunnel as appropriate.
Possibly even applying aggregation at the FIB install level if appropriate to reduce total FIB entry size and programming time.
Distributed a final RIB (+FIB if needed) out to each of the BGP routers in the AS, depending on the view they needed.

I think I'd have a hard time convincing people of that though, and the RIR policy folk would have a small heart attack at the level of complexity required.