A recent discussion hosted by the RIPE NCC highlighted a number of key trends affecting the future of Resource Public Key Infrastructure (RPKI). The event, which drew around 90 participants worldwide, is worth watching as it reveals progress on Border Gateway Protocol (BGP) origination, convergence in routing systems, and difficulties in securing the BGP.
These issues are likely to remain relevant well into the future.
We’re making progress in ‘origin’
The first message I picked up on from the discussion is that there is evidence RPKI deployment, specifically Route Origin Validation (ROV), is now ‘moving the needle’ on the charts. We can see evidence of reduced visibility of bad origination in the BGP. A good case can be made that some of this is due to the increase in BGP speakers that are using ROV from RPKI to prevent invalid states from entering the system. This is a long game, a problem that has been building for some time. It’s pleasing to see that, at scale, in a world with roughly 71,000 ASNs active in the BGP, there are signs of movement.
Another indicator of this was discussed in the presentations. Major CDN, search, content and transit providers are all demonstrating engagement. The ‘reach’ of the major central players has large downstream and Internet-wide consequences. When Amazon (for instance) decides that it will respect ROV facing the AWS service, it penetrates every Internet economy with AWS-homed services. This is not to say there are no downsides to centralization and the increasing use of five to ten core CDNs, transit and search/content providers. But given this trend is a market reality, the adoption of secure routing practices by these players is (I think) unquestionably good.
Read more: DNS resolver centrality
Additionally, there is now good trust in the ROV solutions available in the main BGP-providing equipment and software vendor space. Nobody should have a problem deploying ROV or RPKI in the class of product that a high-availability ISP (or any BGP speaking service provider) needs to use.
Read more: A new way to measure Route Origin Validation
Other work in RIPE may… look a lot like APNIC’s MyAPNIC routing system!
Nathalie Trenaman, one of the principal presenters in this session and Routing Security Program Manager at the RIPE NCC, also discussed feature requests they are looking at in 2021. One of these is managing the Internet Routing Registry (IRR) and the elements included within it (such as whois, Routing Policy Specification Language (RPSL) and routing objects) alongside RPKI in a more ‘combined’ manner. This would align the Route Origin Authorization (ROA) and Route: object (RPSL) views of origination.
This is good news, because this is exactly how APNIC manages routing security in the MyAPNIC portal. We’ve reached out to RIPE to offer implementation experience around this, and it is a good sign of convergence in number/routing management processes inside the RIR system overall. Larger players in the BGP now have to manage resources in more than one RIR and a constant issue for them is divergence in processes inside each RIR’s portal. This move to an aligned model of data management should be welcome news to everyone.
RIPE has made significant investments and commitments to improving security and stability, including RPKI ‘resiliency’ — improvements to the RPKI service designed to prevent loss of service or accidental mis-signings. Like RIPE, APNIC is concerned about the exposure to the community at large in this area, and we too have been looking at our overall stability and service availability. The cooperation between RIPE and APNIC here goes on inside our processes; we’ve been sharing ideas on more reliable RPKI systems, and around our compliance with processes in the Certification Practice Statement (CPS), which binds us to operational norms in the PKI model.
There’s still a hill to climb in ‘path’
Unfortunately, the second message is less positive, but we must face reality. The reality is that securing the BGP path is not proving to be easy. There is no global-Internet-wide path solution in deployment. The cryptography burden to solve BGP path security cannot be taken ‘out’ of the router, and so represents a burden in computation, workload, and time for the router fabric itself. BGP Origin can be calculated and managed ‘outside’ of the BGP engine, and fed in via RPKI-RTR. However, the path itself has to be solved ‘inside the machine’ and it’s not cheap.
Additionally, there are now reasons to look at path, and see not one solution, but actually three: there is BGPSec, the one we know is in standards process and has been ‘coming soon’ for some time, but there is also now Autonomous System Provider Authorization (ASPA), and the alternative AS-Cone model of path security.
Unlike BGPSec, these are perhaps more ‘speculative’ than ‘absolute’ — they tell you that a path you see in the BGP should be trusted because you can show that for the chain of AS-to-AS relationships, there is a visible declaration between the AS holders and they do talk to each other. In BGPSec, the signatures you see on the BGP path show that you know for certain the message is passed between the AS-to-AS chain, as is.
This is both absolute (good) and unfortunately proscriptive (bad) in that it excludes paths that are NOT visibly used by the BGP to forward BGP messages themselves: you can’t simply use BGPSec to secure a path you don’t actually send BGP down. In ASPA and AS-Cone, these are distinct declarations on AS-Pairs, and paths can be found from the set of AS-Pairs. It’s possible to get a lower certainty of trust, but about more things: you know the pairs talk to each other; you just don’t know for sure that the specific chain of AS-Pairs is the one you should be using.
AS-Cone and ASPA are slightly different, and use different information models. My personal view is that AS-Cone is a cruder model, based on prior declarative intent similar to the IRR model of routing configuration, and so might in some way be more aligned to how some BGP speakers already think and operate in provisioning. It’s also mainly of interest in the RIPE region because it was designed by routing engineers from that region.
Inside it, ASPA has the seeds of a model first proposed some time ago called SO-BGP. A proposal that Russ White, an engineer at Cisco, brought into the standards process, and which was rejected for BGPSec. It too now has proponents in the RIPE region (the ASPA principal author is Alexander Asimov) but is grounded in a less Eurocentric process, and so has (in my opinion) more traction worldwide — there are people who are interested in it from all the major circuits of BGP operations, in Europe, Africa, the Americas and Asia.
Read more: One year in BGP (in)security
Manners still matter: MANRS that is!
As well as a discussion focused on the BGP, and the applicability of RPKI to the BGP, we discussed the context of ‘doing the right thing’ overall, which is covered by the ISOC MANRS initiative. We were all reminded there are things routing-active networks can do to limit bad traffic, and this includes defensive and protective-of-others work, such as bad origin filtering. MANRS has recognized there are participants who can’t do some of the higher cost work here, and has removed a strict requirement from the set of conformance requirements to try and ensure motivated MANRS participants can meet specification and get their certification aligned with practical reality.
Internet address security is about more than just BGP: RTA
A final note, discussed in the web session, is the applicability of the APNIC Resource Tagged Attestation (RTA) initiative, which is re-entering the IETF standards process, after APNIC helped NLNet with funding for an implementation inside the ‘Krill’ system. RTA is a general-purpose mechanism for signing statements about things, which relate to some Internet number resources. RTA was noted in the session as being applicable to AS-Cone, ASPA, and possibly other contexts. APNIC would entirely support people exploring the use of RTA to sign these products, and there is no barrier to this right now: RTA is easy to deploy in Krill, and it works, even as it makes its way through the IETF process from draft status — it has just been accepted as a working-group item in the SIDROPS WG and will be discussed at future IETF meetings.
Things are getting better, but there’s always more to do
So, in summary, the RIPE NCC open house on RPKI and network security is well worth watching and the conversation about how to improve the stability, quality and trust in routing in the Internet continues, in all the RIR regions, on and offline. You can watch it via the link, or the embed below.
Join in, and have your say!
To learn more on RPKI developments, register and join the sessions at APRICOT 2021 in March.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.