The global Internet routing table is built primarily on a trust-but-verify model, a nod to the early days of the...
Internet where backbone engineers knew each other personally. Like many other early applications, security was not a primary factor in the development of the Border Gateway Protocol (BGP).
As the Internet has transformed itself from a primarily academic communications medium, applications and protocols that relied on trust and personal connection have been replaced with technologies that rely on cryptographic mechanisms for data privacy, integrity and identity verification. Telnet has (mostly) given way to Secure Shell, and open mail relays have been (again, mostly) locked down. The need has always been to do the same with BGP security, and now the standards exist to further strengthen the "verify" part of trust-by-verify.
No central authority for global IP routing exists
There is no central authority for global IP routing information, nor is the routing structure of the Internet hierarchical. The global route table is built by operators connecting to each other and announcing what routes they will accept traffic for. To accomplish this, BGP establishes sessions between routers to trade prefix reachability information. Even small to medium-sized companies that aren't ISPs can participate in BGP, which allows them to connect to multiple ISPs simultaneously and easily switch providers. At any moment, any BGP speaker can announce any IP prefix.
Contrast this with the public switched telephone network, where routing information is static and distributed in either paper form or in a Microsoft Access database. Anyone who has tried to port numbers between competing telcos will understand the benefits of BGP. It is this flexibility that has contributed to the Internet's explosive growth. It is a foundational element that underpins the daily operation of the Internet and one that is hidden away from end users. This invisibility in part explains why BGP has escaped many of the advances that have improved the security of other Internet protocols and applications.
There is nothing inherent in BGP or IP addressing that prevents a network from improperly announcing a prefix. Again, this is primarily a trust-based system where ISPs need to verify that their downstream customers are properly announcing networks.
Filters should be in place to prevent a customer from announcing a network not assigned to it. Yet this can be a process prone to errors and one based on poorly updated information in the Whois database or from a collection of route registries -- none of which are authoritative. Under the best circumstances, mistakes can still happen.
Public key infrastructure could hold the answer
Prefix hijacking is the term used when a network operator claims or announces routes which are not assigned to it. In 2008, a Brazilian ISP accidentally leaked a nearly full route table to its peers. Luckily, this was caught early and damage was minimized. Earlier that year, the Pakistan Telecommunication Co. caused a worldwide outage when it made a configuration error in its attempt to block YouTube. Was this a case of misconfiguration that leaked or an intentional denial of service? It's hard to tell. More recently, there have been hijacking events for profit: stealing Bitcoins.
There is a solution to address many of these problems: resource public key infrastructure (RPKI). RPKI is a specialized PKI framework that relies on extensions to X.509 certificates to carry IP route origination information. Organizations wanting to announce a prefix create a route origin attestation (ROA), which includes the prefix, mask length range and origin autonomous system number. These ROAs are announcements to the world that a specific organization has a verifiable authorization to announce the specified IP prefix. Currently, less than 5% of the global table is protected with ROAs, with Latin America and the Caribbean in the lead, according to the RPKI Dashboard website. Approximately 20% of Latin American and Caribbean Network Information Centre routes are in the RPKI valid state, representing about 2.5% of the global table.
Two methods to implement the platform
There are two methods for implementing RPKI: hosted and delegated. In the hosted model, the Regional Internet Registry (RIR) runs the certificate authority (CA) and hosts the private certificates for organizations wishing to participate. This is an easy way to get started for smaller organizations that don't have many number resources or don't have many changes to the details contained in the ROAs. Interaction is through a portal hosted by the RIR.
Delegated RPKI is much more flexible, allowing an organization a programmatic interface to the RIR's infrastructure. This requires that the organization become a CA with the associated management overhead. This is more appropriate for service providers that have number resources that can be assigned to downstream customers or organizations that make many changes where human interaction with a Web portal would burdensome.
In the hosted model, the RIRs have implemented this new standard with a lower barrier to entry, making it easy for even the smallest network operators using BGP to participate. For those organizations that do not use BGP, it is still important to understand the security role for this technology. If you don't run BGP to connect to the Internet, you should be asking your upstream provider(s) two questions: Are the prefixes assigned to your organization protected with RPKI? And if they aren't, when will the protection be implemented?
Evaluate cloud providers to ensure protection
If your website or application is hosted by a cloud provider, part of the evaluation and selection process should be to determine if the networks these applications reside on are protected with RPKI. Consider this: The aforementioned route hijacking targeted Bitcoin miners hosted with Amazon Web Services.
It is important to note that RPKI addresses BGP origin validation, not path validation. RPKI cannot detect all routing anomalies, only those when a prefix is originated by an unauthorized autonomous system.
The global route table is a foundational element for the Internet. Its integrity is the responsibility of all networks participating in it. RPKI is an important step forward in ensuring the integrity of this shared resource. There is no longer a reason we should suffer outages because of misconfigurations or hijackings.
BGP in an SDN world