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
On Mon, 23 Jan 2006, Josh Karlin wrote: > 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. It seems like most of the routers which would need to make this decision wouldn't have adequate information upon which to do so... That is, upstream routers would already have hidden one route or the other (except with more-specifics). So this would mostly need to be implemented from the core outwards, rather than by individual smaller operators first. And once the core has done it, it's significantly less important whether the fringes do it or not. When I say "core" here, I don't mean just the "tier 1" operators, I mean everybody with a significant degree of peering. Hm. Well, maybe that's not such a big problem after all. -Bill
On Mon, Jan 23, 2006 at 12:47:38PM -0700, Josh Karlin wrote:
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.
So, if you consider the recent Cone-D hijacking incident, it seems to me that: 1) Cone-D's announcement of _some_ of the prefixes they announced would have been considered "suspicious" -- but not all, since some of the prefixes in question were for former customers or peers who had only recently terminated their business arrangements with Cone-D. 2) Panix's first, obvious countermeasure aimed at restoring their connectivity -- announcing their own address space split in half -- would *also* have been considered suspicious, since it gave two "sub-prefixes" of what Cone-D was hijacking. Unless I misunderstand what you're proposing -- which is entirely possible, in fact perhaps even likely -- it seems to me that it might well have done at least as much harm as good. Thor
For those prefixes announced by ConEd within the last 3 days that it no longer owns, correct, it would not of helped. But saving some is certainly better than none. For the second statement things get a little more subtle. We have considered allowing the trusted originator of a prefix to split the space among itself and those downstream of it without considering that suspicious behavior. This allows ASs to protect themselves via such methods. Thanks for your comments! Josh On 1/23/06, Thor Lancelot Simon <tls@netbsd.org> wrote:
On Mon, Jan 23, 2006 at 12:47:38PM -0700, Josh Karlin wrote:
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.
So, if you consider the recent Cone-D hijacking incident, it seems to me that:
1) Cone-D's announcement of _some_ of the prefixes they announced would have been considered "suspicious" -- but not all, since some of the prefixes in question were for former customers or peers who had only recently terminated their business arrangements with Cone-D.
2) Panix's first, obvious countermeasure aimed at restoring their connectivity -- announcing their own address space split in half -- would *also* have been considered suspicious, since it gave two "sub-prefixes" of what Cone-D was hijacking.
Unless I misunderstand what you're proposing -- which is entirely possible, in fact perhaps even likely -- it seems to me that it might well have done at least as much harm as good.
Thor
On 23-Jan-2006, at 14:47, Josh Karlin wrote:
Short of perfect filters, or perfect IRRs combined with PKI,
To what extent does the route object validation in the RIPE database (for routes covering RIPE-allocated space), together with maintainer object authentication, provide a "perfect IRR", according to your research? (I realise the step from "useful, authenticated source of data" to "universally-deployed import filters" is non-trivial.) Joe
To what extent does the route object validation in the RIPE database (for routes covering RIPE-allocated space), together with maintainer object authentication, provide a "perfect IRR", according to your research?
(I realise the step from "useful, authenticated source of data" to "universally-deployed import filters" is non-trivial.)
My understanding is that RIPE, while quite good, still contains a significant amount of old data that needs to be regularly flushed. It certainly seems reasonable to use its information as a good first approximation of the validity of a route, and I think that would go quite well with our recommendation, reducing the number of routes flagged as suspicious.
participants (4)
-
Bill Woodcock -
Joe Abley -
Josh Karlin -
Thor Lancelot Simon