preventing future situations like panix

Josh Karlin karlinjf at cs.unm.edu
Mon Jan 23 19:47:38 UTC 2006


Short of perfect filters, or perfect IRRs combined with PKI, it's a
difficult problem to stop prefix hijacks such as we've seen this
weekend.   Myself, Jennifer Rexford, and Stephanie Forrest have been
looking at feasible and incrementally deployable solutions to the
problem and we would really like to have operator input on our
proposed solution.

The idea is simply to consider 'suspicious' looking routes as a last
resort in the decision process (~1 day).  Thus if no alternative route
for a prefix exists, the suspicious route is used regardless, no harm
done.  Of course, relationship preference must be preserved when
possible so very few routes should be considered suspicious if
possible.

Suspicious routes are those that originate at an AS that has not
originated the prefix in the last few days and those that introduce
sub-prefixes.  Sub-prefixes are always considered suspicious (~1 day)
and traffic will be routed to the super-prefix for the suspicious
period.

We have not yet addressed man-in-the-middle style of attacks where an
AS announces a false route and places itself in the middle.  We also
realize that nobody likes to have announcements delayed, and we
explain in detail how few routes will actually be delayed by our
mechanism in the linked paper.

http://www.cs.princeton.edu/~jrex/papers/pgbgp.pdf

Your input is most welcome.  Thanks,

Josh Karlin



More information about the NANOG mailing list