BST: BGP Scalable Transport

A company called Packet Design has developed BGP Scalable Transport (BST), a transport protocol for BGP that is intended to replace TCP as the carrier potocol for BGP routing information. Packet Design isn't afraid to make bold claims; their press release about the protocol heads "Packet Design solves security, reliability problems of major internet routing protocol, BGP."

But BST really only addresses the problem that each BGP router in an organization is required to talk to every other BGP router. This gets out of hand very fast in larger networks. But two solutions have been around for years: route reflectors and confederations. When a BGP router is configured to be a route reflector, it checks for routing loops so it can safely "reflect" routing information from one router to another, eliminating the need to have every two routers communicate directly. Confederations break up large Autonomous Systems (ASes) into smaller ones and accomplish the same thing in a different way. Packet Design solves the problem by flooding BGP updates throughout the internal network, much the same way protocols such as OSPF and IS-IS do.

Packet Design claims that this will help with convergence speed and reliability and even security. Their reasoning is that using IPsec on lots of individual TCP sessions uses too much CPU so protecting BGP over TCP with IPsec is unfeasible. But even on a Pentium II @ 450 MHz with SHA-1 authentication you get 17 Mbps (see performance tests). Exchange of a full routing table takes about 8 MB and 1 minute = around 1 Mbps so with less than 17 peers receiving a full table the crypto can keep up without trouble. And that's even assuming internal BGP sessions need this level of protection. External BGP sessions are a more natural candidate for this but eBGP doesn't have the same scalability problem as iBGP. It also assumes the security problems BGP has can be fixed at the TCP level. However, the most important BGP vulnerability is that there is no scalable and reliable way to check whether the origin of a BGP route is allowed to send out the route in question to begin with and whether any information was changed en route (by on otherwise legitimate intermediate router). These issues are addressed by soBGP and S-BGP.

BIRD Internet Routing Daemon

The Faculty of Math and Physics of the Charles University in Prague has created BGP capable routing software for Unix machines released under the GNU General Public License. The BIRD Internet Routing Daemon supports multiple tables with BGP and RIP for both IPv4 and IPv6 and OSPF for IPv4.

Data Connection

Data Connection has a full range of routing products, including the BGP, OSPF and IS-IS protocols. BGP has support for VPNs. The software is very portable and should run on pretty much anything, from Solaris to Windows to special environments, with very little porting effort.

Root server DoS revisited

As promised, some more information on the denial of service attacks on the root DNS servers last october. Paul Vixie, Gerry Sneeringer and Mark Schleifer prepared an event report with some good factual information. It seems each server received 50 to 100 Mbps worth of traffic, but not just ICMP as earlier reports indicated. The source addresses in the attacking IP packets were faked, but not easily identifiable as such. This explains why the attacking traffic wasn't simply filtered out very quickly.

However, all the "users weren't affected" and "the system kept running as designed" claims not withstanding, the fact that a fairly moderate amount of DoS traffic was able to make several of the root servers unreachable for many people is cause for concern. It seems the root server operators have picked up on this and are working on solutions. However, they're not saying much about this, which in itself is also cause for concern... "Security by obscurity" doesn't have a very good track record.

MS SQL "slammer" or "sapphire" worm

I think I'm jinxed. When I put my anti-DoS article up on this site the root name servers were attacked. Then O'Reilly put the article on ONLAMP and the next day there was the MS SQL worm...

A worm in a single 404 byte UDP packet: the net certainly wasn't prepared for that. This worm didn't really harm infected systems all that much: it's the incredible amount of traffic generated by each infected system that caused so much trouble. Obviously dozens of megabits worth of traffic for each affected host will lead to congestion in many places, but it was worse than that: Cisco routers that were doing fast switching rather than Cisco Express Forwarding (CEF) ran out of memory and CPU. It also seems Riverstone routers, which are supposed to be able to do this in hardware, fell flat on their faces. (But I haven't seend this myself.)

Have a look at an article I wrote for the O'Reilly Network about the impact of this worm: Network Impact of the MS SQL Worm. (Note: the link doesn't work anymore, but I saved the article here.) And CAIDA has an in-depth analysis.

Network Impact of the MS SQL Worm

This is a post I wrote for O'Reilly back in January 2003 when the SQL Slammer worm hit. It seems it's gone from their site now, so I'm putting it here, including the comments.