Hi, I'm Iljitsch van Beijnum. This page has all posts about all subjects.
Image link - posted 2002-11-15 in
I'm a bit behind on the news. The most important IDR news is that of the DoS-attacks on the root nameservers on October 21st. (There will be more on this in the tech list news soon.) By some strange coincedence, I had just put a page outlining anti-denial-of-service measures up on this site. I've been working on this since before the summer, but I hadn't yet really published the story on this site since I was considering publishing it somewhere else and I have been unable to test how good it works.
Permalink - posted 2002-10-31
On October 4th, Worldcom/UUNET had a major outage. Worldcom attributes the problems to "a route table issue". It is still unclear what happened, but the rumors indicate a problem similar to the one that AT&T experienced in August: something went wrong while managing the routers, but this time it wasn't a configuration problem, but the problems started after loading a different Cisco IOS image in a large number of routers.
Permalink - posted 2002-10-30
netVmg, a company selling products that optimize traffic flow for organizations with more than one connection to the net, didn't waste any time and announced a "webinar" on October 9th, promising to tell what happened and how to prevent it. I think they mean that if you use their products, your traffic is automatically rerouted around any black holes or congestion in ISP networks. Another company selling similar products, Route Science, had a spokesperson explain that BGP is pretty much brain dead in an Americas Network article.
What those companies conveniently fail to mention is that what their (expensive) products do automatically, can also be done by hand on any BGP router. But I guess as long as they keep the mis-information to a minimum and they don't inject instability into the global routing table by trying to micro-manage inbound traffic flows, their products are harmless and serve a need.
Check out netVmg's newsletter called The Best Path for not-too-technical discussions about the benefits of multihoming with the marketese limited to reasonable levels.
Permalink - posted 2002-10-29
At the end of September, the White House published a National Strategy to Secure Cyberspace. It seems that at the last moment, a lot of text was cut and the 60 odd pages PDF document offered for download was made a draft, with the government actively soliciting comments. One of the prime recommendations in the document is:
| R4-1 | A public-private partnership should refine and accelerate the adoption of improved security for Border Gateway Protocol, Internet Protocol, Domain Name System, and others. |
Some people say the government wants Secure BGP (S-BGP) to be adopted. It is unclear how reliable these claims are. In any event, S-BGP has been a draft for two years, with no sign of becoming an RFC or implementations being in the works.
In 2001 4th quarter interdomain routing news I ranted about the general problems with strong crypto in the routing system. It is widely assumed BGP is insecure because "anybody can inject any information into the global routing table." It is true that the protocol itself doesn't offer protection against abuse, but since BGP has many hooks for implementing policies, it is not a big problem to create filters that only allow announcements from customers or peers that are known to be good. However, the Routing Registries that are supposed to be the source of this information aren't always 100% accurate and although their security has greatly improved the last few years, it is not inconceivable that someone could enter false information in a routing database.
In an effort to make BGP more secure, S-BGP goes way overboard. Not only are BGP announcements supposed to be cryptographically signed (this wouldn't be the worst idea ever, although it remains to be seen whether it is really necessary), routers along the way are also supposed to sign the data. And the source gets to determine who may or may not announce the prefix any further. I see three main problems with this approach:
And even if all of these problems can be solved, it gets much, much harder to get a BGP announcement up and running. This will lead to unreachability while people are getting their certificates straightened out. Also, routers in colo facilities aren't the best place to store private keys.
Permalink - posted 2002-10-28
Stephen Gill has added Application Note: Securing BGP on Juniper Routers to his list of documents. (The list includes some other documents discussing BGP on Juniper routers, among other things.)
He spends a little too much time on filtering "bogons" (address space that isn't allocated or otherwise unroutable) in my opinion, but there is a lot of good stuff in there. Bogon filtering for input will buy you a 35% or so reduction in abusive traffic if you are under a DoS attack with randomly falsified source addresses. Bogon filtering for outbound traffic will buy you next to nothing since if you already do it for incoming, your servers won't have to reply to requests seeming to come from this address space so all that's left is hosts in your network deciding to send packets to bogon space themselves.
My remarks about bogon filtering have not gone unchallenged. Both Stephen Gill (Steve's site) and Rob Thomas (Rob's site) told me bogon filtering can be very useful to get rid of a significant percentage of abusive packets. Especially filtering on bogon source addresses is useful: this stops incoming packets with obviously falsified source addresses. Rob tells me this can be upwards of 50% of the abusive traffic for some attacks. Filtering on bogon destinations (which doesn't have any performance impact if you just route the bogon ranges to the null interface) gets rid of traffic hosts on your network or customer networks send to non-existent destinations. This traffic is usually scans (port scans or worms) but it can also be replies to incoming packets with bogon sources if those aren't filtered.
My main problem with bogon filtering is that you have to keep on top of new /8s assigned to the Regional Internet Registries (RIPE, ARIN, APNIC) by the IANA and change your filters accordingly. A better way to do this is with unicast RPF. If you use uRPF and run full routing without a default, all packets with source addresses for which there is no route in the routing table will be dropped so exit bogon sources. Bogon destinations get a "host unreachable" because without a default route the the router has no place to send them. However, the generally available version unicast RPF on Cisco routers breaks asymmetric routing, which is very common in ISP and multihomed networks. Cisco has improved the uRPF feature to get around this, but this improved uRPF isn't widely available across platforms and IOS images.
See Cisco's uRPF_Enhancement_4.pdf document for more information on the new uRPF capabilities. It seems Cisco doesn't like people linking to their stuff, so this link most likely doesn't work. If you have CCO access, you can probably find the document through "regular channels" and typing the name in a search engine will help you find find it elsewhere.
Permalink - posted 2002-10-27