Feds Plot Massive Internet Router Security Upgrade

BobB-nw writes "The U.S. federal government is accelerating its efforts to secure the Internet's routing system, with plans this year for the Department of Homeland Security to quadruple its investment in research aimed at adding digital signatures to router communications. DHS says its routing security effort will prevent routing hijack attacks as well as accidental misconfigurations of routing data. The effort is nicknamed BGPSEC because it will secure the Internet's core routing protocol known as the Border Gateway Protocol (BGP). (A separate federal effort is under way to bolster another Internet protocol, DNS, and it is called DNSSEC.) Douglas Maughan, program manager for cybersecurity R&D in the DHS Science and Technology Directorate, says his department's spending on router security will rise from around $600,000 per year during the last three years to approximately $2.5 million per year starting in 2009."

Comments

Is it must me, or is that sum peanuts?

[dmomo]

I don't know much about security and cost, but the 600k does indeed seem fairly small to me for something like this. Even 2.x million seems like a sizzle in the pan. Can anyone speak to the costs involved?

Re:Is it must me, or is that sum peanuts?

[Morty]

They're talking about funding research, not deployment. RTFA. The dollar amounts in question sound about right.

Note also that this goes way beyond SSL. This is not about identifying your BGP peers -- that's a relatively simple problem that can easily be solved with MD5 [or one of the hash algorithms that is replacing MD5, since MD5 is problematic.] This is about validating that your BGP peers have the right to announce what they are announcing. This is a much harder problem than SSL.

That is, let's say you have a router that peers with $someco's router. It's easy to use MD5 [or replace it with something better] so you are sure that you are talking to $someco's router. It might also be possible to set up SSL instead, so you are even more sure you are talking to $someco. But even if you know you are talking to $someco, how do you know you can trust what $someco is telling you? What if $someco's router says it's a good path to get to a chunk of address space that belongs to $otherco -- should you believe it? BGP is full of settings that let you limit how much you trust your peers, but how do you know what you should set them to? Note that this is not a simple question of "is address space X associated with the $someco that is announcing it" -- even if address space X belongs to $otherco, it's possible that $someco is a legitimate transit network rather than a malicious third party.

Sounds like DHS is funding research to try to solve this.

This is somewhat different than the DNSSEC push. The DNSSEC effort is looking to deploy an existing but unpopular technology across the US federal government. The BGPSEC effort seems to be about creating a new technology for possible future deployment.

Re:Is it must me, or is that sum peanuts?

[m0i]

It exists already, it is called a routing registry. The most famous is RADB but they can use IRRd to have their own private version (which they probably do already).

Re:Question for the experts

[Klootzak]

will this only increase security at things that are .gov? That's the impression I get but I don't know enough technically to be sure.

Pretty much... it means that when Router A says to Router B "I have a new path to this network." the routers will first authenticate eachothers identity utilizing Digital Signatures.

Basically it's applying elements of PKI to router communications, so the router receiving the information knows it can trust other router's updates. If you didn't do it I could (potentially) spoof updates and say "this network exists here now" and all the information destined for that network would then be routed to me to packet-sniff to my heart's content.

This type of stuff (in addition to SSL/TLS encryption of sensitive data communication channels) has been used internally in (most) Banking networks for awhile now, I'm actually surprised they didn't have something like it in place already.

Re:It's a plot!

[jmauro]

I think they're just enabling MD5 on the BGP sessions. It's already specified in RFC 2385 - Protection of BGP Sessions via the TCP MD5 Signature Option. It's basically a $600k program to manage the logistics of turing this on. I do give props for Network World for making a mundane task 5 whole pages.

Re:Question for the experts

[Anonymous Coward]

This would apply to the backbone of the internet.
BGP is a different kind of routing protocol compared to others.....
You have two varient iBGP (internal) eBGP (external), eBGP is the one used for internet traffic.

With BGP, there is no real knowledge where particular networks are.....they just hand off traffic to the next Autonomous Domain or AS (Autonomous System) that will get the traffic to the right place.

So that is the fear with the protocol, people can go out there and start setting up the protocol in ASs and redirect traffic.....and there is no real way to verify it is taking the right path.

Maybe someone who knows more than I can explain better.

Re:It's a plot!

[youknowjack]

Where the hell is the IETF in all this, I want to know?

http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-10.txt

Abstract:

The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP and the routing information carried within BGP.

Re:It's a plot!

[jmilne]

It's more than just authenticating your neighbor. It's also about confirming that they have the right to be announcing the blocks that they're trying to announce to you.

Re:Question for the experts

[Klootzak]

I don't mean public networks, I mean private ones, SWIFT for instance..

Has been a few years since I've worked in the finance arena, but I thought each BIC code was signed (or at least they were talking about it while I was involved in that area) and things like MQSeries channels between nodes that were used for transporting data have been SSL/TLS encrypted for ages? I remember doing it actually, MQ Version 5.2 (or 5.3?) included SSL-over-channel functionality.

Anyways, I'm sure it's being taken care of, maybe get in touch with your bank and ask them if you're concerned?

Re:DNSSEC

[Morty]

They're not claiming that they invented it, they're just trying to help it along. While DNSSEC has been around a while, the overwhelming majority of zones, including the root zone and .com, are not signed yet. It may look like the US government is late to the party, they're actually ahead of most of the US commercial sector on this one.

So how does this "bolster" DNSSEC? Answer: the government is hoping that a large-scale implementation by a major buyer will push vendors to properly support DNSSEC. Many vendors don't support DNSSEC at all, or only support part of it; Microsoft, for example, only has minimal DNSSEC support. How do you think vendors will respond when .gov customers start telling them "we can't buy your product because it doesn't support DNSSEC. We'll have to go with one of your competitors."

RTFA.

Re:It's a plot!

[Have Blue]

MD5 is only weak when used on data in formats which allow for large amounts of padding. BGP packets are a much less flexible format so collision attacks are much more difficult.

Re:Excellent

[jd]

Well, yes, it is about time. Especially as the actual protocols needed were defined a long time ago. (To give you a frame of reference, the DoD were releasing Open Source IPSEC implementations in 1997. Ok, that specific protocol wasn't finalized at that point, but that tells you when the Government was sufficiently capable of and expert at encrypting router communications that they'd admit to it.)

That BGP, DNS and other mission-critical protocols aren't secure even twelve years later says a lot for the extreme lethargy at the level of critical infrastructure. Sure, they can't afford to dive straight in, but since when does the DoD release as Open Source their cutting-edge technology? If they were willing to let potential opponents (such as US citizens) have access, you can be certain they were already considering it old-hat.

It follows that they had the means and capability to install highly reliable, strongly encrypted, strongly authenticated router-to-router and DNS-to-DNS communications within the Internet. Of course, by that time the NSF had sold all the US links to Sprint and assorted other scrap-metal merchants, which is presumably why they never bothered.

It also tells me that the corporate sector is incapable of handling such infrastructure, that the "invisible hand" is too busy playing with itself to worry about such things as security and reliability, that those who believed businesses would be safer hands than universities have been shown to be utterly and completely incorrect.

This is not to say the public sector better. The UK's JANET is hardly a paragon of virtue. It turns out that they're all incompetent, but for different reasons. Businesses know better but want your money at no effort on their part, Governments know better but want your souls at no effort on their part.