Small addition: routes are not only rejected when the BGP Origin ASN
doesn't match with any of the ROAs, but also if the Prefix Length
doesn't match up. RFC 6811 describes the procedure.
Kind regards,
Job
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.
M
I'll claim a de-facto godwin if anyone mentions the word "blockchain".
Nick
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.
This simply isn’t true. I’m willing to argue a bit about to what degree and in what circumstances RPKI Origin Validation technology is useful or not, but the use of the word “only” in this context is incorrect.
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.
This also is not true. It is not as black and white as you make it out to be.
1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the AS_PATH except on the direct EBGP sessions between 7018 and 2914. This means that you can craft BGP UPDATES with 2914 all you want, but 7018 won’t accept them. You can’t inject yourself between AT&T and NTT using spoofing.
2/ Many networks give all their peering partners the same LOCAL_PREFERENCE, so you’ll have to not only spoof the BGP Origin ASN but also compete & win for the shortest path in order for your hijack to arrive at the intended location.
We as industry essentially already have path validation for paths of length 1. This may not seem much, but since people in this industry tend to peer directly with networks that matter to them. The majority of Internet traffic flows over paths that have an AS_PATH length of 1.
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.
Uh… that draft is about something else entirely. 
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.
you are probably right about that, I’d prefer to stick to a technology that actually exists and is deployable!
Kind regards,
Job
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.
This simply isn’t true. I’m willing to argue a bit about to what degree and in what circumstances RPKI Origin Validation technology is useful or not, but the use of the word “only” in this context is incorrect.
I have massively oversimplified the situation, true, but essentially the vast majority of the pie chart of “why a prefix would be originated from another ASN and/or of a different prefix length” is:
- Leaking from within the originator’s borders where the border acts as a point of aggregation (atomic or otherwise). Mostly harmless.
- Someone else leaking out the prefix when they generate it to assist with traffic engineering, including through a proxy/filter (Pakistan/YouTube)
- Someone maliciously acting, so as to steal that traffic (predominantly Bitcoin mining pools, but could be ACME TLS etc)
Have I missed anything (that has substantial real-life relevance to any incident seen so far) or would you say that was a far summary?
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.
This also is not true. It is not as black and white as you make it out to be.
1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the AS_PATH except on the direct EBGP sessions between 7018 and 2914. This means that you can craft BGP UPDATES with 2914 all you want, but 7018 won’t accept them. You can’t inject yourself between AT&T and NTT using spoofing.
Not relevant to RPKI as it currently stands, which is unrelated to the current mechanism being used: origin validation. Path filtering and IRR prefix list filtering are much more important tools that should be used first – RPKI can only supplement those tools and should not be used in isolation, unlike the others which do a “good enough” job for most non-transit networks.
2/ Many networks give all their peering partners the same LOCAL_PREFERENCE, so you’ll have to not only spoof the BGP Origin ASN but also compete & win for the shortest path in order for your hijack to arrive at the intended location.
We as industry essentially already have path validation for paths of length 1. This may not seem much, but since people in this industry tend to peer directly with networks that matter to them. The majority of Internet traffic flows over paths that have an AS_PATH length of 1.
We do? I beg to differ. Much of Europe does, national networks in North America generally do, but those in the LACNIC / AfriNIC / APNIC regions? Of course there are exceptions (HKIX et al) but your average path length is going to be generally longer in those regions, and all it takes is for someone at a local IX to forge a couple of path attributes, and suddenly a bunch of traffic shifts.
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.
Uh… that draft is about something else entirely.
Oh whooops! Copied the URL from the wrong tab! I of course meant the draft you and Massimiliano Stucchi have at https://tools.ietf.org/html/draft-ss-grow-rpki-as-cones-00 – my bad!!
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.
you are probably right about that, I’d prefer to stick to a technology that actually exists and is deployable!
My idea is deployable today (for some values of today). Mark all the received NLRIs as not to be installed in the FIB, replicate the data via BMP or BGP with add-paths to a collector, process it, and ship out the results via a BGP session that sets the correct next-hops. I wrote a simple BGP speaker that had 4 byte ASN capability advertisement and graceful restart, literally in a day. Sure, it only supported IPv4 unicast, but with the wide array of open source BGP engines out there, it wouldn’t be so hard to put something together that offloaded the entire policy phase from the router to a control plane.
You could easily add modules in (just a chain of OOP interfaces) so that you could compare across prefixes, apply aggregation and damping, near real-time mirroring of IRR data to use as filter sets, maybe even read interface stats via SNMP / streaming telemetry / sFlow to start moving traffic around when ports get hot. Oh dear, I’ve re-invented SDN haven’t I? :S
However, just because you could deploy it today, doesn’t mean you should =)
M
1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the AS_PATH except on the direct EBGP sessions between 7018 and 2914. This means that you can craft BGP UPDATES with 2914 all you want, but 7018 won't accept them. You can't inject yourself between AT&T and NTT using spoofing.
Sure, but RPKI plays no role in this.
2/ Many networks give all their peering partners the same LOCAL_PREFERENCE, so you'll have to not only spoof the BGP Origin ASN but also compete & win for the shortest path in order for your hijack to arrive at the intended location.
Also utterly and completely unrelated to ROAs.
We as industry essentially already have path validation for paths of length 1. This may not seem much, but since people in this industry tend to peer directly with networks that matter to them. The majority of Internet traffic flows over paths that have an AS_PATH length of 1.
I would buy this argument with length 1-3, but I’m not completely convinced of “1”.
Owen
Congrats Jay, this is awesome news!
Thanks, Alex!
> I’m interested to hear what is preventing you from creating ROAs for all of your announcements.
>
> > We will publish more ROAs over time. Thusfar we have been utilizing
> > ARIN's hosted model, but down the road ARIN's delegated model will be
> > in our future.
> >
> What are your main drivers for wanting to move to the delegated model?
We can publish ROAs immediately for aggregate address blocks that we
have been allocated if all routes are originated only by our network.
But for our address allocations within which we have further assigned
sub-blocks to our customers as PA space where we allow multihoming
(e.g. within 12.0.0.0/8), we need to offer our downstream customers
the ability to publish ROAs for their specific portions first before
we publish a ROA for the aggregate, or else we'll make their
announcements become invalid.
Setting up that ability for our customers to publish ROAs for the PA
space they receive from us will require tight integration with our
customer software support systems, and perhaps also with our own
certificate authority -- thus the delegated model.
BTW: Alex, do you know where one might be able to get RPKI CA
software?
Thanks.
Jay B.