Home page logo
/

nanog logo nanog mailing list archives

Re: So -- what did happen to Panix?
From: Nick Feamster <feamster () cc gatech edu>
Date: Sat, 04 Feb 2006 16:45:45 -0500


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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]