From: Nick Feamster (no email)
Date: Sat Feb 04 2006 - 16:45:45 EST
Josh Karlin wrote:
>>> 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
> won.
My point was actually that an adversary could flap a correct route to
damp it, to induce a router to select a suspicious one. (This threat
also exists today, I believe, but the delay tactic does not solve the
problem.)
> 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.
>
I would say that ascertaining correctness is more than half of the work.
If a router can definitively say that a route is bogus, the "measure
to prevent its spread" is pretty simple, right? i.e., just drop the route.
> 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.
Analysis of multiple vantage points could definitely help in your case.
The method for determining what a "suspcious" route is is not obvious,
though.
In the example you present, a router can install route filters to reject
incoming announcements for its own address space (many ISPs seem to
deploy these types of filters already). Much trickier is determining
things like route hijacks, where even a delay won't help much without a
reasonable way to ask "Is this route hijacked?" The best way I know of
for doing that is to go back to the registry. If there are other ways
to do this, I'd certainly be very interested to know about the state of
the art.
The proposal seems useful in a case where collection of measurements
from multiple vantage points could run analysis to detect suspcious
routes, assuming the detection algorithms could be run quickly enough
and the information about suspicious routes could be propagated back out
to the network...which might not always be true in an attack scenario.
-Nick
|
|
|