Hi, I'm Iljitsch van Beijnum. This page has all posts about all subjects.
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
The Computer Science and Engineering Department of the University of Washington is doing a study on BGP misconfiguration, which resulted in the paper Underst anding BGP Misconfiguration (postscript). The conclusion of this paper is that there is a lot of misconfiguration going on (200 to 1200 prefixes are affected each day), and it's not always human error.
Permalink - posted 2002-10-26
During the Asia Pacific Regional Internet Conference on Operational Technologies in March 2002, Geoff Huston presented An Examination of the Internet's BGP Table Behaviour in 2001. It seems the growth in the routing table slowed down considerably to 8%. The two previous years saw a 55% growth rate.
Yes, it took the news some time to reach BGPexpert. There are some other interesting presentations available on the APRICOT 2002 web site as well.
Permalink - posted 2002-10-25
On August 15th, the Recording Industry Association of America (RIAA) filed a complaint against AT&T Broadband, Cable & Wireless USA, Sprint and UUNET, asking for a court order to make those networks to block an MP3 web site operated in China. BGP is even mentioned on page 11 of the complaint.
This, and other recent RIAA initiatives such as their plans to hack MP3 swapper's PC's, has made the RIAA very unpopular on the NANOG list. The pros and cons of blocking RIAA and record label web sites were discussed at length.
When the offending web site went offline, the RIAA dropped the lawsuit. But I'm sure the net hasn't seen the last of the RIAA lawyers.
Permalink - posted 2002-10-21
On August 28th, AT&T had an outage in Chicago that affected a large part of their network. It took them two hours to fix this, and after this they released a fairly detailed description of what happened: network statements in the OSPF configuration of their backbone routers had been deleted by accident.
AT&T was praised by some on the NANOG list for their openness, but others were puzzled how a problem like this could have such wide spread repercussions. This evolved into a discussion about the merits of interior routing protocols. Alex Yuriev brought up the point that when IGPs fail, they do so in a very bad way, his conclusion being it's better to run without any. This led to some "static routing is stupid" remarks. However, it is possible to run a large network without an IGP and not rely on static routes. This should work as follows:
That way, you never talk (I)BGP with a router you're not directly connected to, so you don't need loopback routes to find BGP peers. Because of the next-hop-self on every session, you don't need "redistribute connected" either so you've eliminated the need for an IGP. Since the MED is increased at each hop, it functions exactly the same way as the OSPF or IS-IS cost and the shortest path is preferred.
Permalink - posted 2002-10-15