|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical preventing future situations like panix
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
|