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
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
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
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
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
> 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.
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.
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