mailing list archives
Re: So -- what did happen to Panix?
From: Josh Karlin <karlinjf () cs unm edu>
Date: Fri, 3 Feb 2006 14:55:50 -0700
Hasn't that been said for years? Wouldn't perfect IRRs be great? I
couldn't agree more. But in the meanwhile, why not protect your own
ISP by delaying possible misconfigurations. Our proposed delay does
*not* affect reachability, if the only route left is suspicious, it
will be chosen regardless.
Depending on the threat model, then, one attack would be to cause an AS
to damp the non-suspicious route. This seems bad, right? A flapping,
correct route seems better than a stable, suspicious one.
A flapping route would only be considered suspicious if it disappears
for many consecutive days and no other known route for the prefix
originates at the same AS. At which point the attacker has already
Our primary concern is with keeping BGP stable until its replacement
(e.g. sBGP) is ready for deployment.
Perhaps I am missing something, but how does imposing a delay help in
ascertaining a route's correctness? Even looking at some of the
"suspicious" routes I see by hand in the anomalies we detect, I can't
personally tell what's incorrect/actionable vs. simply unusual (again,
this goes back to the problem of inaccurate registries). In the case of
Panix/ConEd, I can imagine that an operator would have responded to the
alarms, checked the registry information and said, "these routes look
reasonable; go for it!" Or, as human nature suggests, the operator
might have even just ignored the alarms (particularly if origin changes
are as frequent as they seem to be).
Ascertaining correctness is only half of the work. If you correctly
classify a malicious route, but do not take some measure to prevent
its spread, you have just done yourself and your customers harm.
In the case of PGBGP, there is a lot that an operator can do to verify
correctness. Multiple viewpoints of anomalous routes can be collected
into a single database in which operators can, once per day, check to
make sure that their own address space is not being announced
elsewhere. This can easily be automated for both the NOC and the
collection process. Relationship information need not be revealed as
only the originator of the suspicious route is needed.
If, in the worst case, the route is not detected as malicious before
it is considered normal, the next wave of routers will be introduced
to the route and consider it suspicious. The first wave will then
notice the problem and fix it, still protecting a significant portion
of the network.