FRAMINGHAM (10/03/2003) - In 1996 the U.S. government tapped BBN Technologies LLC to develop a more secure version of the primary protocol used to route information around the Internet.
The effort was not in response to any particular data or network security breach. It stemmed from a realization that the Border Gateway Protocol (BGP) was becoming ever more vulnerable as the Internet grew in size and importance.
Yet seven years later, BBN's Secure BGP (S-BGP), which establishes a public-key infrastructure to stymie IP address spoofing, is still a work in progress and has yet to be implemented in Internet routers. Router memory constraints, processing overhead concerns and the downtrodden state of the telecom economy are cited as reasons why.
"The state of security in BGP is pretty minimal," says Alex Zinin, area director of the routing and sub-IP working groups in the Internet Engineering Task Force (IETF). "As it is deployed today, there is no mechanism to authenticate and identify the authorization of a specific (routing information) announcement."
What's more, work on BGP security is more divided than united. Cisco Systems Inc. and some ISPs are working on an alternative to BBN's S-BGP, called Secure Origin BGP (soBGP), which authenticates yet also lets ISPs implement routing policy.
"S-BGP is dead in the water," says Cisco Fellow Fred Baker, former chair of the IETF.
That's an assertion to which Steve Kent, BBN's chief scientist for information security, counters: "Some of the options offered in soBGP would be disastrous from a security standpoint. There are concerns that soBGP doesn't architecturally nail things down."
Security isn't the only concern with BGP. Other public and private efforts have sprung up to address BGP's perceived shortcomings in scalability and reliability as traffic on the Internet continues to double each year.
Some say it's time to move beyond the 14-year-old protocol, while others say doing so would cause drastic disruptions to the thousands of routers in and providing access to the Internet.
"A whole new protocol tends to make people think significant investment and high risk," says Martin Capurro, senior director of product management at Qwest Communications International Inc. "We'd like to see a solution that just enhances the current one."
Proposed enhancements are plentiful. For reliability, the IETF and a number of router vendors developed so-called non-stop routing/forwarding and graceful restart extensions to BGP to keep data flowing as the protocol resets.
But ISPs are highly selective when it comes to incorporating such revisions.
Packet Design, a start-up led by industry veteran Judy Estrin, learned this firsthand.
The company last year unveiled BGP Scalable Transport, a protocol for streamlining communication of BGP routing information. By reducing the number of TCP connections required between routers, the technology could improve scalability and lessen security risks and the effect of lost connections, Estrin says.
But this Packet Design technology never caught on.
"We felt that the routing vendors just did not seem to want to spend the energy on fixing BGP," Estrin says. "The service providers were in enough disarray in terms of reorganizing and consolidation, (and) they didn't feel that they could put significant pressure on the routing vendors to get the capability. We couldn't deploy it without a router."
And router vendors found no need for such a technology.
"It's not something that we, as an implementor of the protocol, ever felt necessary to avail ourselves of," says Matthew Kolon, senior solutions engineer at Juniper Networks Inc.
As a general-purpose protocol, BGP contains the features necessary to implement the scalability and security features appropriate between ISPs, Kolon says.
"A lot of it has to do with the implementation," he says. "(Limitations are) related not to the protocol itself but to the business and political relationships that are inherent in interdomain situations."
Another vendor echoes Kolon's views. Proficient Networks Inc. makes network appliances and software designed to reduce routed WAN infrastructure costs and improve application performance so service providers can deliver on service-level agreements (SLA).
"BGP really is about implementation - not necessarily flaws with the protocol," says Allan Leinwand, Proficient co-founder and president. "There are definitely some security hooks in BGP, such as MD5 checksums or digests on the information, but no one seems to be using them. So there's definitely a way for BGP peers to authenticate each other and to verify that the data coming across is valid and not being hacked or spoofed or replayed."
Service providers probably are not implementing features such as MD5 because they are not included in years-old BGP templates used to establish peering and interdomain policies, Leinwand says. ISPs also might be concerned that MD5, which requires additional CPU horsepower on the router, could sap performance and potentially violate customer SLAs, he adds.
"Do you want to add features and functions that are more CPU-intensive to BGP if you're already a little worried about the fact that it's perhaps not scalable?" Leinwand asks.
MCI uses MD5 to get a little more out of BGP. The carrier employs it on a per-request peer basis in some cases, says Jennifer Brooks, director of global IP engineering at the carrier's ISP operations.
"The clear thing to explore is, what is the risk you assume will occur with compromising BGP or hijacking a BGP connection?" she says. "(Hijacking is) a very hard thing to do. It's not something you can do over a standard BGP connection between two peers. From a hacker perspective, it's difficult unless a lot of information is provided."
AT&T Corp. devised its own method for dealing with BGP route-table integrity. In addition to route filtering, it developed a peering monitor that inspects information sent to its network from other parts of the Internet.
PeerMon, as AT&T calls it, looks for cases in which others are misrepresenting the carrier's address block. AT&T then can notify the unsuspecting ISP that it might need to reconfigure its network; or if the misrepresentation is of a malicious origin, attempt to track down the perpetrator.
"There's no authoritative list of who owns what address block," says Jennifer Rexford, a technology consultant at AT&T Bell Labs. "So when a piece of information is sent into the protocol, all it really takes is someone typing incorrectly or intentionally typing incorrectly to put misinformation into the protocol. Even if BGP could check a very accurate repository of that information, it might be extremely slow."
Qwest uses MD5 in all internal BGP sessions with its peers and to authenticate MPLS Resource Reservation Protocol connections, Capurro says. Qwest also separates BGP route reflection functions from the packet forwarding router onto separate servers, he says.
That way, the carrier also can separate public and private traffic, which frees up CPU cycles, increases memory and minimizes security risks, Capurro says.
BGP is adequate for the interdomain routing infrastructure of the Internet, but a new protocol is needed to swap control information for IP- and MPLS-based services such as VPNs, MCI's Brooks says.
"There's a lot of controversy right now in the IETF about the scalability of BGP," she says. "The requirements of the services for new features and enhancements are impacting the overall BGP source code. Should we cap BGP where it is today and create a new protocol that would be used for (RFC) 2547 (VPNs)?"
BGP wasn't originally intended to support VPNs, but was extended to accommodate them, Brooks says. Some of these extensions could affect the protocol's performance and interoperability, she says.
"You're always going to see that collateral damage as you keep the two (service and infrastructure functions) together," Brooks says. "We're loading BGP down with more and more features than it really was intended to use."
While backing a new protocol for services, Brooks says BGP should remain the operational protocol exchanging information between autonomous systems in the Internet.
"I don't see that changing," she says. "It is too nested into the networks themselves to ever be able to safely undo that. There would be major routing instability if you were to try to move away from BGP."
The IETF doesn't see things changing anytime soon either.
"At this point, we're not defining a new routing protocol," IETF's Zinin says. "And we're not actively working on a new Internet routing and addressing system."