jerry@freeside.fc.NET (Jeremy Porter) writes:

Largely we don't see conflicts of an actual prefix being announced by hostile parties, where there isn't a technical parent/child delegation relationship. The badness of such an event probably is why.

Big events like MAI 7007, Qwest reannouncing 3561, and so forth are noticed. But mis-announcing just a few /24 (out of a /19) or one /16 (out of a /15) don't make headlines. Nevertheless, it does happen on a regular basis. Most of the time it does appear to be a configuration error, which may explain why 'classfull' networks boundaries are the most likely places to have problems. For example, a few weeks ago I posted about the FCC's network prefix being announced by a tiny provider. A more interesting one was at one point during the war over Kosovo, a major backbone had a /16 of its network redirected through Macedonia Telecom. Why go through the trouble of installing a sniffer at mae-east, when you can just redirect the route through a more convient tapping spot. The traffic still flowed, just via a scenic route. Unfortunately, there are no good tools for the first level support people when confronted with an insane route. When reporting a problem, you will generally get back a response it "worked" for them. The next response is "that's how the Internet works," or "that's what the customer requested." As far as the first-level support is concerned, if ping or traceroute works, there is no problem. After a few days of escalating the problem, someone will eventually discover a configuration error, and fix it. Note: the bell-heads haven't solved this problem either. Insane routes also occur in the telephone system. Trying to explain to an operator why even though the call goes through, it is going to the wrong place, is hard to do.

Its good to have the tools in place and the technology understood in the event its need, but to some extent just having the tools is enough (MAPS-smurf/spam).

I suppose when someone finds a quick and dirty hack to remotely cause BGP sessions to flap between providers on private peering or public peering points, the "trust everyone" model will have to examined again. Largely I feel it would result in ingress filtering much like smurf attacks have with directed broadcast.

Since most of BGP route problems appear to be configuration mistakes by operators, more wide-spread double checking of announcements would help. Obviously a more sophisticated, malicious person or tool could get around a simple check. BGP vulnerablilties have been well covered in other forums. But until there is a big problem, I agree with your assessment. BGP passwords offer some protection against one particular type of impersonation attack. Anti-spoofing and access-lists help against other types of attack. Denial of service attacks are a bit harder to protect against. Transitive trust is a tough one unless we can all agree on some source to trust when there is a conflict. Note: I don't think the bell-heads have really solved this one either. If local number portability ever takes off, the net-heads are going to have a remarkable sense of deja vu. And don't get me started on SS7 'security.' -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation