mailing list archives
Re: So -- what did happen to Panix?
From: Nick Feamster <feamster () cc gatech edu>
Date: Fri, 03 Feb 2006 14:15:45 -0500
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
-certified prefix ownership
-certified AS path ownership
-dynamic changes to the above two items
It seems to me that most of the pieces needed to do
this already exist. RPSL, IRR softwares, regional
addressing authorities (RIRs). If there are to be
certified AS paths in a central database this also
opens the door to special arrangements for AS path
routing that go beyond peering, i.e. agreements with
the peers of your peers.
It is true that most of the pieces do exist. The problem appears to be
not a want of tools, but the fact that the tools are not coupled
properly---updating records about prefix ownership is, today, performed
out-of-band from the routing protocol.
This is a losing proposition. The data in the IRR, CA, or any mechanism
that is updated out-of-band from the protocol itself will inherently be
A better idea, I think, would be to tie the identifier of the route
something that is inherently bound to some cryptographic information
(e.g., a public key), rather than a separate piece of information whose
ownership must be "certified" (i.e., an IP prefix, an AS number).
I can think of some great ways to do this, but they all involve varying
degrees of departure from prefix-based routing. I would certinaly be
interested in talking offline about this with any forward-thinking types.
Hasn't that been said for years? Wouldn't perfect IRRs be great? I
couldn't agree more. But in the meanwhile, why not protect your own
ISP by delaying possible misconfigurations. Our proposed delay does
*not* affect reachability, if the only route left is suspicious, it
will be chosen regardless.
Depending on the threat model, then, one attack would be to cause an AS
to damp the non-suspicious route. This seems bad, right? A flapping,
correct route seems better than a stable, suspicious one.
Perhaps I am missing something, but how does imposing a delay help in
ascertaining a route's correctness? Even looking at some of the
"suspicious" routes I see by hand in the anomalies we detect, I can't
personally tell what's incorrect/actionable vs. simply unusual (again,
this goes back to the problem of inaccurate registries). In the case of
Panix/ConEd, I can imagine that an operator would have responded to the
alarms, checked the registry information and said, "these routes look
reasonable; go for it!" Or, as human nature suggests, the operator
might have even just ignored the alarms (particularly if origin changes
are as frequent as they seem to be).
What is really needed, in any case, is a better way to determine the
route's veracity. This still requires some auxiliary mechanism to
distinguish "unusual" from "suspcious", and, while you're designing that
auxiliary mechanism, it might as well be in-band (per the arguments above).
> If you are changing providers, which takes
That process seems to be getting quicker: