BGP security was a hot topic a few years ago, but is not as much studied these years. However, with technologies such as IPv6 and DNSSEC, BGP security is making a comeback, especially in the industry. We academics also have much to contribute in this space. In today’s Three Paper Thursday, I will highlight three recent work related to BGP security. It is also a good starting point to catch up in BGP security for those whose last memories of BGP security involve proposals such as S-BGP and SoBGP.

10 Lessons from 10 Years of Measuring and Modeling the Internet’s Autonomous Systems, M. Roughan et al., IEEE Journal on Selected Areas in Communications.

This paper presents ten well-learned lessons that someone who researches BGP, especially measurement-based BGP analysis, should keep in mind. In BGP research, there is often no shortage of data, since there are many public route collectors available for anyone to download, but the data that does exist contains many artefacts not fully understood by many researchers. For example, we have to be careful when we use publicly collected routing data (usually from RouteViews or RIPE RIS) to infer Internet topology. BGP as a information-hiding protocol is not designed to make available the global topology of the Internet (everyone’s view of the Internet is also different for that matter). An Autonomous System (AS) can have a backup transit provider that only kicks in in certain situations, and would thus be excluded from day-to-day operations. Other artefacts include the fact that route collectors only exist at certain points of the Internet and would miss certain information some hops away. This barrier makes research difficult in some cases: if we see a spike of BGP updates, is it because of many path changes or a session reset?

In this paper the authors use modeling to forecast the deployment of a secure version of BGP given the then-ongoing Resource Public Key Infrastructure (RPKI) work (the RPKI part has since been completed, see next paper). One problem with large-scale security upgrades related to a network’s infrastructure is that nobody wants to be the early adopters. One common reason is why touch it if it is working? The situation might be slightly better in the world of IPv6, since there is a business case and revenue associated to justify its deployment. However, in other technologies such as DNSSEC and secure BGP, it is harder to justify its existence in the business sense. Even if the operators want to roll out the upgrade, their management may still oppose. Enters security economics, which tells us that we must have proper aligned incentives for all stakeholders in order to bring these technologies into reality. These incentives often come in two forms: lower the barrier of entry, or increase the positive outcome. The authors in this paper use simulations on real-life topology to explain how secure BGP will roll out. Specifically, what should be done to lower the cost and barrier for ASes to adopt secure BGP? Or, can we make it so that ISPs will actually see possible revenue by providing secure BGP to their customers?

This is not a paper per se but a newly-born RFC. This particular RFC, along with many others, is the result of the first of many specifications to come by the Secure Inter-domain Routing (SIDR) working group of IETF. After a long period of work the first stage of a secure BGP system comes into light. This RFC discusses the overview of RPKI, a PKI for resources, essentially providing verifiable mappings for AS numbers to prefix blocks. There are no active verifications at this stage. Like other PKIs, this is there so that other technologies can be built on top of it and use it. Already, we see vendors and open-source projects implementing different versions of checkers that use data from RPKI. The short-term planned path of SIDR group is to first have the RPKI to verify ownership, then check for origin, and eventually check for the whole path. Even with all these technologies worked out, BGP security still has a long way to go, since so far we have only worked on the control plane. The data plane, where packets are actually routed, is a whole different matter.