Will feds mandate Internet routing security?

DHS wants federal agencies, carriers to adopt emerging routing security standards

The U.S. Department of Homeland Security has spent $3 million over the past few years on research aimed at bolstering the security of the Internet's routing system.

Now, as this research is being deployed across the Internet, DHS wants government agencies and their carriers to be among the earliest adopters of the new Resource Public Key Infrastructure (RPKI) system that it helped create.

Also read: Fix to Chinese Internet traffic hijack due in January

DHS considers the RPKI system to be a much-needed first step in securing the Internet's core routing protocol, which is called the Border Gateway Protocol (BGP). In addition to its support of RPKI, DHS also has spent around $1 million on research and software development aimed at adding security directly to BGP.

RPKI helps improve routing security by adding a layer of encryption to the communications between Internet registries and network operators. With RPKI, network operators can verify that they have the authority to route traffic for a block of IP addresses or routing prefixes known as Autonomous System Numbers.

RPKI is designed to prevent Internet routing attacks and accidents, such as the recent China Telecom Internet traffic hijacking incident that has received attention on Capitol Hill.

RPKI is similar to another new Internet security mechanism backed by DHS, which is DNS Security Extensions (DNSSEC). DNSSEC is an Internet standard that prevents spoofing attacks by allowing Web sites to verify their domain names and corresponding IP addresses using digital signatures and public-key encryption. Federal agencies were required to adopt DNSSEC in 2009.

Network World interviewed Doug Maughan, director of the Cybersecurity Division within DHS' Science and Technology Directorate. Here are excerpts from that conversation with Maughan about RPKI and whether federal agencies and their carriers will be required to adopt it:

What is the status of DHS' research into routing security?

The majority of the projects are centered around RPKI and BGP security.

RPKI is moving forward in the Internet Engineering Task Force. We're trying to help ensure that the standards side of things progress, so that we are not just creating a solution that's proprietary. We're funding the software development side of things to ensure that when we have an agreed-upon protocol specification for RPKI, we also have working software that can be open sourced to the community. We will continue to fund that software development for RPKI in 2011 as well as the standards activity.

The second piece of our effort is BGP security, which is the development of a new protocol specification. It's in progress. We expect it to be released this fiscal year, and that it will go through an iteration or two within the IETF, which will take us a year or two. We've already started to do an implementation. It changes the way BGP works, just like we did with DNSSEC. At some point in the near future, we will release the design and then make an open source version of the BGP security protocol available.

Should RPKI be required for network operators? If so, by whom?

Each [regional Internet registry] has a different working model. APNIC [the Asia Pacific registry] has a top-down model, and they could tell all of their constituents that they will do this. RIPE [the European registry] has a similar model. But ARIN [the North American registry] has a bottom-up model. ARIN isn't going to force anything unless all of its members agree to it. Many of the major ISPs say they want routing security. We need to tell them that we believe RPKI will provide that. So the next steps are to continue to push the technical completion of RPKI, get working implementations, and at the same time work down the more marketing and political paths.

Should the federal CIO require federal agencies to adopt RPKI similar to the requirement for DNSSEC?

We are working that part of the equation with [the National Institute of Standards and Technology]. Our intent is very similar to the model with DNSSEC. We're trying to work the same issues on the RPKI side. I don't think it will be in the 2011 update to [the Federal Information Security Management Act] because we are not quite far enough along. We're not quite there on the BGP security side. Our intent is to...have government security requirements that say that agencies that are running their own infrastructures have to support RPKI. If they are doing managed services through [a contract] like MTIPS, those vendors who provide those services would have to support RPKI. That's the model we are using. It worked quite well on DNSSEC, and we think it will work on RPKI and routing security. Our goal is to have the government be an early adopter.

What is your guess on how quickly RPKI will be adopted?

There are already some pilots being done by APNIC, RIPE and ARIN. A year from now, we're not going to be able to say it's done. But I would hope that at least we would have completed pilots and be operational with these registries. Routing security is going to take us another couple of years. We have to do marketing and make a business case to key ISPs and key Internet infrastructure providers to jump on board. Our goal is that within a couple of years, RPKI is there. Hopefully by then, the BGP security protocol will be completed and then we can start working on that. We've budgeted to support routing security research at $3 million a year through 2016.

Several years ago, DHS played a similar role in promoting DNSSEC as it is doing today with routing security. What is your view of the adoption of DNSSEC?

I'm optimistic. Over 60 zones are signed. The key thing in my mind was the result of .org's operational experience. They saw minimal impact of DNSSEC to their operational performance. Everybody was claiming that the impact would be a 30% to 50% performance hit, but .org will tell you that's not the case. We've been able to shake out any performance concerns that the naysayers had and show them that it works. Now we're getting .net and .com signed. We're starting to have discussions with CISOs of major companies like PayPal and Google to say that now that .com is being signed, what are your plans? We've made a lot of progress this year. We signed the root, and some said that would never happen.

What new initiatives does DHS have underway with regard to Internet security?

The only other thing we've been doing is in botnet detection technologies. We've been big funders of that.

On the routing side, we've funded the development of a number of tools like the Prefix Sanity Checker. We were the funding behind the University of Oregon's Route Views going from a batch system to a real-time system. When the Pakistan Telecom attack on YouTube happened in 2008, Route Views didn't see it for 80 minutes. With the China Telecom attack, they saw it within 30 seconds.

If you were to address a room full of corporate CIOs, what would you advise them about Internet security?

I would encourage them to get on the DNSSEC bandwagon as soon as they can, especially if they are a dot-com. This becomes a way for them to provide another layer of security for their own infrastructure and for the people who use their infrastructure. I'd at least make them aware of RPKI and tell them that it needs to be on their road maps. While it's not available today, it's coming down the pike. The other thing I'd tell them is to reach out to the R&D community and take advantage of some of the more innovative security technologies that might be coming, from botnets to insider threat detection to identity technologies. We're trying to do more to connect the research community with the operatiional community so that CIOs and CISOs become aware of new security technologies sooner rather than later.

Learn more about this topic

U.S. plots major upgrade to Internet routing security

Fix to Chinese Internet traffic hijack due in January

Six worst Internet routing attacks

Join the discussion
Be the first to comment on this article. Our Commenting Policies