- Root server DoS revisited (posted 2003-02-14)
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 (posted 2003-02-14)
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. And CAIDA has an in-depth
analysis.
- BIRD Internet Routing Daemon (posted 2003-02-16)
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 (posted 2003-02-16)
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.
- BST: BGP Scalable Transport (posted 2003-02-19)
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.
- RIPE MS SQL worm analysis (posted 2003-02-27)
RIPE has another
analysis of the MS SQL worm.
RIPE monitors performance between 49 locations on the net. 40% of the monitored
pairs of hosts suffered from congestion between them, in 60% of the cases
there weren't any problems. The problems were cleared up after about 8 hours.
RIPE also monitors root server performance and BGP activity. Two of the root
servers suffered a good deal of packet loss. The BGP stuff is the most
spectacular: there were about 30 to 60 times more updates of different kinds.
This clearly shows the need for control and data plane seperation: congestion
in the actual traffic shouldn't be able to take down the routing protocols. On the
other hand, having BGP and other routing protocols run "in-band" over the same
circuits as the actual data makes sure there is a functioning path between two
routers. There's also something to be said for that.
On NANOG there was some talk about UDP/1434 filters. I argued that they
shouldn't be necessary any more by now, but the rate of reinfection (people
bringing in new vulnerable boxes) remains significant. So places with Windows
machines on the network will probably need to have these filters in place for
the forseeable future. But this is annoying because they also block legitimate
UDP traffic, such as DNS, once in a while, and many routers take a performance
hit when these types of filters are enabled.
(advertisement)
