Editorial StaffFollowing up on my last post about the security vulnerabilities in BGP, the IETF has taken two efforts to fix them. Back in 1995, the Routing Policy System Working Group was formed (I have chaired this working group, and many in the community, including folks from service providers and address registry operators, contributed). We have standardized a language called Routing Policy Specification Language (RPSL[ref]), and a security model (RP-SEC [ref]).
Network operators, both service providers and enterprises, would register their authorized routes (by chain of trust starting from the Internet Assigned Numbers Authority), and the neighbor ASs they pass these routes to. Given the state of the art in 1994, the security credentials (authentication as well as authorization) would be checked at the time of registration. We then wrote a tool that read these validated policy specifications and generated router configurations that would be immune to these kinds of attacks. Unfortunately, RPSL adoption has been low (more on this later).
IETF recently took another effort in its Secure Inter-Domain Routing Working Group (SIDR). The technology developed there can check the security credentials in-band as BGP routes are exchanged (BGPSEC [ref]). Unfortunately, this technology does not adequately solve the problem: It requires heavy cryptographic computational power not available in today’s routers; it does not protect against man-in-the-middle BGP route hijack attacks (rather it protects against the earlier attacks); and it does not address the reason why RPSL adoption has been low.
There were two major factors that contributed to the low adoption of the RPSL. First, to get the full benefit of the system, policy registrations had to reach a critical mass. That is, an early adopter does not gain much. Second, operators need to configure their routers from these policy specifications to filter routes from their customers and perhaps even from their peers. This is an operational hardship as policies are constantly changing. Consequently, only a few service providers in the U.S. and elsewhere adopted the system (Europe saw better adoption).
These networks are better protected though: none of their customers can hijack routes. Hence, the service provider can ensure at least its customers can always reach each other. With the increase of the malicious attacks, time may be ripe for more service providers following suit and deploying either RPSL or SIDR based systems.
Software Defined Networking (SDN) can help address the second factor; that is, configuring routers from RPSL policies in a timely manner. Routing policies change constantly due to the high number of policy objects needed to represent all BGP routes and autonomous systems. Unfortunately, the router configurations are only updated during maintenance windows; usually a few times a week. This creates a time window during which some policies are not reflected and can lead to suboptimal routing.
For example, when an enterprise changes its service provider, some service providers may not accept routes from the new service provider and only accept routes from the old service provider until their routers are reconfigured. In an SDN world, a controller can read and revalidate these policies as fast as changes happen and configure routers in real time without causing an operational hardship. The support for NetConf/Yang[ref] in routers and controllers can simplify configuring these policies. We are very pleased to see NetConf/Yang support in the OpenDaylight controller.
Whether it is RPSL or SIDR, we must act with urgency to secure BGP and protect networks from malicious attacks. Both solutions require registration of policy objects. (Have your network’s policy objects been registered?) Until this is done on a broad scale, we need to closely monitor BGP for evidence of route hijacking. In my next post, I’ll discuss how Route Analytics technology can help.
Add comment