In a two-part post, PacketDesign’s Cengiz Alaettinoglou, gives a brief overview and comparison of the IRR and SIDR security models.
Securing Internet routing was a highly debated topic during the APRICOT 2015 meeting in Fukuoka, Japan in February. This is a subject dear to my heart as well. I was one of the co-inventors of the Internet Engineering Task Force’s (IETF) Routing Policy System (RPS) Working Group’s security model; more widely known as the Internet Routing Registry (IRR) security model. I thought that sharing some of our experiences with deploying the IRR model can help others as well, including the IETF’s newer Secure Inter-Domain Routing (SIDR) Working Group’s model.
This is a complicated subject. Throwing more technology at it is not going to be sufficient, as successfully securing the Internet’s routing requires addressing social and economic challenges as well. We found out that the latter two were harder to address than the technology. Unfortunately, most of the advances in this area have been in the technology front; hence the SIDR model’s adoption has been had too low. How do we get service providers and enterprises to use one of these solutions? How do we pass the point where they stop seeing this as a cost burden?
In part I of this entry, I will give a brief overview and comparison of the IRR and SIDR security models. Then we will dive into our experiences in Part II.
IRR Model
At the core of the IRR model is the object-oriented Routing Policy Specification Language (RPSL). “Route” objects specify that the route object’s prefix can and will be announced in the Border Gateway Protocol (BGP) by the route object’s autonomous system (AS). Route objects need to be signed by both the prefix holder and the AS number holder (see http://www.rfc-editor.org/info/rfc2725) according to the addressing and numbering registries (such as regional registries like APNIC).
RPSL aut-num objects contain their ASs’ import and export policies; that is, they contain what routes are imported from and exported to each of their neighboring ASs. Aut-num objects only need to be signed by the AS number holder. The language contains other objects in order to simplify specification of the routing policies, but they are not important in this discussion.
These objects are registered at one of the registries participating in IRR. The verification of the objects, such as authorization and authentication checking, is done at the registration time. IRR registries are distributed (see http://www.rfc-editor.org/info/rfc2769) and as the data is replicated across registries, subsequent registries can re-verify the objects. A service provider can also run a routing registry where it stores its local objects as well as replicates remote objects (after re-verifying their authenticity). From these locally stored objects, a service provider using a tool (for example: see http://irrtoolset.isc.org) generates router configurations, mainly route filters that implement its policies. This is similar to, and indeed is, Software Defined Networking, except instead of a controller we have a compiler where we generate router configurations from high-level network-wide policy specifications. The ability to automate lengthy and error-prone BGP router configurations was one of the primary goals of the effort as well.
With route and aut-num objects registered, verified, and routers configured with the correct filters, it is possible to verify what route announcements in BGP are valid and what announcements are invalid and should not be accepted. Invalid announcements could include both accidental mistakes and malicious attacks such as prefix hijacking (for example: Pakistan hijacks (YouTube); and man-in-the-middle attacks (for example: bitcoin heist).
SIDR Model
The SIDR model has two components. The first component, route origin attestations (ROA), is similar to RPSL’s route objects. It states that a prefix owner authorizes an AS to announce its prefix in the BGP. ROA objects only need to be signed by the prefix owners. RPSL route objects on the other hand had to be signed by both the prefix holder and the AS owner. This makes ROA objects easier to manage. However, if one was to create a filter for a typical import policy “from neighbor AS x import all prefixes registered with origin AS x,” the SIDR model does not ensure that AS x is in charge of what these prefixes are. Indeed, AS x has no obligation to announce any of the prefixes with valid ROA objects with AS x. This is not as serious a problem for the SIDR model as the IRR model because of its second component.
The second component of the SIDR model is protocol extensions to BGP called BGPSec. BGPSec amends the BGP AS_Path attribute with the BGPSec_Path attribute using a series of signatures from all the ASs in the AS path. The nth signature in this attribute affirms that the nth AS in the AS_Path has passed the route it received from the previous AS in the AS_Path to the next AS in the AS_Path. In addition, the first signature affirms that the first AS originates the prefix.
In the SIDR model, verifying authentication and authorization mainly happens in the BGP speaking routers. Verification of ROA objects can be made offline in a server and a list of valid prefix/AS origin pairs can be downloaded to the routers as a filter, similar to the IRR model. However, validating the signatures in the BGPSec_Path attribute has to happen in the routers as the routes are being announced. This causes a computational burden on the routers, and it is questionable that today’s routers have the sufficient computational capacity.
This on-the-fly authentication and authorization checking before accepting a route eliminates the IRR model’s need for publishing policies and is very attractive. Note that the policy filters are still in place at AS boundaries as they implement business relationships; however they don’t need to be publicly published anymore. Publishing policies publicly was one of the criticisms of the IRR model. However, because publishing policies is replaced by protocol machinery, BGPSec may not protect from all attacks if the machinery was not sophisticated enough to foresee a new type of attack (more on this in Part II). In the IRR model, this is not an issue as long as an AS filters all of its peers, not just its customers, including large peers with very large route announcements.
The IRR security model has been available since the mid 90s. However, we are nowhere near securing the Internet’s routing system, because its adoption had been low. To ensure the SIDR model’s successful adoption, we need to understand where the IRR model failed and make sure the SIDR model addresses these shortcomings. This will be the subject of part II of this entry.
End of Part 1- read part 2 here.
Cengiz Alaettinoglou is currently the CTO at Packet Design and is working on SDN analytics and developing a prototype of a Network Access Broker. He is a widely published author and popular lecturer and was co-chair of the Internet Engineering Task Force (IETF) Routing Policy System Working Group.
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.