jerry(a)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
