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