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
Re: preventing future situations like panix
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
Re: preventing future situations like panix
bill,all, On Mon, Jan 23, 2006 at 12:08:11PM -0800, Bill Woodcock wrote: 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... not necessarily. the decision could be made in near real time by building prefix filters based on the algorithms that josh and co have worked on and leaving a 'default deny' in place. this moves the routing decision off of the router (which i agree does not have the history or resources to take these additional vectors of information into account) and over to a server with more storage and computational capacity. it has the side effect of denying announcements of valid prefixes from customers that are not in the prefix list until the list is next updated, but we already pay that price now; well, networks that maintain prefix filter lists on customer-facing ports pay that price now. this just describes a different way of building and maintaining those lists. the idea of incorporating history into the validation process for routing tremendously useful and worth considering seriously. at least until we get all signed updates. how is that whole thing going? :-) t. -- _ todd underwood chief of operations security renesys - internet intelligence [EMAIL PROTECTED] www.renesys.com
Re: preventing future situations like panix
On Mon, 23 Jan 2006, Todd Underwood wrote: It seems like most of the routers which would need to make this decision wouldn't have adequate information upon which to do so... not necessarily. the decision could be made in near real time by building prefix filters based on the algorithms that josh and co have worked on and leaving a 'default deny' in place. this moves the routing decision off of the router (which i agree does not have the history or resources to take these additional vectors of information into account) and over to a server with more storage and computational capacity. Agreed, if you're willing to suppose that routing decisions will be centralized, and static RIBs pushed down into things that look more like switches, many many many problems go away, to be replaced by the other problem: out-of-band control plane and detection of forwarding plane failures. I did a bunch of work with the Agilent guys on that five years ago or so, and found it really fascinating, in a what-if alternate-universe sort of way. -Bill
Re: preventing future situations like panix
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
Re: preventing future situations like panix
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
Re: preventing future situations like panix
It seems like most of the routers which would need to make this decision wouldn't have adequate information upon which to do so... not necessarily. the decision could be made in near real time by building prefix filters based on the algorithms that josh and co have worked on and leaving a 'default deny' in place. this moves the routing decision off of the router (which i agree does not have the history or resources to take these additional vectors of information into account) and over to a server with more storage and computational capacity. The 'core' routers are definitely the best informed, though other ASs which are multi-homed also come across a substantial bit of information through updates. Yet if only the core ASs were to run such a solution, it would be sufficient to suppress most attacks for at least a day. The paper has more detail on that situation.
Re: preventing future situations like panix
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.
Re: preventing future situations like panix
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 [EMAIL PROTECTED] 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
